Re: [E-devel] eeze_scanner/enlightenment_f segfault

On Fri, 16 Apr 2021 23:38:53 -0700 Jose R R <[email protected]> said:

> On Fri, Apr 16, 2021 at 4:47 AM Carsten Haitzler <[email protected]> wrote:
> >
> > On Thu, 15 Apr 2021 18:52:42 -0700 Jose R R <[email protected]> said:
> >
> > > > > Niltze [Hello]-
> > > > >
> > > > > I have experienced some segfaults on March 11/12
> > > > >
> > > > > [ 9011.777974] eeze_scanner[4428]: segfault at 39 ip 00007fdccb8d59bd
> > > > > sp 00007ffc7e6c8f50 error 4 in libc-2.28.so[7fdccb873000+148000]
> > > > > [ 9011.777986] Code: 89 ee 48 89 df 5b 5d e9 11 fd ff ff 90 53 48 83
> > > > > ec 10 48 8b 05 4c 65 13 00 48 8b 00 48 85 c0 0f 85 88 00 00 00 48 85
> > > > > ff 74 73 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 37 48 8b 15 a8 63 13 00
> > > > > 64 48 83 [ 9011.778212] enlightenment_f[4426]: segfault at 39 ip
> > > > > 00007f3c2cf3d9bd sp 00007ffc993901e0 error 4 in
> > > > > libc-2.28.so[7f3c2cedb000+148000] [ 9011.778228] Code: 89 ee 48 89 df
> > > > > 5b 5d e9 11 fd ff ff 90 53 48 83 ec 10 48 8b 05 4c 65 13 00 48 8b 00
> > > > > 48 85 c0 0f 85 88 00 00 00 48 85 ff 74 73 <48> 8b 47 f8 48 8d 77 f0
> > > > > a8 02 75 37 48 8b 15 a8 63 13 00 64 48 83
> > > > >
> > > > > Today my USB mouse stopped working:
> > > > > [26821.338485] eeze_scanner[4803]: segfault at 56279c000000 ip
> > > > > 00007ffa8f8979ef sp 00007fff6cc3b5e0 error 4 in libc-2.28.so
> > > > > [7ffa8f835000+148000]
> > > > > [26821.338505] Code: a8 02 75 37 48 8b 15 a8 63 13 00 64 48 83 3a 00
> > > > > 0f 84 a5 00 00 00 48 8d 3d 5e 72 13 00 a8 04 74 0c 48 89 f0 48 25 00
> > > > > 00 00 fc <48> 8b 38 48 83 c4 10 31 d2 5b e9 b2 c6 ff ff 66 90 8b 15
> > > > > ae 68 13
> > > > >
> > > > > I opened a tty2 and
> > > > >
> > > > > killall -SEGV enlightenment
> > > > > (Attached .e-crashdump)
> > > > >[]
> > > > > Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
> > > >
> > > >
> > > > --
> > > > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > > > Carsten Haitzler - [email protected]
> > > >
> > > I continue to get those sefaults (from today's dmesg output)
> > > [ 6377.388742] enlightenment_f[4572]: segfault at 39 ip
> > > 00007fb99f0339bd sp 00007ffe597dcde0 error 4 in
> > > libc-2.28.so[7fb99efd1000+148000]
> > > [ 6377.388769] Code: 89 ee 48 89 df 5b 5d e9 11 fd ff ff 90 53 48 83
> > > ec 10 48 8b 05 4c 65 13 00 48 8b 00 48 85 c0 0f 85 88 00 00 00 48 85
> > > ff 74 73 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 37 48 8b 15 a8 63 13 00 64
> > > 48 83
> > > [ 6377.388830] eeze_scanner[4574]: segfault at 39 ip 00007f06efdd39bd
> > > sp 00007ffe658a9480 error 4 in libc-2.28.so[7f06efd71000+148000]
> > > [ 6377.388871] Code: 89 ee 48 89 df 5b 5d e9 11 fd ff ff 90 53 48 83
> > > ec 10 48 8b 05 4c 65 13 00 48 8b 00 48 85 c0 0f 85 88 00 00 00 48 85
> > > ff 74 73 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 37 48 8b 15 a8 63 13 00 64
> > > 48 83
> > >
> > > < http://www.enlightenment.org/ss/e-6078e3003333c4.42631337.jpg >
> > >
> > > Probably my next task is to refresh EFL/E by generating another build
> > > for Debian Buster backports GCC8 for AMD64...
> >
> > you need to figure out how to get core dumps produced - i suspect ulimit
> > config has disabled core dumps... that'll be a start. building efl and e
> > with asan enabled (use -Db_sanitize=address as a meson config option). this
> > will be best as it will give something pretty close to accurate.
> Well I am not a developer 'per se' so this represents a deviation from
> the usual expectations using a Window Manager.

it's not using. it's denbugging. you you used arch linux, i already created
efl-git-asan and enlightenment-git-asan AUR packages so:

yay -S enlightenment-git-asan

your do it for you (also yay -S efl-git-asan...). for debian you will have to
recompile efl and e and use that option to enable asan.

> > > notwithstanding, I have experienced stability issues, as well, in the
> > > most recently build of EFL/E for Debian Bullseye GCC10 for AMD64;
> > > i.e., sometimes when building a reiser4 -enabled kernel(s) -- a task
> > > that takes approximately couple of hours in this oldie Intel machine
> > > -- I will return and find an XDM login screen. Apparently EFL/E
> > > environment crashes and kicks me out (no dump file, either). I do not
> > > lose my partial kernel build due to the atomicity feature in reiser4,
> > > notwithstanding, it is annoying when it occurs.
> >
> > fyi unless the system literally hw crashed (like the equivalent of ripping
> > the power cord out with no battery) or kernel-oopsed (and an oops will not
> > get you back to a login screen -it'll be stuck in the oops), reiser will
> > have no effect/help. as long as the kernel keeps marching on, any
> > filesystem will work just fine even with no journalling because the kernel
> > keeps all file content in ram before it goes to disk. ext3, ext4, f2fs,
> > resier, xfs, btrfs, nilfs2 and some others will all do journalling and
> > essentially be just as stable as eachother in the face of "losing power or
> > a kernel oops/deadlock" when the kernel cant safely write out contents of
> > ram to disk.
> The design of reiser4
> < https://metztli.blog/amatl/reiser-nahui/reiser4-design >
> differs from that pack, with the possible exception of XFS.

Doesn't matter though. As I described. :)

> > your machine reboot or total hardware fault or just the xsession died? did
> > you check Xorg. 0.old ? (the log of the previous xorg run). did you have
> > stdout/error go to ~/.xsession-errors ? did you check it (log into a
> > vt/tty, cp ~/.xsession-errors to some other file then log in again and look
> > ait it). looked at dmesg to see if a segv was reported or oom killer or
> > something else? could it be overheating?
> Even when the machine was newer there have been endemic cases when
> even an accidental touch of a button triggered the EFL/E to log me out
> -- in real time.
>  did you try logging cpu temperature? i've literally
> > had problems with a gpu when its fan didn't run fast enough to cool - play a
> > game for a bit that's heavy enough and the kernel would reboot the system
> > with a temperature critical alert. mi literally improved the e temperature
> > module because of this making it possible to monitor gpu temps too (add
> > another temp gadget and select the gpu). I have a commandline tool that
> > dumps sensor info:
> >
> I have only monitored the machine temperature with the thermometer
> utility in E. During a kernel build procedure it may go within 80% to
> 90% -- it has never reached 100%

80- 90% of what? the min/max of the temp gadget are configurable temperatures.
that still doesn't mean it isn't overheating.

> > http://www.rasterman.com/files/hwmn.c
> >
> > a laptop running long builds - especially if old can easily have cooling
> > problems. dust collected in the tiny heat fins making the cooler much less
> > effective. bearings in fan going ad and dragging the fan to slower speeds,
> > thus long build causing lots of heat causing instability - could easily
> > cause cpu errors and memory errors that turn up as random crashes of things
> > because data corrupts.
> Well I have replaced the fan once due to a noticeable noise ( I gave
> the machine a thorough clean, too) but have not had similar issues
> ever since.
> It has got 16GB of aftermarket lifetime quality RAM. By experience in
> other machines I know what effect bad ram causes. This is not the
> case.
> Obviously, I do not engage (nor like, as a matter of fact) gaming but
> I do make substantial use of hardware virtualization to build my base
> images -- which are subsequently customized for Google Compute Engine
> (GCE)
> https://youtu.be/jfmHeV63Qho
>  -- as well as to lightly test my reiser4 minimal ISO/USB Debian Installers.

what you do isn't that important - as long as what you are doing is stressing
the system to cause a lot of heat. games are often a perfect case as they tend
to hammer cpu, ram and gpu.

but right now we don't know what is dying and why (an xorg crash, an e crash?
did something forcibly kill the xorg or e processes like the oom killer as you
ran out of memory and the oom killer just chose the process with the biggest
memory footprint to kill?)

> > > Ever since I switched ot E, I do not use any other window manager
> > > environment so I would not know if those bloated like GNOME and/or KDE
> > > are as unstable. Probably I will try WindowMaker in Bullseye to find
> > > out if behaviour is similar/else/not.
> > >
> > >  uname -a
> > > Linux huitzilopochtli 5.10.0-5+reiser4.0.2-amd64 #1 SMP Debian
> > > 5.10.26-2+reiser4.0.2 (2021-03-27) x86_64 GNU/Linux
> > >
> > > Best Professional Regards.
> > >
> > > P.S. I could build my kernels in the cloud -- in half-an-hour or so --
> > > by using rented computing power
> > > < https://metztli.blog/amatl/reiser-nahui/bullseye >
> > > so as not to stress EFL/E locally ;) but after a while it becomes
> > > somewhat expensive.
> > >
> > > --
> > > Jose R R
> > > http://metztli.it
> > > ---------------------------------------------------------------------------------------------
> > > Download Metztli Reiser4: Debian Buster w/ Linux 5.10.20 AMD64
> > > ---------------------------------------------------------------------------------------------
> > > feats ZSTD compression https://sf.net/projects/metztli-reiser4/
> > > ---------------------------------------------------------------------------------------------
> > > or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
> > > -------------------------------------------------------------------------------------------
> > > Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
> > >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - [email protected]
> >
> 
> 
> -- 
> Jose R R
> http://metztli.it
> ---------------------------------------------------------------------------------------------
> Download Metztli Reiser4: Debian Buster w/ Linux 5.10.26 AMD64
> ---------------------------------------------------------------------------------------------
> feats ZSTD compression https://sf.net/projects/metztli-reiser4/
> ---------------------------------------------------------------------------------------------
> or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
> -------------------------------------------------------------------------------------------
> Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - [email protected]