On Sun, 5 Sep 2021 11:25:35 +0900 Florian Schaefer <list...@netego.de> said:
> OK, the ibox patch seemed to resolve this issue. > Thank you very much! :-) > > But. As you proposed I started to play with ASAN ... and opened quite a > can of worms apparently. E is now rather constantly crashing. I guess > this is because of the "abort_on_error=1" setting of ASAN and it's, > well, finding many memory leaks. So I hope we can squash them one by one. export ASAN_OPTIONS="detect_odr_violation=0:detect_leaks=0:abort_on_error=1:new_delete_type_mismatch=0" :) it will only barf on real memory erros - not smaller things that don't cause crashes. for leaks i'm more interested in using massif for that, but they wont cause crashes so those are "worry about another day" if anything. > First I want to say that I needed to add "log_path=asan.log" to the > ASAN_OPTIONS variable in order to have the asan output actually written > somewhere, so I would propose to add this information to the > enlightenment homepage. Most users nowadys probably don't start E from a > terminal where any stdout would be visible. actually i just redirect ALL stdout/err from e to ~/.xsession-errors so that handles it anyway :) you won't need to do the above special asan log if you're dloing that and i'd generally say it's a smart move. if you don't you can also check your journald logs from systemd etc. > So I tried to capture one of the crashes as best as I could with both > gdb and asan. This one seemed to be in the procstats module. The result > is here: https://pastebin.com/M6V2QTwd ooh procstats... i do not run that, so that probably explains why i don't see this... /me summons a netstar > Also, now E brings an additional error popup when returning from the > lock screen: "Authentication via PAM had errors setting up the > authentication session. The error code was 6." This did not happen > before the recompiling. So I was suspecting that this is somehow due to > ASAN so I tried to remove the ASAN_OPTIONS from the .xsessionrc. But it > seems that without this variable E won't even start now. I see the > processes in the process list but the screen remains just black. > Therefore back to ASAN it is. Also I could not find any related messages > in auth.log or similar. Very strange and somewhat unsettling. aaaah yes. i think error code is changing because asan detects something e.g. like a leak on shutdown of the ckpasswd slave binary thus making this not work. basically "don't rely on desklock to work right" if using asan. kind of a "gotcha". > Concerning the ACPI daemon. I see, this seems to be a "hard" requirement > of E then. Interesting design choice. For me personally running an ACPI It's a soft requirement. E works without BUT you will be missing events for things like: lid open/close, some power/reset buttons being pressed, ac adaptor plug/unplug ... e will check if your system has acpi at all - if it does it will want events from acpid to handle these. it may be you are lucky and don't need these (eg only have a power button - you already getkey press for it and no reset button, no lid, no ac adapter/battery), but e will basically insist this runs because you have these as possible events. it's a trivially small daemon to run and every distro i know of has it, so not much to just go do this. i added this because people complained e didn't suspend their laptop on lid close and it ended up they didn't follow the recommendation of having acpid to handle that. this is there because people don't follow docs so now it's pushing it on everyone to avoid things like a laptop in your backpack running and overheating and running your entire battery empty in a few hours. > daemon on a desktop system has exactly zero additional benefit. The > power button is handled by systemd just fine and I am happy for every actually it's not. e inhibits systemd handling this - always. no choice. when e runs system will ignore this. e is handling it. it can handle it either via a x11 power key press event OR an acpi button press. see above. :) > unnecessary daemon that I can prevent from cluttering my ps output. So, > anyway, for now I just commented out the callback to the popup. Works > great. ;-) see above. too many times people don't follow the recommendations, so now forcing it on everyone. i have considered adding acpi support to enlightenment_system that runs as root, but i haven't done that so until then ... you need acpid. :) > Cheers > Florian > > On 9/5/21 6:27 AM, Carsten Haitzler wrote: > > On Sat, 4 Sep 2021 17:52:09 +0900 Florian Schaefer <list...@netego.de> said: > > > >> On 9/4/21 4:55 PM, Carsten Haitzler wrote: > >>> On Sat, 4 Sep 2021 11:47:20 +0900 Florian Schaefer <list...@netego.de> > >>> said: > >>> > >>>> Raster, > >>>> > >>>> Thanks for the quick reply and help! > >>>> > >>>> OK, so ibox seems to be the culprit. With the module unloaded I was not > >>>> able to crash the system. That's quite interesting, on my personal > >>>> machine I am using ibox ever since and never had any issues (just like > >>>> your test yesterday). So this seems to be somehow specific to my new > >>>> system here. > >>>> > >>>> Anyway, thanks for pointing me into the right direction. With this I now > >>>> also finally understood how to identify which one of the many threads > >>>> was the segfaulting one. ;-) > >>>> > >>>> Now for the backtrace. As it is quite short I will paste it below > >>>> > >>>> ======================================== > >>>> (gdb) bt > >>>> #0 0x00007f23b417f872 in __libc_pause () at > >>>> ../sysdeps/unix/sysv/linux/pause.c:29 > >>>> #1 0x0000564440d159f7 in e_alert_show () at ../src/bin/e_alert.c:43 > >>>> #2 0x0000564440cda47a in _e_crash () at ../src/bin/e_signals.c:81 > >>>> #3 0x0000564440cda4a9 in e_sigseg_act (x=<optimized out>, > >>>> info=<optimized out>, data=<optimized out>) at ../src/bin/e_signals.c:91 > >>>> #4 0x00007f23b4180140 in <signal handler called> () at > >>>> /lib/x86_64-linux-gnu/libpthread.so.0 > >>>> #5 0x00007f23a57df211 in _ibox_icon_fill (ic=0x5644419a2910) at > >>>> ../src/modules/ibox/e_mod_main.c:636 > >>>> #6 0x00007f23a57df330 in _ibox_cb_icon_fill_timer (data=<optimized > >>>> out>) at ../src/modules/ibox/e_mod_main.c:526 > >>>> #7 0x00007f23b4c25581 in _ecore_call_task_cb (data=<optimized out>, > >>>> func=<optimized out>) at ../src/lib/ecore/ecore_private.h:456 > >>>> #8 _ecore_timer_legacy_tick (data=0x564441cbf230, event=0x7ffd43c61150) > >>>> at ../src/lib/ecore/ecore_timer.c:172 > >>>> #9 0x00007f23b3b1c130 in _event_callback_call (obj_id=0x400000379067, > >>>> pd=0x5644412371e0, desc=0x7f23b4c521e0 > >>>> <_EFL_LOOP_TIMER_EVENT_TIMER_TICK>, event_info=<optimized out>, > >>>> legacy_compare=legacy_compare@entry=0 '\000') at > >>>> ../src/lib/eo/eo_base_class.c:2114 > >>>> #10 0x00007f23b3b1c3ec in _efl_object_event_callback_call > >>>> (obj_id=<optimized out>, pd=<optimized out>, desc=<optimized out>, > >>>> event_info=<optimized out>) at ../src/lib/eo/eo_base_class.c:2186 > >>>> #11 0x00007f23b3b16620 in efl_event_callback_call (obj=<optimized out>, > >>>> desc=desc@entry=0x7f23b4c521e0 <_EFL_LOOP_TIMER_EVENT_TIMER_TICK>, > >>>> event_info=event_info@entry=0x0) at ../src/lib/eo/eo_base_class.c:2189 > >>>> #12 0x00007f23b4c26e15 in _efl_loop_timer_expired_call > >>>> (obj=obj@entry=0x40000000012d, pd=pd@entry=0x5644411fd460, > >>>> when=when@entry=436613.23437423998) at ../src/lib/ecore/ecore_timer.c:669 > >>>> #13 0x00007f23b4c26f43 in _efl_loop_timer_expired_timers_call > >>>> (obj=obj@entry=0x40000000012d, pd=pd@entry=0x5644411fd460, > >>>> when=436613.23437423998) at ../src/lib/ecore/ecore_timer.c:621 > >>>> #14 0x00007f23b4bf2fae in _ecore_main_loop_iterate_internal > >>>> (obj=obj@entry=0x40000000012d, pd=pd@entry=0x5644411fd460, > >>>> once_only=once_only@entry=0) at ../src/lib/ecore/ecore_main.c:2431 > >>>> #15 0x00007f23b4bf383f in _ecore_main_loop_begin > >>>> (obj=obj@entry=0x40000000012d, pd=pd@entry=0x5644411fd460) at > >>>> ../src/lib/ecore/ecore_main.c:1231 > >>>> #16 0x00007f23b4bf7e6d in _efl_loop_begin (obj=0x40000000012d, > >>>> pd=0x5644411fd460) at ../src/lib/ecore/efl_loop.c:57 > >>>> #17 0x00007f23b4bf7233 in efl_loop_begin (obj=0x40000000012d) at > >>>> src/lib/ecore/efl_loop.eo.c:28 > >>>> #18 0x00007f23b4bf390c in ecore_main_loop_begin () at > >>>> ../src/lib/ecore/ecore_main.c:1316 > >>>> #19 0x0000564440cb8c50 in main (argc=<optimized out>, argv=<optimized > >>>> out>) at ../src/bin/e_main.c:1121 > >>>> > >>>> (gdb) fr 5 > >>>> #5 0x00007f23a57df211 in _ibox_icon_fill (ic=0x5644419a2910) at > >>>> ../src/modules/ibox/e_mod_main.c:636 > >>>> 636 if ((ic->ibox->inst->ci->show_preview) && > >>>> (edje_object_part_exists(ic->o_holder, "e.swallow.preview"))) > >>>> > >>>> (gdb) list > >>>> 631 } > >>>> 632 > >>>> 633 static void > >>>> 634 _ibox_icon_fill(IBox_Icon *ic) > >>>> 635 { > >>>> 636 if ((ic->ibox->inst->ci->show_preview) && > >>>> (edje_object_part_exists(ic->o_holder, "e.swallow.preview"))) > >>>> 637 _ibox_icon_fill_preview(ic, EINA_FALSE); > >>>> 638 else > >>>> 639 _ibox_icon_fill_icon(ic); > >>>> 640 > >>>> > >>>> (gdb) print ic > >>>> $1 = (IBox_Icon *) 0x5644419a2910 > >>>> > >>>> (gdb) print *ic > >>>> $2 = {ibox = 0x564441cc3fe0, o_holder = 0x0, o_icon = 0x0, o_holder2 = > >>>> 0x0, o_icon2 = 0x0, client = 0x0, drag = {start = 0 '\000', dnd = 0 > >>>> '\000', x = 0, y = 0, dx = 0, dy = 128}} > >>>> > >>>> (gdb) print *(ic->ibox) > >>>> $3 = {inst = 0x40, o_box = 0xe1, o_drop = 0x564441a499b0, o_drop_over = > >>>> 0x7f23b4165cb0 <main_arena+304>, o_empty = 0x7474756200726162, > >>>> ic_drop_before = 0x81646c3698761235, drop_before = 1103904792, icons = > >>>> 0x0, zone = 0x698761254, dnd_x = 0, dnd_y = 1769170290} > >>>> > >>>> (gdb) print *(ic->ibox->inst) > >>>> Cannot access memory at address 0x40 > >>>> ======================================== > >>>> > >>>> So somehow we've got some garbage pointer in ic->ibox->inst. > >>> > >>> actualluy.. ic->ibox is junk. iut happens to point to some memory we can > >>> access but it's full of ... garbage. like dnd_y is and unrealistic coord. > >>> zone does not look like a proper pointer (o_drop does) and o_box is > >>> nothing like what a pointer should look like. drop_before seems junky > >>> too. so ... what happened to ic->ibox? or ... for that matter what > >>> happened to ic? maybe ic has been freed and now the ibox ptr has been > >>> overwritten to point to some junk as i cant imagine the ibox struct being > >>> freed as that struct is still there for the ibox gadget. so ... > >> > >> Ah I see. It certainly makes debugging easier if you know what a pointer > >> is supposed to look like. :-) > >> > >>> well turning on ASAN (search enlightenment.org for asan and how to enable > >>> it) in efl and e would probably instantly point out the problem. you can > >>> try that as an exercise in being able to divine better debug info from > >>> efl > >>> + e. it's pretty easy now with meson.... :) unlike valgrind it's not > >>> prohibitively slow either. it's usable day to day on a fast enough > >>> machine. > >> > >> Interesting. Thanks for the pointer to new debugging tools. (And yes, > >> valgrind is really slow.) I found the documentation you mentioned. I > >> think I will give it a try before applying your patch, just to see what > >> happens and to be able to play around with it for a bit. > >> > >>> and i can see the problem: > >>> > >>> ecore_timer_add(0.1, _ibox_cb_icon_fill_timer, ic); > >>> > >>> a timer is created to fill the icon in 0.1 sec... but ... imagine the icon > >>> (ic) has been freed/deleted BEFORE the timer fires... in 0.1sec from > >>> now. ... someone added a timer without remembering to delete it when the > >>> icon the timer is for is deleted! a bit sloppy... > >> > >> Bad boy. ;-) > >> > >> This means that on my old laptop I never ran into any issues because it > >> is just too slow for this race condition to occur? > >> > >>> d12acf0d01e628d71548adbb77670c7e40aef043 commit in git now fixes that. > >>> problem is in e ... not efl :) > >> > >> Great. Thanks! As said before, I will try to tackle this with ASAN first > >> for training and then see how your solution is holding up. That will > >> hopefully be tomorrow. > >> > >> Now to the second point of my first mail from yesterday: Is there any > >> way for me to disable/silence the error popup on startup that no ACPI > >> daemon is running? > > > > oh yes. install acpid and have it run. :) > > > >> Cheers, > >> Florian > >> > >>>> I tried to poke into the preceding frames (#6 and #7) but only hit > >>>> optimized out variables. This is efl territory, right? This morning I > >>>> recompiled enlightenment with "-O0 -g" but I guess I should also have > >>>> done the same to efl. Well, I can do this the next time I'm in office if > >>>> helpful. > >>>> > >>>> Any ideas? > >>>> > >>>> For now I gave ibar a try. Not exactly a replacement for me. I don't > >>>> need a launcher (using everything and favorites menu instead) or a > >>>> tracker of running windows (I know what windows I have open). I only > >>>> need something to show my minimized windows so that I can open them > >>>> again (I know, they appear with Alt+Tab...) and this seems to be the > >>>> only scenario that cannot be reproduced by ibar. -- I guess I never > >>>> bought into the MacOS style launcher bar. ;-) > >>> > >>> ibar will show both running and minimized icons for windows .. but ok - > >>> yeah - it doesnt "show only minimized"... :) > >>> > >>>> Cheers > >>>> Florian > >>>> > >>>> On 9/4/21 1:25 AM, Carsten Haitzler wrote: > >>>>> On Fri, 3 Sep 2021 21:04:35 +0900 Florian Schaefer <list...@netego.de> > >>>>> said: > >>>>> > >>>>> quick - if you unload the ibox module ... does the problem stop? that > >>>>> crash is inside ibox code - memory it's accessing is bad/wrong - why i > >>>>> don't know. not more information. like 363 in ibox is: > >>>>> > >>>>> if ((ic->ibox->inst->ci->show_preview) && > >>>>> (edje_object_part_exists(ic->o_holder, "e.swallow.preview"))) > >>>>> > >>>>> so what is ic? whats is ic->ibox, ic->ibox->inst, ic->ibox->inst->ci ? > >>>>> > >>>>> if you attach gdb when e crashes and dump these values - i'd know more. > >>>>> maybe. I actually stopped using ibox a while ago since ibar does both > >>>>> effectively these days. perhaps it is an ibox bug and i havent seen it > >>>>> as i dont use it. so try the above, if it goes away - attach gdb > >>>>> > >>>>> i can say that i dont see the problem here with ibox enabled and on amd > >>>>> + e (git). > >>>>> > >>>>>> Dear everyone, > >>>>>> > >>>>>> so I got a new desktop PC at work and the first thing I did, of course, > >>>>>> was to install Debian sid and enlightenment-git. ;-) > >>>>>> > >>>>>> The machine has a Nvidia T600 card and this is where troubles probably > >>>>>> begin. As I kind of need the graphics performance for CAD I went with > >>>>>> the drivers from Nvidia (the stock open source drivers were terribly > >>>>>> slow). > >>>>>> > >>>>>> Now what happens is that enlightenment crashes often. Like kind of > >>>>>> constantly. I got the impression it happens mostly when several windows > >>>>>> are going through their appearance fade-in transition at the same time. > >>>>>> Then the "red screen of death" appears and I need to press F1 to > >>>>>> continue. With some applications this happens always (Eagle anyone?) > >>>>>> with others only sometimes. After the forced restart many windows (e.g. > >>>>>> terminology always, firefox sometimes) need to be minimized and > >>>>>> uncovered again for their content to display again. Some dialog windows > >>>>>> won't even show their content from the beginning and instead just some > >>>>>> different portion of the screen. Needless to say that for a machine at > >>>>>> work this is not an optimal situation. > >>>>>> > >>>>>> The most pressing issue are of course the crashes. I recompiled > >>>>>> everything with debugging symbols and optimization disabled (or at > >>>>>> least I thought so, some things seem still to be optimized away) to > >>>>>> get some meaningful dumps. One of which I uploaded to pastebin > >>>>>> (https://pastebin.com/YWSarC10) hoping that it makes sense to someone. > >>>>>> > >>>>>> I am sure that it is not E that is "at fault" but Nvidia, but for now I > >>>>>> need to find a way around this so that I can work without having to > >>>>>> reset everything every five minutes. Any ideas? > >>>>>> > >>>>>> Oh, I also tried to disable OpenGL in the compositor settings and > >>>>>> choosing the software option. And it still crashes! > >>>>>> > >>>>>> For starters I was hoping that I can just switch off all the window > >>>>>> transition-fading eye-candy but I did not understand whether this is > >>>>>> possible. Is it? > >>>>>> > >>>>>> Finally, being a desktop system (my first in like 10 years or so) it > >>>>>> does not run an acpi daemon. I don't really see any reason to do so. > >>>>>> Therefore E also complains on every startup that no acpi daemon can be > >>>>>> found. I did not find any compile time or runtime options to disable > >>>>>> acpi. Is there a way to silence this error/warning? > >>>>>> > >>>>>> Cheers, > >>>>>> Florian > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> enlightenment-users mailing list > >>>>>> enlightenment-users@lists.sourceforge.net > >>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> enlightenment-users mailing list > >>>> enlightenment-users@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >>>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> enlightenment-users mailing list > >> enlightenment-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >> > > > > > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
