delorie.com/archives/browse.cgi | search |
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=TOuWYlQzqrJiHGRklHR5ZtcDv5xSQALw27P/xatmro4=; | |
b=C3XeNDS/2r9PrGalpQ3QMXOjQaOGsq3Tztu1Nm9wZHgk6OsGathAOIC4FBpw4MIdTJ | |
bp1soXMYkYP2yurexGj59CDG2KDc3kxNEYcyDR630pTdDLKPSBQ+UfEXiclFXM4mqwnb | |
M4oIPhdSxaC8jBNU/IvCNGdV8lSd3UNpWa/fvM5XuH4yLoNcsVZo9uATcx+u5ay+htiH | |
U358B0AU0ZKIQbXFavy2wx630sfcu1wcPfgzWw+eGbiGmQfYiqFauohZvIJgpb2hRnjR | |
JaymttgB96vuMbRZc9gAqTY/El0LN1ty7BehQHkpIHxc0RzoJH4PB+QFnBp/U1HO54Eu | |
GF+A== | |
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=TOuWYlQzqrJiHGRklHR5ZtcDv5xSQALw27P/xatmro4=; | |
b=AZmMG+ZL2ItwGw/kn4ma8Ub73mChicY/YMaQAeps6Zie+iAGN/hBtbOHuKl2/l9L8D | |
ZYF8zz54BxNvL3+w7TsjnAMid/sKFXIlS6B5wLLsf1+uqhWPgyN2q4KCYX7otRCRHOzL | |
wWcAoEDTC+OUfFWDik/tDEADLmiMCh0o773Wm3kq8aP5CRsribC+xDHIye6IDKv+4FdT | |
7pByE0VH8nbgFnObQdLCoCgsz+WHGm1tyWH6x/zNQT4jtXslDsc/nXFgWYs8hBOuxxOL | |
uaBgqnO/n7/vYsBRbHHh7Pfij4h2/hihZ0sORb/AVsJ8YJu8CbcFCTJh2RqWB858Fz2m | |
rRxQ== | |
X-Gm-Message-State: | AOAM53104fCWhR3DgAcGQVgon+DN7cB9n7+iLIMAYpHt7kb6bBiPXT3Y |
fZ7Z1/1plAzjc/ida5X7wJz0JxTdWg== | |
X-Google-Smtp-Source: | ABdhPJyMIF6osUJKRdezbkcDSFDaruN1e9U5cgoMAwgrIZhi0NJ6Uy8zi4O1Xg4hXMNOIVyFZDHQlw== |
X-Received: | by 2002:a37:5f04:: with SMTP id t4mr3880339qkb.440.1617208791741; |
Wed, 31 Mar 2021 09:39:51 -0700 (PDT) | |
Date: | Wed, 31 Mar 2021 16:39:39 +0000 |
From: | "John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> |
To: | John Doty <geda-help AT delorie DOT com> |
Subject: | Re: [geda-help] Gschem segfaults |
Message-Id: | <20210331163939.7f0e056b76c0cd9f96e651a2@gmail.com> |
In-Reply-To: | <348D497F-774A-41C4-8070-478894FA569C@noqsi.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> | |
<20210331131335 DOT d8f625b883ac9235b8b8e418 AT gmail DOT com> | |
<alpine DOT DEB DOT 2 DOT 21 DOT 2103311605450 DOT 5886 AT nimbus> | |
<20210331145641 DOT 4f615c0a2a8ca34bdb16276b AT gmail DOT com> | |
<348D497F-774A-41C4-8070-478894FA569C AT noqsi 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_16_39_39_+0000_mVYcQja3S=Un9jsn Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John, I understand the "should" of autosaved. I had a long long career of being asked why something was not doing what "should". My response was if it was known why was not doing what "should" then there would be no issue doing what should as it would be known why. When the why is known then the should do as should will work. Ergo why Ronald asked if I could duplicate or advise how Ronald could duplicate the issue. Knowing the why not does what should, i.e. duplicate the issue, allows the developer to see the issue and determine the solution. That can include the issue is in code that gschem is calling or partly. So 100% what Roland asked and why makes 100% sense which sadly some problems take some time to find how to duplicate so can be given to developer to investigate. I suspect your system you use receives many many fixes of issues others have had, but collectively most have not experienced the issue, yet some have and a real issue was found and fixed. That means the should may only not being should for a select few and still a real bug that has to be fixed. This is more common than a bug that affects most people as those types of bugs have immediate and full visibility, occurrence is infrequent, but when do the impact is clear and immediate and did not occur from developer point of view prior to release. I understand the should and that likely many are having the should have the backup of what was near last change. I can tell you from experience there are some common points of failure why this occurs. It is far from isolated to gschem. I know as I have seen such occur time and time again in many applications I use and have fell victim to again and again. The root cause at code level is any possible number of a couple handful of coding reasons these types of situations occur and looming in alot of applications. I see first hand applications that are doing as should then over time slowly not doing the common and less common should for many complex reasons that have not been vetted in code. I know as I have lots of experience explaining to clients why what needs to be tested and why required. Suffice to say I have seen some very serious system failures and data loss of very large complex systems as result you do not want to know. I have recently had a few serious same bugs in different (not different versions and tested at times different versions as part of investigation, but different) "C" compilers and/or only one of the compilers for compiling exactly same code. I thought in these instances I had made some sort of coding error, especially when all compilers failed same way. Turned out after days/weeks if investigations it was not my code, but the compiler code generated was flawed. Once I knew was not my code at fault I find a way to solve or work around the bugs. Often simple and unnecessary. Other times when works with one compiler and not other turns out to be very serious and not good assumptions compiler makes in code compiler generates such that was making a coding error. Again all about "should", did not do as should, and finding out cause (in this case compiling code with different compilers), and then way to work about the issue. I write code for me, and never did as career that started in assembler with Operating Systems and Compilers in High School on IBM commercial system with core memory. Yes real iron core memory with lots of very very fine wires through each iron core. One core per one bit of system core memory.=20 John L. Males Toronto, Ontario Canada 31 March 2021 12:39 -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 16:06:06+0000-UTC Time: 1617206766 PC/System time 31 Mar 16:06:06 ntpdate[59168]: ntpdate 4.2.8p12-a (1) 31 Mar 16:06:21 ntpdate[60916]: step time server 206.108.0.131 offset +0.002209 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: 72.0C dev.cpu.1.temperature: 73.0C dev.cpu.2.temperature: 70.0C dev.cpu.3.temperature: 70.0C hw.acpi.thermal.tz0.temperature: 73.1C vmstat -s: 617777893 cpu context switches 2038065094 device interrupts 356334027 software interrupts 2926403267 traps 2761234924 system calls 27 kernel threads created 400571 fork() calls 54791 vfork() calls 1410 rfork() calls 69067032 swap pager pageins 195068373 swap pager pages paged in 35529529 swap pager pageouts 196650984 swap pager pages paged out 2402655 vnode pager pageins 17097267 vnode pager pages paged in 8985 vnode pager pageouts 9220 vnode pager pages paged out 64742 page daemon wakeups 1682283394 pages examined by the page daemon 9111 clean page reclamation shortfalls 503368650 pages reactivated by the page daemon 30577051 copy-on-write faults 18549 copy-on-write optimized faults 310611268 zero fill pages zeroed 468002 zero fill pages prezeroed 69712280 intransit blocking page faults 3585122350 total VM faults taken 67434790 page faults requiring I/O 0 pages affected by kernel thread creation 23047417 pages affected by fork() 2122265 pages affected by vfork() 70500 pages affected by rfork() 2633666446 pages freed 3828219415 pages freed by daemon 1585107707 pages freed by exiting processes 131452 pages active 141954 pages inactive 4203 pages in the laundry queue 729145 pages wired down 3046011 pages free 4096 bytes per page 3254788369 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 0 0 22 9064408 12183984 309 43 6 3 227 145 0 0 176 238 53 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: 70446; load averages: 0.15, 0.21, 0.21 up 134+08:02:15 16:06:22 91 processes: 1 running, 90 sleeping Mem: 514M Active, 555M Inact, 16M Laundry, 2848M Wired, 1554M Buf, 12G Free Swap: 48G Total, 2161M Used, 46G Free, 4% Inuse hw.physmem: 17053859840 hw.usermem: 14067113984 hw.realmem: 17179869184 total used free shared buffers cached Mem: 16210872 3459168 12751704 0 0 0 Swap: 50331644 2212872 48118772 swapinfo: Device 1K-blocks Used Avail Capacity /dev/ada0s1b 50331644 2212872 48118772 4% 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 0 0 22 9064392 12183956 309 43 6 3 227 145 0 0 176 238 53 28 7 65 Message replied to: Date: Wed, 31 Mar 2021 11:33:17 -0400 From: John Doty <jpd AT noqsi DOT com> To: "Torben Friis (friistf AT gmail DOT com) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> Subject: Re: [geda-help] Gschem segfaults >=20 > > On Mar 31, 2021, at 10:56 AM, John L. Males > > (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com] > > <geda-help AT delorie DOT com> wrote: > >=20 > > 99% of time the work is completely lost. This includes when > > editing for several minutes. >=20 > Even if you haven?t saved your work, there should be an > autosave file. Some versions of gEDA or lepton put it in the > working directory with a name #something.sch#, while some put > it in /tmp/gschem.savesomething.sch. >=20 >=20 > John Doty Noqsi Aerospace, Ltd. > jpd AT noqsi DOT com >=20 >=20 >=20 --Signature=_Wed__31_Mar_2021_16_39_39_+0000_mVYcQja3S=Un9jsn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQxRId2q5JPHFiozTr5X9dS0HpoEAUCYGSlywAKCRD5X9dS0Hpo EDWnAKCbeJbkdznMapIn1XT8x7Hd+jXmIQCeMtnex30blZYtjZ4lpSNwVdiw47E= =GVXh -----END PGP SIGNATURE----- --Signature=_Wed__31_Mar_2021_16_39_39_+0000_mVYcQja3S=Un9jsn--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |