On Thu, 9 Sep 2021 09:20:28 +0900 Florian Schaefer <list...@netego.de> said:
> On Wed, Sep 08, 2021 at 11:08:00AM +0100, Carsten Haitzler wrote: > > 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. > > So there are things that valgrind can that asan cannot. More stuff to > learn. :) Yeah. Valgrind is actually a cpu interpreter. it literally interprets every instruction and while doing that tracks memory state. it also traps malloc/free and so on too and tracks what memory has been allocated, freed down to the byte, if it has been written to or not etc. - doing qll of this is can see every issue. it may have no DEBUG to tell you more than "code in this library causers problem X", or with full gdb debug it can use that memory address to tell you the file, line number, function name and so on too. This is why valgrind is slow. it's literally interpreting everything a process under valgrind does. Asan has the compiler do the above instead. So when the compiler generates the binary code for an application or library, it ADDS code that runs natively that does tracking. This means tat simple instructions that just do add/sub/compare etc. just get generated as normal. instructions that access memory get tracking code added like valgrind. this means only the code that the compiler generates will get tracked (e.g. efl and enlightenment), and other code that efl calls (stuff in libc, libjpeg, opengl libs etc.) will not be. this is a major difference in design and makes asan massively faster. it's actually usable day to day on a decently fast machine. it does mean e uses a lot more memory as asan needs extra memory in the process to do the tracking of every byte and its history and it does need to execute more instructions whenever reading/writing to some memory etc. ... but not all the code your cpu runs will have this extra work because it's only these actions and any libraries called that do not have asan build will also not do this extra work. thus - asan can't find anything in a library you did not build with asan support. thus sometimes you still have to pull out ye-olde valgrind. valgrind is an amazing tool. it's just slow. if you seem to have issues in e/efl the first port of call is to try asan. it's fast enough to run day to day and not very intrusive in that you can rebuild efl+e and then just ctrl+alt+end to restart e and presto - asan is on. as long as you have pre set-up a proper ASAN_OPTIONS env var ... also i suggest you: export EINA_FREEQ_TOTAL_MAX=0 export EINA_FREEQ_MEM_MAX=0 export EINA_FREEQ_FILL_MAX=0 as well. this may make e/efl a little more crashy and will also remove a minor optimization (freeq is a ... free queue - it takes things that need to be freed and adds them to a queue to free some time later = freeq will collect things to free up until some limit. it will, when items are added to the queue, fill their memory with some pattern like 0x555555 or 0x777777 etc. - or well up to the first N bytes of that memory object, and then when it actually does the free later will check that that pattern still is there. if it's not, something wrote to that memory that SHOULD have been left alone as the object was queued to be freed - it can give you an indication that something is wrong but not exactly where). as freeq waits until the app is idle (has nothing to do but wait for input or things to happen) it runs through the queue then freeing objects so avoiding the work of the free until then. it's an efl self-check mechanism put in to hunt down bugs and get a little optimzation in return for the extra work it has to do. by setting the above to zero you basically disable freeq and force it to free immediately which is what you want for both valgrind and asan so they detect the problems right. note efl knows when it runs under valgrind and auto disables freeq on its own. but with asan, it does not. i hope that helps explain the above (roughly - i glossed over a lot of details to make it easier to explain in a short amount of time) > Anyway, I tried to follow the debugging instructions on E.org as good as > I can (after having finally recompiled everything without asan, but > leaving the debugging symbols in place). > > Three observations: > > 1. The valgrind option --db-attach seems to be deprecated since 2015 and > is not avaiable any more. So I just omitted this. I hope that's fine. i know. :( you now need a separate shell running gdb to attach gdb to the process then tell it to run. painful. :( > 2. Then I tried to use the ".xinitrc-debug" method. Upon starting E the > startup apparently went into an infinite loop, generating pages and > pages of valgrind and E startup messages (a few valgrind messages with > something-something exiting 0) and generating many 120MB core dumps. So > I never got to the point where I would actually get anything but a black > screen from X. aaah with valgrind you want to probably bypass enlightenment_start - this means any issue will drop you out of your login session but you will have a chance to debug it. to avoid enlightenment_start do: export E_START=1 valgrind --tool=memcheck ... enlightenment FYI when i valgrind i do: valgrind --suppressions=$HOME/.zsh/vgd.supp --tool=memcheck --num-callers=64 --show-reachable=no --read-var-info=yes --leak-check=yes --leak-resolution=high --undef-value-errors=yes --track-origins=yes --vgdb-error=0 --vgdb=full --redzone-size=512 --freelist-vol=100000000 :) the suppressions file is a file i keep to tell valgrind to ignore that issue - e.g. it's a common optimization in libc or freetype or something that it should just pretend is not an issue. you can drop that option because you won't maintain that file and that file is highly system specific. > 3. Then I tried it again, removing from the .xinitrc-debug script all > options from valgrind but the --tool=memcheck one, thus being closer to > the first example of using valgrind. This caused a complete lockup of my > computer and my only rescue was a reboot via SysRq. > > I guess I will have to try this again with a somewhat different > approach... > > Cheers, > Florian > > PS: Can I hijack this thread to quickly paste an eina trace I get all > the time when openening everying? ;) https://pastebin.com/rvupgMcx > > > > 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 -- ------------- 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
