delorie.com/archives/browse.cgi   search  
Mail Archives: geda-help/2021/03/31/12:40:20

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--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019