On Wed, 8 Sep 2021 17:35:12 +0900 Florian Schaefer <list...@netego.de> said:
> Seems to me to have been good last words this time. ;) So I am running > this all day now and I think I did not have a segfault due to procstat > so far. Thanks for the fixes and I like the new indicator icon. :) > > That being said, I still had some crashes today and I am thinking that > perhaps finally I might have something true to the topic of this thread. > At least it crashes within libnvidia and I do not get an ASAN trace. > > For what it's worth, I tried to record a trace as good as I can. > > https://pastebin.com/p41b7GKW > > This happens reproducibly when I change from X running E to the text > console and then back to the graphics screen. (I did quite a lot of > these switches lately for running gdb while E is stil crashed.) When I > have an "empty" E running it is fine. However, as soon as some window is > open it reliably segfaults upon returning to X. Any ideas? time to stop asan and use valgrind. that can at least say if the memory nvidia is accessing is beyond some array e provided - the shader flush basically has e provide a block of mem containing vertexes etc. for the gpu to draw. this array is expanded as new triangle are added then flushed to the gpu at some point during rendering. that might be the only thing i can think of that might be an efl bug - we use a dud pointer? but then you could figure this out from valgrind + gdb... maybe. valgrind would see the errant pointer and perhaps if its just beyond some other block of mem or if that block was freed recently etc. > Cheers > Florian > > On Tue, Sep 07, 2021 at 09:29:50PM +0100, Al Poole wrote: > > ok i pushed some changes as did raster...i seem to be running with asan and > > no problems...famous last words. > > > > On Tue, Sep 7, 2021 at 11:19 AM Al Poole <nets...@gmail.com> wrote: > > > > > Hey can you try this... > > > > > > > > > > > > On Tue, Sep 7, 2021 at 9:30 AM Al Poole <nets...@gmail.com> wrote: > > > > > >> Nah > > >> > > >> On Tue, 7 Sep 2021, 09:25 Florian Schaefer, <list...@netego.de> wrote: > > >> > > >>> It seems I was once again celebrating to early... > > >>> > > >>> > > >>> Not trying to pretend that I actually understand the logic behind the > > >>> changed line > > >>> > > >>> if ((n) && (*n) && (*n + 1)) eina_strbuf_append(buf, " "); > > >>> > > >>> it more importantly still leads to buffer overflows. > > >>> > > >>> > > >>> https://pastebin.com/gf6AppF1 > > >>> > > >>> > > >>> Am I lately the harbinger of bad news? ;) > > >>> > > >>> > > >>> Cheers, > > >>> > > >>> Florian > > >>> > > >>> > > >>> "Florian Schaefer" list...@netego.de – September 7, 2021 4:23 PM > > >>> > Excellent. Many thanks. :) > > >>> > > > >>> > > > >>> > Cheers, > > >>> > > > >>> > Florian > > >>> > > > >>> > "Al Poole" nets...@gmail.com – September 7, 2021 4:18 PM > > >>> > > Pushed. > > >>> > > > > >>> > > On Tue, Sep 7, 2021 at 8:11 AM Al Poole <nets...@gmail.com> wrote: > > >>> > > > > >>> > > > Thanks Florian, I didn't backport this to procstats...should have > > >>> a fix... > > >>> > > > > > >>> > > > On Tue, Sep 7, 2021 at 12:46 AM Florian Schaefer < > > >>> list...@netego.de> > > >>> > > > wrote: > > >>> > > > > > >>> > > >> I think we've got a second, independent issue with procstat here. > > >>> This > > >>> > > >> time it seems to me your friendly string-buffer overflow. > > >>> Incidentally > > >>> > > >> triggered by a long command line in terminology while compiling > > >>> the latest > > >>> > > >> enlightenment. ;) > > >>> > > >> > > >>> > > >> > > >>> > > >> pastebin.com/Ue03AbmB > > >>> > > >> > > >>> > > >> > > >>> > > >> Cheers, > > >>> > > >> > > >>> > > >> Florian > > >>> > > >> > > >>> > > >> > > >>> > > >> "Al Poole" nets...@gmail.com – September 6, 2021 1:22 AM > > >>> > > >> > Summoned > > >>> > > >> > > > >>> > > >> > On Sun, 5 Sep 2021, 14:12 Carsten Haitzler, < > > >>> ras...@rasterman.com> > > >>> > > >> wrote: > > >>> > > >> > > > >>> > > >> > > 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: 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 > > >>> > > >> > > > >>>>>> (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 > > >>> > 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
