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=paP315CKPbInkdoX+th1LPUeuOPB6QxNb7KVMVq4Bx0=; b=s/2kpTeMWs7S+vKiBLBiv6FDznxPCyaEM2NYYuAnXKgWqHCOV+JcQ9wDQ/9c4GDiK0 cJYn5xF/XrAwrwvuc/ByoS4j233rZFHlu4v6P6AfeyvJ+mXqQsYJlzlEuOu90jkn+l3N BcdUjKdDEZOusLlA7LIkywE1nuvZpMITXbD2xzLbcPQnaTjV2Sfqmhr8je4uykkOTtSV w7+EFVmGFhyWkGjmmRZCTZvs3h9a/vgqdwlipToSGTZtsjvmommK65hgpZcK4qABb8Mi MENL3uHi8QDDhHCNGPnIQOiU2+FWR2COzlPg219w1teOSYaJ98saEmKJnKabDv//k9Ss vBWA== 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=paP315CKPbInkdoX+th1LPUeuOPB6QxNb7KVMVq4Bx0=; b=ZjJ17XEWcxgz4qccki+7TE5u3dGi0r3sV4TwHoAc+vBNXpBakoFcDY09TYg/zONtuC zU6nkWDqPHZfu/3mi58KjzylUnv0CCjdVRUtXYSInTt0bNiPM4NsjR60W2xLEhq1q/Cy PWZD1tW6/7HLnjOd/mvSAhvqXC2807EjDUHGLvEV7JJ3t5+RtUZYN0h/MNW+yleB1Ovz uykObm8AmOC0v4/d3PC1iqQQWzZ97bX6k5fgubUWpGWM36Ca79QBg9cESdr2L+Hu80M8 4MFHjCbO9x3E2kXasSDCEY0f0I05dMEzr/aaBJ2NrbSq01hiVBeCoV17SAU0MoEZRKY3 X4GQ== X-Gm-Message-State: AOAM532H4B+v+Rp57DcIvNFjKPZK9HnQM07jzBvRFB6om3Gwe/SyjdHw qyuy7lzWjgQ9vC9DJW1MCZ254yl0r/Lv X-Google-Smtp-Source: ABdhPJyrg17ZQ79aXp3Qd+4gUa60DEs0wbNCmTY5UXSOHOXISysGH6eoEMYs5KU9ZGya7ekYqYthoQ== X-Received: by 2002:aed:30e6:: with SMTP id 93mr2090396qtf.41.1624422985409; Tue, 22 Jun 2021 21:36:25 -0700 (PDT) Date: Wed, 23 Jun 2021 04:36:07 +0000 From: "John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com]" To: Roland Lutz Subject: Re: [geda-help] Re: Gschem segfaults Message-Id: <20210623043607.4ed1ea3817bf406660aab4b9@gmail.com> In-Reply-To: <20210331145641.4f615c0a2a8ca34bdb16276b@gmail.com> References: <4b1d3d85-7f93-9eac-c4eb-9f84f2a47e61 AT bitflipper DOT ca> <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> <20210331131335 DOT d8f625b883ac9235b8b8e418 AT gmail DOT com> <20210331145641 DOT 4f615c0a2a8ca34bdb16276b AT 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 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__23_Jun_2021_04_36_07_+0000_dOpuDtNX0UicBrLG" 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 Precedence: bulk --Signature=_Wed__23_Jun_2021_04_36_07_+0000_dOpuDtNX0UicBrLG Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Roland, I have been trying different EDAs for schematic capture and seems gschem has some enduring qualities I like I have not seen with other Open Source EDAs for schematic capture. I have searched and for some reason the Debian distributions are stuck on 1.8.2 from September 2013 for reason unknown. As FYI when I tried xschem is also crashed random like gschem 1.8.2 on Debian. I just finished ./configure, make, make install with geda-gaf-1.10.2 after I discovered how many many many many changes and fixes since 1.8.2 have occurred to 1.10.2. when I trid to execute gschem an error is returned. The error is "gschem: error wile loading shared libraries: libgedacairo.so.1: cannot open shared object file: no such file or directory". Di dI miss something I was supposed to do or is there an bug in the make install? System this was compiled on was a Live Debian Buster based system and not compiled on the FreeBSD system this eMail is being sent from. John L. Males Toronto, Ontario Canada 23 June 2021 00:36 -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-06-23 04:01:30+0000-UTC Time: 1624420890 PC/System time 23 Jun 04:01:30 ntpdate[36371]: ntpdate 4.2.8p12-a (1) 23 Jun 04:01:45 ntpdate[36621]: step time server 206.108.0.133 offset +0.000885 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) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 94.1C: resuming previous clock speed (1400 MHz) acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz acpi_tz0: temperature 95.1C: decreasing clock speed from 1400 MHz to 1300 MHz dev.cpu.0.temperature: 85.0C dev.cpu. 1.temperature: 85.0C dev.cpu.2.temperature: 80.0C dev.cpu. 3.temperature: 80.0C hw.acpi.thermal.tz0.temperature: 84.1C vmstat -s: 4073922859 cpu context switches 562135947 device interrupts 132084395 software interrupts 3297714639 traps 4114165075 system calls 29 kernel threads created 114922 fork() calls 16448 vfork() calls 30 rfork() calls 27669679 swap pager pageins 75213249 swap pager pages paged in 13518517 swap pager pageouts 68077320 swap pager pages paged out 702198 vnode pager pageins 4689137 vnode pager pages paged in 5314 vnode pager pageouts 48953 vnode pager pages paged out 22618 page daemon wakeups 3512408256 pages examined by the page daemon 2732 clean page reclamation shortfalls 1578322400 pages reactivated by the page daemon 9888583 copy-on-write faults 7364 copy-on-write optimized faults 2492575084 zero fill pages zeroed 504529 zero fill pages prezeroed 27934919 intransit blocking page faults 3425730733 total VM faults taken 27392122 page faults requiring I/O 0 pages affected by kernel thread creation 7545848 pages affected by fork() 576421 pages affected by vfork() 1500 pages affected by rfork() 3159305699 pages freed 1332814597 pages freed by daemon 3680322897 pages freed by exiting processes 967686 pages active 1712828 pages inactive 580083 pages in the laundry queue 701321 pages wired down 90847 pages free 4096 bytes per page 1103530110 total name lookups cache hits (80% pos + 5% neg) system 1% per-directory deletions 0%, falsehits 0%, toolong 0% Boot time : 1621053554 procs memory page disks faults cpu0 cpu1 cpu2 cpu3 r b w avm fre flt re pi po fr sr md10 ad0 in sy cs us sy id us sy id us sy id us sy id 0 0 0 86431096 363340 1017 469 8 4 938 1043 0 0 167 1222 1210 30 7 63 30 6 63 30 7 63 30 7 63 memory info: real memory =3D 17179869184 (16384 MB) avail memory =3D 16495013888 (15730 MB) last pid: 38052; load averages: 1.46, 2.07, 1.88 up 38+23:22:32 04:01:46 120 processes: 1 running, 118 sleeping, 1 zombie Mem: 3781M Active, 6691M Inact, 2266M Laundry, 2740M Wired, 1554M Buf, 354M Free Swap: 48G Total, 3089M Used, 45G Free, 6% Inuse hw.physmem: 17053859840 hw.usermem: 14181081088 hw.realmem: 17179869184 total used free shared buffers cached Mem: 16210872 8996300 7214572 0 0 0 Swap: 50331644 3163288 47168356 swapinfo: Device 1K-blocks Used Avail Capacity /dev/ada0s1b 50331644 3163288 47168356 6% vmstat: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr md10 ad0 in sy cs us sy id 0 0 0 86431096 363104 1017 469 8 4 938 1043 0 0 167 1222 1210 30 7 63 On Wed, 31 Mar 2021 14:56:41 +0000 "John L. Males" wrote: Subject: Re: [geda-help] Re: Gschem segfaults To: Roland Lutz CC:=20 MessageID: 20210331145641 DOT 4f615c0a2a8ca34bdb16276b AT gmail DOT com > Roland, >=20 > 99% of time the work is completely lost. This includes when > editing for several minutes. The editing several minutes is > not so much that many edits as is time takes and often flipping > to data sheet as part of process as work on pin by pin. >=20 > In terms of being able to reproduce there is no way to > reproduce the issue. I understand your asking to reproduce and > makes 100% sense. The issue is this type of bug is what I call > difficult to reproduce. I have a extensive Software > Engineering QA/Problem analysis background and I have solved > issues engineering teams cannot in sense of find what takes to > reproduce problems, some existed for few years, some only occur > once every month to three months, et al. So I understand the > need to reproduce to solve. This bug or buts falls in bug > class of averages of occurrences and is like very timing > related to the code and APIs. IF I was to hedge my guess there > is some point(s) in code where RC codes are not checked or a > code returned no in return code checked for likely cause of > issue. That does not mean this is a gschem bug or may mean it > is part a gschem bug and part an API called by gschem. >=20 > Some of the instances the crash has occurred are moving a box > of the symbol to change size, including just clicking on the > box with intent to move. Clicking on a text attribute to > edit, clicking on element propensities such as connection, > component name, an attribute of the part, selecting from > attributes an attribute to add, entering attribute value such as > document, deleting an attribute, or selecting an attribute > before can enter value of the attribute, selecting item like pin > and such to move or copy, et al. In essence any type of edit > action one can do. The symbol editing process I use is one > where I find a part that might be close to what I need or at > least can use a s base for new part, copy that part to a > director within home, then use gschema to edit part. Opps I do > use the command line to edit the part, sorry I forgot I did and > just remembered now. My apologies, so there are messages like > the OP noted, I did not save those messages as I was giving up > with schema. Often with any application run via command line > there are often messages, many often not good in my opinion, > but I never report as seems as whole nobody want to track down > the issue. >=20 > I have tired with reporting more serious and repeatable bugs as > I am constantly challenged that bug is not valid, which was > likewise very common over my many years in IT software > engineering that sadly took alot of time and effort to prove > otherwise where I could recreated the bug at will. >=20 > I can try to create a new symbol for sake of creating new > symbol to see what messages are issues to console when run > gschem from command line. It may be several days to several > weeks as that system took an all too familiar side trip that can > take hours to weeks to get out of. Very familiar to me and has > been an issue for many years. Another system has been in > familiar side trip for 4 weeks now. These side trips are not > related to gschem at all, i.e. not in any way. These side trip > issues I had reported many years ago and just ignored as not > possible. So I gave up trying to report and will just wait > until crap hits fan on own for the cause of the issues. >=20 > So in meantime it may be a while before I can even attempt to > see what messages occur and provide in case a give hint of > issues. >=20 > In mean time I would suggest trying to use gschem from command > line and see what happens in terms of messages. Best approach > likely do via a Live Debian Buster that uses LXDE, not LXQT, and > install gEDA and see what may occur based on how I create > gschem parts. >=20 >=20 > John L. Males > Toronto, Ontario > Canada > 31 March 2021 10:56 -0400 EDT >=20 >=20 > =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 >=20 > 2021-03-31 14:24:47+0000-UTC Time: 1617200687 PC/System time >=20 > 31 Mar 14:24:47 ntpdate[36897]: ntpdate 4.2.8p12-a (1) >=20 > 31 Mar 14:25:02 ntpdate[39466]: step time server 132.246.11.229 > offset -0.004126 sec >=20 > 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 >=20 [snip] >=20 >=20 > Message replied to: >=20 > Date: Wed, 31 Mar 2021 16:12:03 +0200 (CEST) > From: Roland Lutz > To: "John L. Males (jlmales AT gmail DOT com) [via > geda-help AT delorie DOT com]" Subject: Re: > [geda-help] Re: Gschem segfaults >=20 >=20 > > On Wed, 31 Mar 2021, John L. Males (jlmales AT gmail DOT com) [via=20 > > geda-help AT delorie DOT com] wrote: > > > Many times work is lost with gschem as it crashes I assume. > >=20 > > gschem should be able to recover your work up until > > practically the moment of the crash from the autosave files, > > so no work should be lost even in a situation like this. > > Does this not work for you? > >=20 > > > What does happen is suddenly gschem disappears > >=20 > > In order to fix the crash, I need to be able to reproduce > > it. Can you provide me with a series of actions that > > reliably triggers the problem? > >=20 > > Roland > >=20 --Signature=_Wed__23_Jun_2021_04_36_07_+0000_dOpuDtNX0UicBrLG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQxRId2q5JPHFiozTr5X9dS0HpoEAUCYNK6NwAKCRD5X9dS0Hpo EC9EAJ9acGevDH7poCHNWkeLBqVoWumMTwCfb84w+/ZteugGpi+ipluwgbcQy1Q= =jJc3 -----END PGP SIGNATURE----- --Signature=_Wed__23_Jun_2021_04_36_07_+0000_dOpuDtNX0UicBrLG--