delorie.com/archives/browse.cgi   search  
Mail Archives: geda-help/2021/03/31/10:57:10

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=mx++ieKOSWYeO7N4naMUKAiBT/bpcVYVLqjoTdGDdy8=;
b=FBv0yr63vUiJ/XFpaPmbRxWMkDFrbCJEObB2bd7zHoP5NYRup+GPlZ6HEth+hUKVUn
DoO9I5ChhPNYUYVd6S2lcHiSp9LGiFoL69PhWmWFNQzIecOfRQxCLWIzJiOZ1af/DnRj
PJsHNdsB3OVeRyIrH0PgknW68Ompf5M8N4x10dRyij5cCdOV60RLq/Dnf9TWUZDWbhQ5
3rbJMerxYaS0RwjlpEcRTXpsX2p7Wo0xyEfrEoREulqkbSRwd/UW3YJ7Lg6D4Szrqk5Q
b2xa1J3JihIi2WLu++FtLLhfiVdb1mcg5Qt3ruF/PyYbCqgZ0DldO/u1+tqwaBup7ts5
MgkA==
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=mx++ieKOSWYeO7N4naMUKAiBT/bpcVYVLqjoTdGDdy8=;
b=Hw1+Nbfo2JLxr4lImVT2/QCjWVZ9abmppLYPKYC3pFJ6XF+3eQau4n56F/2sK/keDw
O2jtq8iIKLtqHfIXN2LxFm42TZsXa0my7JJjN6TsQdFjLtDgqC+J7gMSwOe/BmzOlmHp
NAuPAQkWVtOLfOZSaP0fK2objesIKHDm5rii6Eqnxqx1t3q8aLO6/zHXP5UBBgyaJ6qO
djXxdGUCXwGWBhd8eM9D1Nr4ZHpwldrYhOHx4M1kQ/akRi28JGmv1DdOGnZnfNSVpCGk
ifAlYfPClhT5KNQrlEloiXTCSAnCI+7P2SQfFBs+u+qJociTm1Kula658Fwl5o6BhO6y
r7Zg==
X-Gm-Message-State: AOAM531SS9uedHovb14iP8y6U0IHlp88ap2MbwZlaIqBaYJXCBMmn1CG
XnRwkTOK8f6ll/ae2fiQSWZYLJLrzQ==
X-Google-Smtp-Source: ABdhPJwx2YCdE22CTbmzg1rHy0+zc1T3rt3SSfmtjY2CqIlAxGTIDngLHVuNK2/BkuRUKqbwl9VuZw==
X-Received: by 2002:a05:6214:4b3:: with SMTP id w19mr3422598qvz.26.1617202614531;
Wed, 31 Mar 2021 07:56:54 -0700 (PDT)
Date: Wed, 31 Mar 2021 14:56:41 +0000
From: "John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
To: Roland Lutz <geda-help AT delorie DOT com>
Subject: Re: [geda-help] Re: Gschem segfaults
Message-Id: <20210331145641.4f615c0a2a8ca34bdb16276b@gmail.com>
In-Reply-To: <alpine.DEB.2.21.2103311605450.5886@nimbus>
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>
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_14_56_41_+0000_ucc18/CZmf/k.HlW
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Roland,

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.

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.

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.

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.

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.

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.

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.


John L. Males
Toronto, Ontario
Canada
31 March 2021 10:56 -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 14:24:47+0000-UTC Time: 1617200687 PC/System time

31 Mar 14:24:47 ntpdate[36897]: ntpdate 4.2.8p12-a (1)

31 Mar 14:25:02 ntpdate[39466]: step time server 132.246.11.229
offset -0.004126 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: 76.0C
dev.cpu.1.temperature: 76.0C
dev.cpu.2.temperature: 74.0C
dev.cpu.3.temperature: 74.0C
hw.acpi.thermal.tz0.temperature: 76.1C

vmstat -s:

600432135 cpu context switches
2035004410 device interrupts
356150625 software interrupts
2926043786 traps
2739573562 system calls
       27 kernel threads created
   400313  fork() calls
    54781 vfork() calls
     1410 rfork() calls
 69061085 swap pager pageins
195056085 swap pager pages paged in
 35529529 swap pager pageouts
196650984 swap pager pages paged out
  2400515 vnode pager pageins
 17052261 vnode pager pages paged in
     8984 vnode pager pageouts
     9219 vnode pager pages paged out
    64742 page daemon wakeups
1680936614 pages examined by the page daemon
     9111 clean page reclamation shortfalls
503368650 pages reactivated by the page daemon
 30556312 copy-on-write faults
    18544 copy-on-write optimized faults
310398099 zero fill pages zeroed
   468002 zero fill pages prezeroed
 69706220 intransit blocking page faults
3584418718 total VM faults taken
 67428144 page faults requiring I/O
        0 pages affected by kernel thread creation
 23035420 pages affected by  fork()
  2121915 pages affected by vfork()
    70500 pages affected by rfork()
2633120901 pages freed
3828219415 pages freed by daemon
1585039224 pages freed by exiting processes
   125074 pages active
    41462 pages inactive
     4236 pages in the laundry queue
   719807 pages wired down
  3162186 pages free
     4096 bytes per page
3254093656 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 8719312 12648640   309
43   6   3   227  145   0   0  175   236    52 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: 50835;  load averages:  0.37,  0.48,  1.31  up
134+06:20:57    14:25:04 88 processes:  1 running, 87 sleeping

Mem: 489M Active, 162M Inact, 17M Laundry, 2812M Wired, 1554M
Buf, 12G Free Swap: 48G Total, 2207M Used, 46G Free, 4% Inuse

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

             total       used       free     shared
buffers     cached Mem:      16210872    3396440
12814432          0          0          0 Swap:     50331644
2259468   48072176

swapinfo:

Device          1K-blocks     Used    Avail Capacity
/dev/ada0s1b     50331644  2259468 48072176     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 8719296
12648444   309  43   6   3   227  145   0   0  175   236    52
28  7 65


Message replied to:

Date: Wed, 31 Mar 2021 16:12:03 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "John L. Males (jlmales AT gmail DOT com) [via
geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> Subject: Re:
[geda-help] Re: Gschem segfaults


> 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__31_Mar_2021_14_56_41_+0000_ucc18/CZmf/k.HlW
Content-Type: application/pgp-signature

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

iF0EARECAB0WIQQxRId2q5JPHFiozTr5X9dS0HpoEAUCYGSNqgAKCRD5X9dS0Hpo
EAxBAJ9tqw2UW3/ZBbdYa5IMLWNtXNDoXgCfe6T73RCkzsPehigZIBB0PldXJ5w=
=wlGt
-----END PGP SIGNATURE-----

--Signature=_Wed__31_Mar_2021_14_56_41_+0000_ucc18/CZmf/k.HlW--

- Raw text -


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