X-Authentication-Warning:	delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient:	geda-help AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=date:from:to:subject:message-id:in-reply-to:references:reply-to
	:organization:disposition-notification-to:return-receipt-to
	:mime-version;
	bh=R8KHMEAyY52HffCBJ1AYfVXA/qmKSvh0X3lVBcJwOo0=;
	b=IeDSLvcdIKwo2ga5HzyJI0N9aBqEX17eyqxwXb3IRk5q/FdsYrvpo6xT803B5oGUJe
	q0jdPAADSqZcFCLsUv5iAgvFogkaGWylod8tyLK0xeEeAG+BN2dwFaaFD2JT7mIAdg7J
	yOsEZ63l7eJfkQSiLSkPS3ul7TUIxyKS7FFW2NhSXi/RTSdYy3La4rQeczCaDx5iCtnt
	QvYknoNfs6p5QtDYAs3uoN6M1obrc5RH9xBNE/zl8sSK+hE/wxU0lLU3sWbVgiJwBJ1M
	b+Py7Kq8E1TACZZ1gHbdA47uahMuoxZwUiWtGVaijhpn8AR3VqvzWoV7IdxuHnvu1kQ9
	i5XQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to
	:references:reply-to:organization:disposition-notification-to
	:return-receipt-to:mime-version;
	bh=R8KHMEAyY52HffCBJ1AYfVXA/qmKSvh0X3lVBcJwOo0=;
	b=Qd7YcKzdcQlO+xeTyZkRloMTaHei7p8Bv/10prJ06UiANc4PLLf1jTloqqM6nlvpED
	q5rdVCdIl6RwfALsKh+hX9kk7nWH/d30mIW3t3FG8Oj0BhBNHjWDxYmjDQF4iQgC00XV
	OKWZ1c50ChQzkLUdm/o0Q2up1xm7TuvKrpHVCayQIq2VBrn1IVmMWeCOPMJpmZKlSDTt
	CFiOCAvUcGFkbp+4BZH1WxVx/A+vHI5KyLg26+WTBC3DAnPzxW6oOhDtH1vWScmM8VWg
	l2hy6IndfG6I2Sd7OWgAYxwl98NIlHa9I9imv3+Bpc05zcICgAQBxlM7ppogidG1GLE8
	7wEw==
X-Gm-Message-State:	AOAM531G6d/TygPspYEXufVKrv31u+qzZbhS8/MzYtNhg5IaoWgmCza3
	VTTmblCoFRu8A+3AdlRVehYv/LaeTg==
X-Google-Smtp-Source:	ABdhPJwaRe933yIOmEUgx75MpionI1pxRdmbrefuSIEpMNXQmcDzJcn4A9m2pkGqYQI85d3VvWYHhw==
X-Received:	by 2002:a0c:f053:: with SMTP id b19mr2917805qvl.7.1617196428314;
	Wed, 31 Mar 2021 06:13:48 -0700 (PDT)
Date:	Wed, 31 Mar 2021 13:13:35 +0000
From:	"John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
To:	geda-help AT delorie DOT com
Subject:	Re: [geda-help] Re: Gschem segfaults
Message-Id:	<20210331131335.d8f625b883ac9235b8b8e418@gmail.com>
In-Reply-To:	<CACNnPR=v8xy3-7QF1Q20dAaVzk3Kv3=EtL4kH+=4Atc2FgQh6Q@mail.gmail.com>
References:	<xnh7nchcyj DOT fsf AT envy DOT delorie DOT com>
	<4b1d3d85-7f93-9eac-c4eb-9f84f2a47e61 AT bitflipper DOT ca>
	<CAMw9acBn7xNo5jvrvS6Dof6JtYgOOLVKJwFFTu93S+CoPszjHw AT mail DOT gmail DOT com>
	<20210225212042 DOT 16269 DOT qmail AT stuge DOT se>
	<20210226140333 DOT 7D5E78248737 AT turkos DOT aspodata DOT se>
	<20210226203024 DOT 8107 DOT qmail AT stuge DOT se>
	<20210226220140 DOT D69CD824873C AT turkos DOT aspodata DOT se>
	<20210302145834 DOT 24761 DOT qmail AT stuge DOT se>
	<20210302154815 DOT 39C3682475BD AT turkos DOT aspodata DOT se>
	<20210302185121 DOT 27316 DOT qmail AT stuge DOT se>
	<20210302200007 DOT E0E2082475BF AT turkos DOT aspodata DOT se>
	<20210303113537 DOT 9A3DA832CA61 AT turkos DOT aspodata DOT se>
	<CACNnPR=v8xy3-7QF1Q20dAaVzk3Kv3=EtL4kH+=4Atc2FgQh6Q AT mail DOT gmail DOT com>
Organization:	Toronto, Ontario
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.3)
Disposition-Notification-To:	jlmales AT gmail DOT com
X-Compose-Start-Epoch:	`date +%s`
Mime-Version:	1.0
Reply-To:	geda-help AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-help AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--Signature=_Wed__31_Mar_2021_13_13_35_+0000_2zs+mPLSBA0ul_n+
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

I have use gschem a number of times in past week with Debian
Buster.  Many times work is lost with gschem as it crashes
I assume.  What does happen is suddenly gschem disappears and
the work I had done was all lost.  this has occured a number of
times when creating parts.  I assume the disappear and loss of
edits on part is due to some form of gschem is not happy about
something.  I would think what OP discovered is similar to what
I have experienced, but I never ran schema from command line to
know what occurred with these many crashes I experienced.

I cannot imagine what would occur when working on a complex
schematic which was my end goal.  An end goal I am now questing
if I should move forward to create schematic and PCB I want to
create with schematic.   As result I have taken pause of using
gschem and considering alternatives to gschem and facing many
parts I now have to make again as not common parts for the
instrument project.


John L. Males
Toronto, Ontario
Canada
31 March 2021 09:13 -0400 EDT


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

2021-03-31 13:04:01+0000-UTC Time: 1617195841 PC/System time

31 Mar 13:04:01 ntpdate[65075]: ntpdate 4.2.8p12-a (1)

31 Mar 13:04:16 ntpdate[67900]: step time server 206.108.0.131
offset -0.003692 sec

FreeBSD 11.4-RELEASE-p3 FreeBSD 11.4-RELEASE-p3 #0: Tue Sep  1
08:22:33 UTC 2020
root AT amd64-builder DOT daemonology DOT net:/usr/obj/usr/src/sys/GENERIC=20

(Work in progress alternative to Linux Kernel of its own right,
 Debian, and
 other Linux based Kernel distributions determined.)

Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz
Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz (1396.86-MHz K8-class
CPU) Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz (1396.86-MHz
K8-class CPU) Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz
(1396.86-MHz K8-class CPU) Intel(R) Core(TM) i3-2367M CPU @
1.40GHz (1396.86-MHz K8-class CPU) Intel(R) Core(TM) i3-2367M
CPU @ 1.40GHz (1396.86-MHz K8-class CPU)

dev.cpu.0.temperature: 82.0C
dev.cpu.1.temperature: 83.0C
dev.cpu.2.temperature: 79.0C
dev.cpu.3.temperature: 78.0C
hw.acpi.thermal.tz0.temperature: 82.1C

vmstat -s:

538332549 cpu context switches
2031997789 device interrupts
355972848 software interrupts
2905459334 traps
2625220972 system calls
       27 kernel threads created
   400154  fork() calls
    54773 vfork() calls
     1410 rfork() calls
 68793594 swap pager pageins
194285929 swap pager pages paged in
 35378881 swap pager pageouts
196044966 swap pager pages paged out
  2397335 vnode pager pageins
 17034889 vnode pager pages paged in
     8977 vnode pager pageouts
     9212 vnode pager pages paged out
    64636 page daemon wakeups
1561679545 pages examined by the page daemon
     9087 clean page reclamation shortfalls
497600207 pages reactivated by the page daemon
 30529981 copy-on-write faults
    18539 copy-on-write optimized faults
292432830 zero fill pages zeroed
   467538 zero fill pages prezeroed
 69436917 intransit blocking page faults
3563567239 total VM faults taken
 67163633 page faults requiring I/O
        0 pages affected by kernel thread creation
 23013876 pages affected by  fork()
  2121635 pages affected by vfork()
    70500 pages affected by rfork()
2610007825 pages freed
3821853854 pages freed by daemon
1572397259 pages freed by exiting processes
  2315054 pages active
   691714 pages inactive
   300497 pages in the laundry queue
   704941 pages wired down
    40559 pages free
     4096 bytes per page
3251987002 total name lookups
          cache hits (81% pos + 4% neg) system 1% per-directory
          deletions 0%, falsehits 0%, toolong 0%

Boot time : 1605600247

procs     memory        page                    disks
faults        cpu0     cpu1     cpu2     cpu3 r b w     avm
fre  flt  re  pi  po    fr   sr ad0 pa0   in    sy    cs us sy
id us sy id us sy id us sy id 2 0 20 110168620  162100   307
43   6   3   225  135   0   0  175   226    46 29  7 65 29  6
65 28  7 65 28  7 65

memory info:

real memory  =3D 17179869184 (16384 MB)
avail memory =3D 16495013888 (15730 MB)

last pid: 76950;  load averages:  1.98,  1.87,  1.95  up
134+05:00:10    13:04:17 106 processes: 2 running, 103
sleeping, 1 zombie

Mem: 9044M Active, 2702M Inact, 1174M Laundry, 2754M Wired,
1379M Buf, 157M Free Swap: 48G Total, 14G Used, 34G Free, 28%
Inuse

hw.physmem: 17053859840
hw.usermem: 14166278144
hw.realmem: 17179869184

             total       used       free     shared
buffers     cached Mem:      16210872   13281996
2928876          0          0          0 Swap:     50331644
14398328   35933316

swapinfo:

Device          1K-blocks     Used    Avail Capacity
/dev/ada0s1b     50331644 14398328 35933316    29%

vmstat:

procs     memory        page                    disks
faults         cpu r b w     avm     fre  flt  re  pi  po
fr   sr ad0 pa0   in    sy    cs us sy id 2 0 20 110168620
161840   307  43   6   3   225  135   0   0  175   226    46
28  7 65


Message replied to:

Date: Wed, 31 Mar 2021 12:22:02 +0530
From: "Abhijit Kshirsagar (abhijit86k AT gmail DOT com) [via
geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> To:
geda-help AT delorie DOT com Subject: Re: [geda-help] Re: Gschem
segfaults


> Hello all,
>=20
> I'm having this exact problem on a fairly clean Ubuntu 20.04
> machine, and geda-gaf 1.10.2 built and installed from the
> tarball (error message below).
> The problem has started occurring after a recent package
> upgrade (dist-upgrade) some time in the last 2 weeks - gschem
> worked fine until then.
> I do not have any other version installed on this machine so
> I'm hoping this helps identify the problem. I have a couple
> of other machines where the same source was compiled on the
> same OS and it works there.
> I will run dist upgrade on all those to see which package
> breaks gshchem. If there is something else I can run / debug
> to help please let me know.
>=20
> [geda-gaf-1.10.2]
> >$ gschem
>=20
> (gschem:154416): Gdk-CRITICAL **: 12:19:07.605:
> IA__gdk_drawable_get_size: assertion 'GDK_IS_DRAWABLE
> (drawable)' failed
>=20
> ** (gschem:154416): CRITICAL **: 12:19:07.605:
> gschem_page_geometry_set_values: assertion 'screen_width > 0'
> failed
>=20
> (gschem:154416): Gdk-CRITICAL **: 12:19:07.605:
> IA__gdk_cairo_create: assertion 'GDK_IS_DRAWABLE (drawable)'
> failed Segmentation fault (core dumped)
>=20
>=20
> -Abhijit
>=20
> On Wed, 3 Mar 2021 at 17:12, karl AT aspodata DOT se [via
> geda-help AT delorie DOT com] <geda-help AT delorie DOT com> wrote:
> >
> > I tried to bisect and similar, but I get too many errors
> > like:
> >
> > *** error: gettext infrastructure mismatch: using a
> > Makefile.in.in from gettext version 0.18 but the autoconf
> > macros are from gettext version 0.19
> >
> > configure: error: you need Guile 2.2 (at least version
> > 2.2.4)
> >
> > so I'm giving up for the moment.
> >
> > Regards,
> > /Karl Hammar
> >
> >

--Signature=_Wed__31_Mar_2021_13_13_35_+0000_2zs+mPLSBA0ul_n+
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQQxRId2q5JPHFiozTr5X9dS0HpoEAUCYGR1gAAKCRD5X9dS0Hpo
EEV9AKCmOuRGnjxVXW18R8t5k0LLYb+YJgCgpsS33uJycFpdDx/8+71maqX5cs0=
=2NAz
-----END PGP SIGNATURE-----

--Signature=_Wed__31_Mar_2021_13_13_35_+0000_2zs+mPLSBA0ul_n+--

- Raw text -