| 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=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--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |