Mail Archives: geda-help/2021/06/23/00:37:12
--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" <jlmales AT gmail DOT com> wrote:
Subject: Re: [geda-help] Re: Gschem segfaults
To: Roland Lutz <geda-help AT delorie DOT com>
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 <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
>=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--
- Raw text -