Re: [e-users] E crash with Nvidia
On Fri, Sep 10, 2021 at 12:36:24AM +0100, Carsten Haitzler wrote: > On Fri, 10 Sep 2021 08:28:30 +0900 Florian Schaefer said: > > > On Thu, Sep 09, 2021 at 08:32:47AM +0100, Carsten Haitzler wrote: > > > On Thu, 9 Sep 2021 09:20:28 +0900 Florian Schaefer > > > 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 > > > > > 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
Re: [e-users] E crash with Nvidia
On Thu, Sep 09, 2021 at 08:32:47AM +0100, Carsten Haitzler wrote: > On Thu, 9 Sep 2021 09:20:28 +0900 Florian Schaefer 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 > > > 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
Re: [e-users] E crash with Nvidia
On Wed, Sep 08, 2021 at 11:08:00AM +0100, Carsten Haitzler wrote: > On Wed, 8 Sep 2021 17:35:12 +0900 Florian Schaefer 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. :) 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. 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. 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 wrote: > > > > > > > Hey can you try this... > > > > > > > > > > > > > > > > On Tue, Sep 7, 2021 at 9:30 AM Al Poole wrote: > > > > > > > >> Nah > > > >> > > > >> On Tue, 7 Sep 2021, 09:25 Florian Schaefer, 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 > > > >>> >
Re: [e-users] E crash with Nvidia
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? 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 wrote: > > > Hey can you try this... > > > > > > > > On Tue, Sep 7, 2021 at 9:30 AM Al Poole wrote: > > > >> Nah > >> > >> On Tue, 7 Sep 2021, 09:25 Florian Schaefer, 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 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 > >>> > > &g
Re: [e-users] E crash with Nvidia
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 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 > > > 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, > > >> wrote: > > >> > > > >> > > On Sun, 5 Sep 2021 11:25:35 +0900 Florian Schaefer > >> > > > >> > > 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... > > >> > > > > &g
Re: [e-users] E crash with Nvidia
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 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 > > 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, > >> wrote: > >> > > >> > > On Sun, 5 Sep 2021 11:25:35 +0900 Florian Schaefer >> > > >> > > 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 > >&
Re: [e-users] E crash with Nvidia
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. ;) https://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, wrote: > > > On Sun, 5 Sep 2021 11:25:35 +0900 Florian Schaefer > > 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. > > > > h 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 t
Re: [e-users] Segfault in e_object_del()
Hi Raster, three's a charm, right? - Looks good so far here, too. Despite my best efforts I could not produce another error. :) Thanks again for your quick help! Cheers, Florian "Carsten Haitzler" ras...@rasterman.com – September 7, 2021 1:10 AM > On Mon, 06 Sep 2021 08:23:12 + Florian Schaefer said: > > > hmmm trying again - for me with asan on i don't see an issue with desklock > now... ? i tried to change the code to avoid possibly multiple entries in the > array... > > > Hmm, you might not like it (neither do I BTW) but it crashed again on me > > right after restarting E a second time. > > > > pastebin.com/i1pMSR4d > > > > > > But still, its definitely more stable than before... ;) > > > > > > Sorry about that, > > > > Florian > > > > > > "Florian Schaefer" list...@netego.de – September 6, 2021 5:08 PM > > > "Carsten Haitzler" ras...@rasterman.com – September 6, 2021 4:51 PM > > > > On Mon, 06 Sep 2021 00:00:37 + Florian Schaefer > > > > said: > > > > > > > > fixed it just now. :) > > > > > > Hooray, thanks a bunch! :) > > > > > > With this I am now finally able to also activate/test the modified > > > procstats module. (Before, this bug here would crash the module dialog so > > > that I could not make any changes.) So far so good. Back to work it is and > > > let's see what else turns up. ;-) > > > > > > Cheers > > > Florian > > > > > > > > OK, so it seems that Raster already tried to address this problem. > > > > > Thank you very much! > > > > > > > > > > This morning first thing I installed the changed version. Now it > > > > > crashes in the newly created _e_util_cb_delayed_cancel() instead... > > > > > > > > > > > > > > > pastebin.com/mX6hU40g > > > > > > > > > > > > > > > (This is reliably triggered when I try to set the border style of a > > > > > window to borderless.) > > > > > > > > > > > > > > > Unfortunately my ASAN is currently refusing to give meaningful outputs > > > > > to a logging facility that I can see so I have only the gdb manual and > > > > > the E automatic backtrace (even though the latter one contains the > > > > > ASAN > > > > > information in a realy difficult to read way). > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Florian > > > > > > > > > > > > > > > "Florian Schaefer" list...@netego.de – September 5, 2021 2:32 PM > > > > > > As I mentioned in my last message of the "E crash with Nvidia" > > > > > > thread, > > > > > > in using ASAN I could trigger quite a bit of additional segmentation > > > > > > faults. So I disabled the procstat module for now and went > > > > > > hunting. :-) > > > > > > > > > > > > On closer inspection it now seems to me that the faults are actually > > > > > > all due to an invalid call in e_object_del() of e_object.c. > > > > > > > > > > > > Here are the traces and ASAN outputs of two captured crashes: > > > > > > > > > > > > pastebin.com/3du7GYkS > > > > > > pastebin.com/9V1wCjnw > > > > > > > > > > > > They seem quite identical to me. > > > > > > > > > > > > I did not find a fully reproducible way to trigger this. It mostly > > > > > > happened for me right after a restart of E or when dismissing the > > > > > > initial error dialog (informing me that there was some error with > > > > > > PAM). > > > > > > > > > > > > Anyway, I hope that this is helpful. > > > > > > > > > > > > Cheers > > > > > > Florian ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Segfault in e_object_del()
Hmm, you might not like it (neither do I BTW) but it crashed again on me right after restarting E a second time. https://pastebin.com/i1pMSR4d But still, its definitely more stable than before... ;) Sorry about that, Florian "Florian Schaefer" list...@netego.de – September 6, 2021 5:08 PM > "Carsten Haitzler" ras...@rasterman.com – September 6, 2021 4:51 PM > > On Mon, 06 Sep 2021 00:00:37 + Florian Schaefer > > said: > > > > fixed it just now. :) > > Hooray, thanks a bunch! :) > > With this I am now finally able to also activate/test the modified procstats > module. (Before, this bug here would crash the module dialog so that I could > not make any changes.) So far so good. Back to work it is and let's see what > else turns up. ;-) > > Cheers > Florian > > > > OK, so it seems that Raster already tried to address this problem. Thank > > > you > > > very much! > > > > > > This morning first thing I installed the changed version. Now it crashes > > > in > > > the newly created _e_util_cb_delayed_cancel() instead... > > > > > > > > > pastebin.com/mX6hU40g > > > > > > > > > (This is reliably triggered when I try to set the border style of a > > > window to > > > borderless.) > > > > > > > > > Unfortunately my ASAN is currently refusing to give meaningful outputs to > > > a > > > logging facility that I can see so I have only the gdb manual and the E > > > automatic backtrace (even though the latter one contains the ASAN > > > information > > > in a realy difficult to read way). > > > > > > > > > Cheers, > > > > > > Florian > > > > > > > > > "Florian Schaefer" list...@netego.de – September 5, 2021 2:32 PM > > > > As I mentioned in my last message of the "E crash with Nvidia" thread, > > > > in using ASAN I could trigger quite a bit of additional segmentation > > > > faults. So I disabled the procstat module for now and went hunting. :-) > > > > > > > > On closer inspection it now seems to me that the faults are actually all > > > > due to an invalid call in e_object_del() of e_object.c. > > > > > > > > Here are the traces and ASAN outputs of two captured crashes: > > > > > > > > pastebin.com/3du7GYkS > > > > pastebin.com/9V1wCjnw > > > > > > > > They seem quite identical to me. > > > > > > > > I did not find a fully reproducible way to trigger this. It mostly > > > > happened for me right after a restart of E or when dismissing the > > > > initial error dialog (informing me that there was some error with PAM). > > > > > > > > Anyway, I hope that this is helpful. > > > > > > > > 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
Re: [e-users] Segfault in e_object_del()
"Carsten Haitzler" ras...@rasterman.com – September 6, 2021 4:51 PM > On Mon, 06 Sep 2021 00:00:37 + Florian Schaefer said: > > fixed it just now. :) Hooray, thanks a bunch! :) With this I am now finally able to also activate/test the modified procstats module. (Before, this bug here would crash the module dialog so that I could not make any changes.) So far so good. Back to work it is and let's see what else turns up. ;-) Cheers Florian > > OK, so it seems that Raster already tried to address this problem. Thank you > > very much! > > > > This morning first thing I installed the changed version. Now it crashes in > > the newly created _e_util_cb_delayed_cancel() instead... > > > > > > pastebin.com/mX6hU40g > > > > > > (This is reliably triggered when I try to set the border style of a window > > to > > borderless.) > > > > > > Unfortunately my ASAN is currently refusing to give meaningful outputs to a > > logging facility that I can see so I have only the gdb manual and the E > > automatic backtrace (even though the latter one contains the ASAN > > information > > in a realy difficult to read way). > > > > > > Cheers, > > > > Florian > > > > > > "Florian Schaefer" list...@netego.de – September 5, 2021 2:32 PM > > > As I mentioned in my last message of the "E crash with Nvidia" thread, > > > in using ASAN I could trigger quite a bit of additional segmentation > > > faults. So I disabled the procstat module for now and went hunting. :-) > > > > > > On closer inspection it now seems to me that the faults are actually all > > > due to an invalid call in e_object_del() of e_object.c. > > > > > > Here are the traces and ASAN outputs of two captured crashes: > > > > > > pastebin.com/3du7GYkS > > > pastebin.com/9V1wCjnw > > > > > > They seem quite identical to me. > > > > > > I did not find a fully reproducible way to trigger this. It mostly > > > happened for me right after a restart of E or when dismissing the > > > initial error dialog (informing me that there was some error with PAM). > > > > > > Anyway, I hope that this is helpful. > > > > > > Cheers > > > Florian ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Segfault in e_object_del()
OK, so it seems that Raster already tried to address this problem. Thank you very much! This morning first thing I installed the changed version. Now it crashes in the newly created _e_util_cb_delayed_cancel() instead... https://pastebin.com/mX6hU40g (This is reliably triggered when I try to set the border style of a window to borderless.) Unfortunately my ASAN is currently refusing to give meaningful outputs to a logging facility that I can see so I have only the gdb manual and the E automatic backtrace (even though the latter one contains the ASAN information in a realy difficult to read way). Cheers, Florian "Florian Schaefer" list...@netego.de – September 5, 2021 2:32 PM > As I mentioned in my last message of the "E crash with Nvidia" thread, > in using ASAN I could trigger quite a bit of additional segmentation > faults. So I disabled the procstat module for now and went hunting. :-) > > On closer inspection it now seems to me that the faults are actually all > due to an invalid call in e_object_del() of e_object.c. > > Here are the traces and ASAN outputs of two captured crashes: > > pastebin.com/3du7GYkS > pastebin.com/9V1wCjnw > > They seem quite identical to me. > > I did not find a fully reproducible way to trigger this. It mostly > happened for me right after a restart of E or when dismissing the > initial error dialog (informing me that there was some error with PAM). > > Anyway, I hope that this is helpful. > > 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
Re: [e-users] E crash with Nvidia
"Carsten Haitzler" ras...@rasterman.com – September 5, 2021 10:11 PM > On Sun, 5 Sep 2021 11:25:35 +0900 Florian Schaefer 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. These are actually exactly the options I am using right now. So I guess the errors are deemed sufficiently "real" to merit a SIGSEGV. Really, right now my system has become a little bit stressful to use. I hope we manage to settle this down soon. :-) > > 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. Thanks. Interestingly no .xsession-errors is created here even though it is at least mentioned in /etc/X11/Xsession. I had a look at my journalctrl output. Even though I see tons of other errors (actually also a few backtraces for eina_btlog) there are no traces of ASAN. And this morning ASAN even stopped giving the reports to my logging file. What about the good old days where everything was easy to follow? :) > > 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 I see that Al has addressed this by now. Thank you very much! I will give it a try. > > 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. > > h 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". OK, thank you for clearing this up. Then I am happy that your apparent fallbacks for the unlocking at least leave me back into my system. > > 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 doc
[e-users] Segfault in e_object_del()
As I mentioned in my last message of the "E crash with Nvidia" thread, in using ASAN I could trigger quite a bit of additional segmentation faults. So I disabled the procstat module for now and went hunting. :-) On closer inspection it now seems to me that the faults are actually all due to an invalid call in e_object_del() of e_object.c. Here are the traces and ASAN outputs of two captured crashes: https://pastebin.com/3du7GYkS https://pastebin.com/9V1wCjnw They seem quite identical to me. I did not find a fully reproducible way to trigger this. It mostly happened for me right after a restart of E or when dismissing the initial error dialog (informing me that there was some error with PAM). Anyway, I hope that this is helpful. Cheers Florian ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] E crash with Nvidia
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. 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. 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 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. 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 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 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. ;-) Cheers Florian On 9/5/21 6:27 AM, Carsten Haitzler wrote: On Sat, 4 Sep 2021 17:52:09 +0900 Florian Schaefer said: On 9/4/21 4:55 PM, Carsten Haitzler wrote: On Sat, 4 Sep 2021 11:47:20 +0900 Florian Schaefer 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 0x7f23b417f872 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29 #1 0x564440d159f7 in e_alert_show () at ../src/bin/e_alert.c:43 #2 0x564440cda47a in _e_crash () at ../src/bin/e_signals.c:81 #3 0x564440cda4a9 in e_sigseg_act (x=, info=, data=) at ../src/bin/e_signals.c:91 #4 0x7f23b4180140 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x7f23a57df211 in _ibox_icon_fill (ic=0x5644419a2910) at ../src/modules/ibox/e_mod_main.c:636 #6 0x7f23a57df330 in _ibox_cb_icon_fill_timer (data=) at ../src/modules/ibox/e_mod_main.c:526 #7 0x7f23b4c25581 in _ecore_call_task_cb (data=, func=) 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 0x7f23b3b1c130 in _event_callback_call (obj_id=0x40379067, pd=0x5644412371e0, desc=0x7f23b4c521e0 <_EFL_LOOP_TIMER_EVENT_TIMER_TICK>, event_info=, legacy_compare=legacy_compare@entry=0 '\000') at ../src/lib/eo/eo_base_class.c:2114 #10 0x7f23b3b1c3ec in _efl_object_event_callback_call (obj_id=, pd=, desc=, event_info=) at ../src/lib/eo/eo_base_class.c:2186 #11 0x7f23b3b16620 in efl_event_callback_call (obj=, 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 0x7f23b4c26e15 in _efl_loop_timer_expired_call (obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460, when=when@entry=436613.23437423998) at ../src/lib/ecore/ecore_timer.c:669 #13 0x7f23b4c26f43 in _efl_loop_timer_expired_timers_call (obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460, when=436613.23437423998) at ../src/lib/ecore/ecore_timer.c:621 #14 0x7f23b4bf2fae in _ecore_main_loop_iterate_internal (obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460, once_only=once_only@entry=0) at ../src/lib/ecore/ecore_main.c:2431 #15 0x7f23b4bf383f in _ecore_main_loop_begin (obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460) at ../src/lib/ecore/ecore_main.c:1231 #16 0x7f23b4bf7e6d in _efl_loop_begin (obj=0x412d, pd=0x5644411fd460) at .
Re: [e-users] E crash with Nvidia
On 9/4/21 4:55 PM, Carsten Haitzler wrote:
On Sat, 4 Sep 2021 11:47:20 +0900 Florian Schaefer 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 0x7f23b417f872 in __libc_pause () at
../sysdeps/unix/sysv/linux/pause.c:29
#1 0x564440d159f7 in e_alert_show () at ../src/bin/e_alert.c:43
#2 0x564440cda47a in _e_crash () at ../src/bin/e_signals.c:81
#3 0x564440cda4a9 in e_sigseg_act (x=,
info=, data=) at ../src/bin/e_signals.c:91
#4 0x7f23b4180140 in () at
/lib/x86_64-linux-gnu/libpthread.so.0
#5 0x7f23a57df211 in _ibox_icon_fill (ic=0x5644419a2910) at
../src/modules/ibox/e_mod_main.c:636
#6 0x7f23a57df330 in _ibox_cb_icon_fill_timer (data=) at ../src/modules/ibox/e_mod_main.c:526
#7 0x7f23b4c25581 in _ecore_call_task_cb (data=,
func=) 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 0x7f23b3b1c130 in _event_callback_call (obj_id=0x40379067,
pd=0x5644412371e0, desc=0x7f23b4c521e0
<_EFL_LOOP_TIMER_EVENT_TIMER_TICK>, event_info=,
legacy_compare=legacy_compare@entry=0 '\000') at
../src/lib/eo/eo_base_class.c:2114
#10 0x7f23b3b1c3ec in _efl_object_event_callback_call
(obj_id=, pd=, desc=,
event_info=) at ../src/lib/eo/eo_base_class.c:2186
#11 0x7f23b3b16620 in efl_event_callback_call (obj=,
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 0x7f23b4c26e15 in _efl_loop_timer_expired_call
(obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460,
when=when@entry=436613.23437423998) at ../src/lib/ecore/ecore_timer.c:669
#13 0x7f23b4c26f43 in _efl_loop_timer_expired_timers_call
(obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460,
when=436613.23437423998) at ../src/lib/ecore/ecore_timer.c:621
#14 0x7f23b4bf2fae in _ecore_main_loop_iterate_internal
(obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460,
once_only=once_only@entry=0) at ../src/lib/ecore/ecore_main.c:2431
#15 0x7f23b4bf383f in _ecore_main_loop_begin
(obj=obj@entry=0x412d, pd=pd@entry=0x5644411fd460) at
../src/lib/ecore/ecore_main.c:1231
#16 0x7f23b4bf7e6d in _efl_loop_begin (obj=0x412d,
pd=0x5644411fd460) at ../src/lib/ecore/efl_loop.c:57
#17 0x7f23b4bf7233 in efl_loop_begin (obj=0x412d) at
src/lib/ecore/efl_loop.eo.c:28
#18 0x7f23b4bf390c in ecore_main_loop_begin () at
../src/lib/ecore/ecore_main.c:1316
#19 0x564440cb8c50 in main (argc=, argv=) at ../src/bin/e_main.c:1121
(gdb) fr 5
#5 0x7f23a57df211 in _ibox_icon_fill (ic=0x5644419a2910) at
../src/modules/ibox/e_mod_main.c:636
636if ((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 {
636if ((ic->ibox->inst->ci->show_preview) &&
(edje_object_part_exists(ic->o_holder, "e.swallow.preview")))
637 _ibox_icon_fill_preview(ic, EINA_FALSE);
638else
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 , 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
imagi
Re: [e-users] E crash with Nvidia
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. ;-) Cheers Florian On 9/4/21 1:25 AM, Carsten Haitzler wrote: On Fri, 3 Sep 2021 21:04:35 +0900 Florian Schaefer 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
[e-users] E crash with Nvidia
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
Re: [e-users] slow change window/task
On 4/5/21 2:54 AM, Carsten Haitzler wrote: On Sun, 4 Apr 2021 17:40:21 +0900 Florian Schaefer said: On 4/4/21 5:02 PM, Francesc Guasch wrote: On 04/04/2021 05:09, Carsten Haitzler wrote: On Sun, 4 Apr 2021 10:20:15 +0900 Florian Schaefer said: On 4/4/21 5:52 AM, Carsten Haitzler wrote: On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch said: Hi. I am running Enlightenment 0.24.99 24520. It has always run smooth on my lapton, this is a 2005 Toshiba with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller. I know I am pushing the limit here, sorry for that. Since the last release changing windows with ALT-TAB takes 2 / 3 seconds. After the window changes the list of tasks is shown and the back desktop is blurred for a few seconds. Then the selected window is shown and I can use it. how is it blurred. the default theme does not blur the background. i tried that a while back in flat but testing on an older machine showed it could not keep up (a 2010 intel laptop with intel gpu) and dropped to like 20-30fps, so i disabled the filter and it just darkens what is below... so what you describe must be an altered theme? Sorry if I barge in into the discussion here. Just yesterday I also updated after some weeks again to he current git versions, now with the flat theme, and experienced the same "issue". (BTW, I also ran into the elput issue and had a jolly time figuring out that I need to enable the DRM option.) I guess what Francesc intended was exactly this fading to a darker background. On my machine here (i7-3517U) it takes probably about a second. But it is no smooth transition and rather seems to be stuttering along the way, thus feeling really as if the machine is struggling to keep up with rendering this transition. The effect is that the whole process of switching windows feels very sluggish and seems to take ages. I was also (unsuccessfully) looking around for a way to switch off this transition effect. Switching between windows with Alt-Tab is a very common action and I would like this to be over in literally in the blink of an eye. One can actually quickly switch windows in the current state, cutting the whole transition short right at the start. Still, I would prefer if I can have the window list either appear instantaneously or with a really fast fade-in and -out. (BTW, this is using the window switcher in list mode, not in large mode where this whole background darkening is probably really necessary as there is otherwise no window to separate the list from the normal desktop.) Maybe I didn't explain good enough. I reproduce it pressing ALT-TAB while I have some windows open. I don't know about window siwtcher in list mode or large mode that Florian talked about. Cheers and thanks as always for the great work, Florian also a large number of maximized windows (a lot of pixels to render) will slow down even the best of gpu's if you have enough of them... smaller windows render faster in miniature (the input window is smaller). and both the old list mode and large mode how show these miniatures and thus render everything you see which costs.. the more you have visible, the more it costs. it costs even more in software rendering than a gpu... the "i dont even see the fade animation" hints to me it's software compositing or a very large number of large windows. Hey ! Thanks for stepping in Florian. I was wrong, the problem was not on the fading of the background, but on the app windows. I too built with the latest git commits but it didn't fix it for me. Is it running faster ? Maybe, I am not sure, but it is still slow. Right now I have a couple of Thunderbird windows and a Terminology and it is paifull. Probably because of the large Thunderbird window that takes all the screen. xrandr shows 1680x1050 60.00* Just to summarize: - Large Windows: yes, it gets worse with those. But just a gvim and a terminology also is noticeable slow. - Composite: OpenGL . glxinfo: direct rendering: Yes And now what may be the root of the problem: Turning rendering to software or opengl won't make a change. So the conclusion may be this laptop is way too old. I tried if I could download drivers but the Ubuntu software tool won't show any. With lsmod I see i915. I guess 2020 Enlightenment task switch was way faster because it probably didn't have this transition. I actually made the same observation, software rendering and openGL won't make a difference. I thought this odd at that time. However, now that we know its the previews and not the transition effect, it probably makes sense. Seen that Raster has some dithering algorithm doing the down-scaling its probably down to the CPU to do this. The way you put the result on the screen, software or openGL, won't affect the time required then. At least that's my understanding now. On a different note: I am a bit worried about this "laptop is way too old" feeling. Fo
Re: [e-users] slow change window/task
On 4/4/21 5:40 PM, Florian Schaefer wrote: On 4/4/21 5:02 PM, Francesc Guasch wrote: On 04/04/2021 05:09, Carsten Haitzler wrote: On Sun, 4 Apr 2021 10:20:15 +0900 Florian Schaefer said: On 4/4/21 5:52 AM, Carsten Haitzler wrote: On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch said: Hi. I am running Enlightenment 0.24.99 24520. It has always run smooth on my lapton, this is a 2005 Toshiba with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller. I know I am pushing the limit here, sorry for that. Since the last release changing windows with ALT-TAB takes 2 / 3 seconds. After the window changes the list of tasks is shown and the back desktop is blurred for a few seconds. Then the selected window is shown and I can use it. how is it blurred. the default theme does not blur the background. i tried that a while back in flat but testing on an older machine showed it could not keep up (a 2010 intel laptop with intel gpu) and dropped to like 20-30fps, so i disabled the filter and it just darkens what is below... so what you describe must be an altered theme? Sorry if I barge in into the discussion here. Just yesterday I also updated after some weeks again to he current git versions, now with the flat theme, and experienced the same "issue". (BTW, I also ran into the elput issue and had a jolly time figuring out that I need to enable the DRM option.) I guess what Francesc intended was exactly this fading to a darker background. On my machine here (i7-3517U) it takes probably about a second. But it is no smooth transition and rather seems to be stuttering along the way, thus feeling really as if the machine is struggling to keep up with rendering this transition. The effect is that the whole process of switching windows feels very sluggish and seems to take ages. I was also (unsuccessfully) looking around for a way to switch off this transition effect. Switching between windows with Alt-Tab is a very common action and I would like this to be over in literally in the blink of an eye. One can actually quickly switch windows in the current state, cutting the whole transition short right at the start. Still, I would prefer if I can have the window list either appear instantaneously or with a really fast fade-in and -out. (BTW, this is using the window switcher in list mode, not in large mode where this whole background darkening is probably really necessary as there is otherwise no window to separate the list from the normal desktop.) Maybe I didn't explain good enough. I reproduce it pressing ALT-TAB while I have some windows open. I don't know about window siwtcher in list mode or large mode that Florian talked about. Cheers and thanks as always for the great work, Florian also a large number of maximized windows (a lot of pixels to render) will slow down even the best of gpu's if you have enough of them... smaller windows render faster in miniature (the input window is smaller). and both the old list mode and large mode how show these miniatures and thus render everything you see which costs.. the more you have visible, the more it costs. it costs even more in software rendering than a gpu... the "i dont even see the fade animation" hints to me it's software compositing or a very large number of large windows. Hey ! Thanks for stepping in Florian. I was wrong, the problem was not on the fading of the background, but on the app windows. I too built with the latest git commits but it didn't fix it for me. Is it running faster ? Maybe, I am not sure, but it is still slow. Right now I have a couple of Thunderbird windows and a Terminology and it is paifull. Probably because of the large Thunderbird window that takes all the screen. xrandr shows 1680x1050 60.00* Just to summarize: - Large Windows: yes, it gets worse with those. But just a gvim and a terminology also is noticeable slow. - Composite: OpenGL . glxinfo: direct rendering: Yes And now what may be the root of the problem: Turning rendering to software or opengl won't make a change. So the conclusion may be this laptop is way too old. I tried if I could download drivers but the Ubuntu software tool won't show any. With lsmod I see i915. I guess 2020 Enlightenment task switch was way faster because it probably didn't have this transition. I actually made the same observation, software rendering and openGL won't make a difference. I thought this odd at that time. However, now that we know its the previews and not the transition effect, it probably makes sense. Seen that Raster has some dithering algorithm doing the down-scaling its probably down to the CPU to do this. The way you put the result on the screen, software or openGL, won't affect the time required then. At least that's my understanding now. On a different note: I am a bit worried about this "laptop is way too old" feeling. For me one of the selling points o
Re: [e-users] slow change window/task
On 4/4/21 5:02 PM, Francesc Guasch wrote: On 04/04/2021 05:09, Carsten Haitzler wrote: On Sun, 4 Apr 2021 10:20:15 +0900 Florian Schaefer said: On 4/4/21 5:52 AM, Carsten Haitzler wrote: On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch said: Hi. I am running Enlightenment 0.24.99 24520. It has always run smooth on my lapton, this is a 2005 Toshiba with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller. I know I am pushing the limit here, sorry for that. Since the last release changing windows with ALT-TAB takes 2 / 3 seconds. After the window changes the list of tasks is shown and the back desktop is blurred for a few seconds. Then the selected window is shown and I can use it. how is it blurred. the default theme does not blur the background. i tried that a while back in flat but testing on an older machine showed it could not keep up (a 2010 intel laptop with intel gpu) and dropped to like 20-30fps, so i disabled the filter and it just darkens what is below... so what you describe must be an altered theme? Sorry if I barge in into the discussion here. Just yesterday I also updated after some weeks again to he current git versions, now with the flat theme, and experienced the same "issue". (BTW, I also ran into the elput issue and had a jolly time figuring out that I need to enable the DRM option.) I guess what Francesc intended was exactly this fading to a darker background. On my machine here (i7-3517U) it takes probably about a second. But it is no smooth transition and rather seems to be stuttering along the way, thus feeling really as if the machine is struggling to keep up with rendering this transition. The effect is that the whole process of switching windows feels very sluggish and seems to take ages. I was also (unsuccessfully) looking around for a way to switch off this transition effect. Switching between windows with Alt-Tab is a very common action and I would like this to be over in literally in the blink of an eye. One can actually quickly switch windows in the current state, cutting the whole transition short right at the start. Still, I would prefer if I can have the window list either appear instantaneously or with a really fast fade-in and -out. (BTW, this is using the window switcher in list mode, not in large mode where this whole background darkening is probably really necessary as there is otherwise no window to separate the list from the normal desktop.) Maybe I didn't explain good enough. I reproduce it pressing ALT-TAB while I have some windows open. I don't know about window siwtcher in list mode or large mode that Florian talked about. Cheers and thanks as always for the great work, Florian also a large number of maximized windows (a lot of pixels to render) will slow down even the best of gpu's if you have enough of them... smaller windows render faster in miniature (the input window is smaller). and both the old list mode and large mode how show these miniatures and thus render everything you see which costs.. the more you have visible, the more it costs. it costs even more in software rendering than a gpu... the "i dont even see the fade animation" hints to me it's software compositing or a very large number of large windows. Hey ! Thanks for stepping in Florian. I was wrong, the problem was not on the fading of the background, but on the app windows. I too built with the latest git commits but it didn't fix it for me. Is it running faster ? Maybe, I am not sure, but it is still slow. Right now I have a couple of Thunderbird windows and a Terminology and it is paifull. Probably because of the large Thunderbird window that takes all the screen. xrandr shows 1680x1050 60.00* Just to summarize: - Large Windows: yes, it gets worse with those. But just a gvim and a terminology also is noticeable slow. - Composite: OpenGL . glxinfo: direct rendering: Yes And now what may be the root of the problem: Turning rendering to software or opengl won't make a change. So the conclusion may be this laptop is way too old. I tried if I could download drivers but the Ubuntu software tool won't show any. With lsmod I see i915. I guess 2020 Enlightenment task switch was way faster because it probably didn't have this transition. I actually made the same observation, software rendering and openGL won't make a difference. I thought this odd at that time. However, now that we know its the previews and not the transition effect, it probably makes sense. Seen that Raster has some dithering algorithm doing the down-scaling its probably down to the CPU to do this. The way you put the result on the screen, software or openGL, won't affect the time required then. At least that's my understanding now. On a different note: I am a bit worried about this "laptop is way too old" feeling. For me one of the selling points of linux in general and also E in particular was and
Re: [e-users] slow change window/task
On 4/4/21 12:01 PM, Carsten Haitzler wrote: On Sun, 4 Apr 2021 10:20:15 +0900 Florian Schaefer said: On 4/4/21 5:52 AM, Carsten Haitzler wrote: On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch said: Hi. I am running Enlightenment 0.24.99 24520. It has always run smooth on my lapton, this is a 2005 Toshiba with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller. I know I am pushing the limit here, sorry for that. Since the last release changing windows with ALT-TAB takes 2 / 3 seconds. After the window changes the list of tasks is shown and the back desktop is blurred for a few seconds. Then the selected window is shown and I can use it. how is it blurred. the default theme does not blur the background. i tried that a while back in flat but testing on an older machine showed it could not keep up (a 2010 intel laptop with intel gpu) and dropped to like 20-30fps, so i disabled the filter and it just darkens what is below... so what you describe must be an altered theme? Sorry if I barge in into the discussion here. Just yesterday I also updated after some weeks again to he current git versions, now with the flat theme, and experienced the same "issue". (BTW, I also ran into the elput issue and had a jolly time figuring out that I need to enable the DRM option.) I guess what Francesc intended was exactly this fading to a darker background. On my machine here (i7-3517U) it takes probably about a second. But it is no smooth transition and rather seems to be stuttering along the way, thus feeling really as if the machine is struggling to keep up with rendering this transition. The effect is that the whole process of switching windows feels very sluggish and seems to take ages. I was also (unsuccessfully) looking around for a way to switch off this transition effect. Switching between windows with Alt-Tab is a very common action and I would like this to be over in literally in the blink of an eye. One can actually quickly switch windows in the current state, cutting the whole transition short right at the start. Still, I would prefer if I can have the window list either appear instantaneously or with a really fast fade-in and -out. it is smooth. it fades in smoothly over like 0,2 seconds - that's the transition time in the theme. IF your gpu was weak enough before i removed the blur it could stutter. Well, I am sitting on an integrated Intel graphics here (i915 kernel driver, intel_drv.so Xorg driver), so I wouldn't expect any performance miracles. :-) the darkening is cheap - it's rendering the large window previews in the zooming in popup of the switcher that is more costly (unless it's the blur which is even more costly...) Yeah, it seems you are right - of course. ;-) As you mentioned in your second reply post, big windows seem to have a notable impact. My standard setup is four virtual desktops with three desktops occupied by basically maximized terminology, Firefox and Thunderbird windows. Closing these and just putting some "standard sized" terminology instances makes the transition notably smoother. So this might have been the culprit here. it COULD have been the dither shader though too - i actually just optimized it tonight, but the i5-4200u i have here copes perfectly with it and silky-smoothly fades. if i tap alt-tab really fast it only partly fades in before fading out again... I saw your commit message this morning, wondering whether this might be related. So I recompiled everything with the optimized shader. It might be wishful thinking, but I think it made things smoother indeed. At least with my three big windows (is 1600x900 big?) open it is a much more pleasant experience now. :-) (BTW, this is using the window switcher in list mode, not in large mode where this whole background darkening is probably really necessary as there is otherwise no window to separate the list from the normal desktop.) the darkening is cheap... it's just a big solid rect that is semi-transparent. rendering the miniature windows is going to cost more. Again, thanks for pointing that out. Seems to have been a typical case where the user jumped at the most obvious thing (the darkening of basically the whole screen) while completely underestimating the details (a preview window that is way too small anyways (in list mode) for any useful information). are you software rendering? then this can get a lot more costly. it makes a MASSIVE difference in software compositing - like goes from 5-10fps to 60 if the window miniatures are not included in the list mode. the darkening makes really no difference (well in comparison). I wouldn't have been to surprised to be in software rendering with my old Intel graphics system here. But glxinfo is reporting "direct rendering: Yes" and the E Composite Settings are on the OpenGL engine. I tried the "Show Framerate" option from the composite Deb
Re: [e-users] slow change window/task
On 4/4/21 5:52 AM, Carsten Haitzler wrote: On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch said: Hi. I am running Enlightenment 0.24.99 24520. It has always run smooth on my lapton, this is a 2005 Toshiba with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller. I know I am pushing the limit here, sorry for that. Since the last release changing windows with ALT-TAB takes 2 / 3 seconds. After the window changes the list of tasks is shown and the back desktop is blurred for a few seconds. Then the selected window is shown and I can use it. how is it blurred. the default theme does not blur the background. i tried that a while back in flat but testing on an older machine showed it could not keep up (a 2010 intel laptop with intel gpu) and dropped to like 20-30fps, so i disabled the filter and it just darkens what is below... so what you describe must be an altered theme? Sorry if I barge in into the discussion here. Just yesterday I also updated after some weeks again to he current git versions, now with the flat theme, and experienced the same "issue". (BTW, I also ran into the elput issue and had a jolly time figuring out that I need to enable the DRM option.) I guess what Francesc intended was exactly this fading to a darker background. On my machine here (i7-3517U) it takes probably about a second. But it is no smooth transition and rather seems to be stuttering along the way, thus feeling really as if the machine is struggling to keep up with rendering this transition. The effect is that the whole process of switching windows feels very sluggish and seems to take ages. I was also (unsuccessfully) looking around for a way to switch off this transition effect. Switching between windows with Alt-Tab is a very common action and I would like this to be over in literally in the blink of an eye. One can actually quickly switch windows in the current state, cutting the whole transition short right at the start. Still, I would prefer if I can have the window list either appear instantaneously or with a really fast fade-in and -out. (BTW, this is using the window switcher in list mode, not in large mode where this whole background darkening is probably really necessary as there is otherwise no window to separate the list from the normal desktop.) Cheers and thanks as always for the great work, Florian It doesn't happen in other more modern PC I have. I wanted to let you know because it looks like something happened here. Just in case it rings any bell. I have been looking at the settings in transitions, tasks and many other places and I couldn't find a way to make it faster. Is there something I could do ? thanks ___ 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
Re: [e-users] problem with input focus and window layering in E 0.21.11
On 11.05.18 15:59, Carsten Haitzler (The Rasterman) wrote: > On Fri, 11 May 2018 08:43:06 +0900 Florian Schaefer <list...@netego.de> said: > >> On 10.05.18 12:04, Carsten Haitzler (The Rasterman) wrote: >>> On Thu, 10 May 2018 09:11:08 +0900 Florian Schaefer <list...@netego.de> >>> said: >>> >>>> Hi everyone, >>>> >>>> sorry for jumping into the discussion so suddenly. :-) >>>> >>>> On 10.05.18 01:12, Carsten Haitzler wrote: >>>> [...] >>>>>> Ok, so basically you are confirming that >>>>>> https://photos.app.goo.gl/GFht7beUYWbobxpP6 >>>>>> is a bug in 0.21.11 and that >>>>> >>>>> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps >>>>> - ..." ... the pointer should/would focus the window it is over, even if >>>>> that window is partly obscured by something on top. >>>>> >>>>>> 1) I'm the first one to see it, maybe because no one is using that >>>>>> release with focus follow mouse? >>>>>> >>>>>> 2) it's not going to get fixed because 0.21.x is a dead branch >>>>> >>>>> correct. the answer is "use 0.22". we don't have the manpower to support >>>>> multiple stable branches going back in time. we maintain one (the last >>>>> release stable branch). :( >>>> [...] >>>> >>>> I'd just like to confirm that I observe a similar behavior here since >>>> some weeks perhaps. I'm currently using efl and e 0.22 recompiled from >>>> GIT on April 22nd. >>>> >>>> Basically I see the same behavior. Interestingly only Firefox (version >>>> 56 in my case) seems to steal the focus from the top windows. And also >>>> only with some applications (e.g. FoxitReader) on top and not strictly >>>> always reproducible. Still, this is really unnerving as I tend to close >>>> my windows using keyboard shortcuts mostly and I always end up closing >>>> the Firefox beneath instead of the intended application... >>> >>> does it still do it on git master? >> >> Yes. >> >> I just recompiled (just to be sure) EFL and enlightenment from GIT >> (master). Behaviour is unchanged: Firefox steals focus from FoxitReader >> window. In that situation the FoxitReader is displayed on top of Firefox >> and the cursor is residing within the Foxit window. My focus settings >> are "sloppy" and "Ignore hint". Interestingly, Foxit regains focus for a >> split second when my mouse curser changed from the main window area to >> the title bar. > > hmmm does focus get stolen on click to focus? can you examine to see precisely > what areas the mouse has to go over for this to happen and see if there is a > pattern that matches something else on screen (visible or maybe obscured). > > i also am not sure if this also has to do with focus model or clients > interacting with focus by setting focus too... trying to at least narrow it > down to "clients involved or not" or is it simply something geometrical? OK, I did some more tests and something like a pattern emerged. It's a bit complicated perhaps but bear with me, I try to break it down. My setup: Notebook with additional external monitor configured to extend my desktop below the notebook screen. I have Firefox running on my notebook screen. Now I create another window on the external monitor, let's say leafpad. I move leafpad up (remember the monitor is sitting below the notebook screen) to cover the firefox window only partially. A part of leafpad is still visible on the external screen. In that case if I move my mouse cursor first to firefox and then from firefox into the leafpad window, firefox steals the focus. Everywhere on the leafpad window. Only the moment I pass a border to the leafpad windows' decorations (title bar or other borders) I get the focus back for a split second. It then goes right back to firefox. This also happens if I try to not move the mouse away from the pixel where I recovered focus. This was when entering leafpad from the firefox window. If I enter the leafpad window directly form the desktop backgroudn without going through firefox first, the focus is not stolen. Also, the moment no part of leafpad is on the external screen but completely on the notebook screen, the focus behaves as expected. Further, this only happens with "Pointer" and "Sloppy" focus. With "Click" focus no problems in all scenarios. For know I observed this whole stuff only with a firefox window below. It seems to be independent of the content firefox is displaying at that moment. I hope this is somehow understandable and helps. :-) Cheers, Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] problem with input focus and window layering in E 0.21.11
On 10.05.18 12:04, Carsten Haitzler (The Rasterman) wrote: > On Thu, 10 May 2018 09:11:08 +0900 Florian Schaefer <list...@netego.de> said: > >> Hi everyone, >> >> sorry for jumping into the discussion so suddenly. :-) >> >> On 10.05.18 01:12, Carsten Haitzler wrote: >> [...] >>>> Ok, so basically you are confirming that >>>> https://photos.app.goo.gl/GFht7beUYWbobxpP6 >>>> is a bug in 0.21.11 and that >>> >>> oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps >>> - ..." ... the pointer should/would focus the window it is over, even if >>> that window is partly obscured by something on top. >>> >>>> 1) I'm the first one to see it, maybe because no one is using that >>>> release with focus follow mouse? >>>> >>>> 2) it's not going to get fixed because 0.21.x is a dead branch >>> >>> correct. the answer is "use 0.22". we don't have the manpower to support >>> multiple stable branches going back in time. we maintain one (the last >>> release stable branch). :( >> [...] >> >> I'd just like to confirm that I observe a similar behavior here since >> some weeks perhaps. I'm currently using efl and e 0.22 recompiled from >> GIT on April 22nd. >> >> Basically I see the same behavior. Interestingly only Firefox (version >> 56 in my case) seems to steal the focus from the top windows. And also >> only with some applications (e.g. FoxitReader) on top and not strictly >> always reproducible. Still, this is really unnerving as I tend to close >> my windows using keyboard shortcuts mostly and I always end up closing >> the Firefox beneath instead of the intended application... > > does it still do it on git master? Yes. I just recompiled (just to be sure) EFL and enlightenment from GIT (master). Behaviour is unchanged: Firefox steals focus from FoxitReader window. In that situation the FoxitReader is displayed on top of Firefox and the cursor is residing within the Foxit window. My focus settings are "sloppy" and "Ignore hint". Interestingly, Foxit regains focus for a split second when my mouse curser changed from the main window area to the title bar. Cheers, Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] problem with input focus and window layering in E 0.21.11
Hi everyone, sorry for jumping into the discussion so suddenly. :-) On 10.05.18 01:12, Carsten Haitzler wrote: [...] >> Ok, so basically you are confirming that >> https://photos.app.goo.gl/GFht7beUYWbobxpP6 >> is a bug in 0.21.11 and that > > oh wit. now i see it.. as your mouse goes over "Terminal" it focused "apps > - ..." ... the pointer should/would focus the window it is over, even if that > window is partly obscured by something on top. > >> 1) I'm the first one to see it, maybe because no one is using that >> release with focus follow mouse? >> >> 2) it's not going to get fixed because 0.21.x is a dead branch > > correct. the answer is "use 0.22". we don't have the manpower to support > multiple stable branches going back in time. we maintain one (the last release > stable branch). :( [...] I'd just like to confirm that I observe a similar behavior here since some weeks perhaps. I'm currently using efl and e 0.22 recompiled from GIT on April 22nd. Basically I see the same behavior. Interestingly only Firefox (version 56 in my case) seems to steal the focus from the top windows. And also only with some applications (e.g. FoxitReader) on top and not strictly always reproducible. Still, this is really unnerving as I tend to close my windows using keyboard shortcuts mostly and I always end up closing the Firefox beneath instead of the intended application... Cheers, Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] ltmain.sh not found
And it did the trick! :-)
At least the configure seems to have run smoothly. Now let's see whether
the rest compiles and runs just as well.
Cheers,
Florian
PS: Still, would be nice to understand why this doesn't work out of the
box...
On 26.02.2015 16:49, marcel-hollerb...@t-online.de wrote:
Hi,
had this a while back, If I remember correctly it has something to do
with updated autotools versions.
Running libtoolize in the repository should work :)
Greetings bu5hm4n
On Thu, Feb 26, 2015 at 10:11:32AM +0900, Florian Schaefer wrote:
Dear enlightenment guys,
since about half a year I cannot figure out any more how to successfully
compile E (neither official releases or from git).
The autogen.sh (or configure) step always end like this:
snip
CDPATH=${ZSH_VERSION+.}: cd . /bin/sh
/usr/src/e17/enlightenment/missing aclocal-1.14 -I m4
cd . /bin/sh /usr/src/e17/enlightenment/missing automake-1.14 --gnu
configure.ac:312: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
and its use is discouraged.
configure.ac:312: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
macro instead,
configure.ac:312: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
Makefile.am files.
configure.ac:48: error: required file './ltmain.sh' not found
Makefile:4595: recipe for target 'Makefile.in' failed
make: *** [Makefile.in] Error 1
snap
I am running automake 1.14 and autoconf 2.69 on Debian here.
Further, I can build evas, emotion and elementary just fine.
Any ideas are greatly appreciated. :-)
Cheers
Florian
--
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for
all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] ltmain.sh not found
Dear enlightenment guys,
since about half a year I cannot figure out any more how to successfully
compile E (neither official releases or from git).
The autogen.sh (or configure) step always end like this:
snip
CDPATH=${ZSH_VERSION+.}: cd . /bin/sh
/usr/src/e17/enlightenment/missing aclocal-1.14 -I m4
cd . /bin/sh /usr/src/e17/enlightenment/missing automake-1.14 --gnu
configure.ac:312: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
and its use is discouraged.
configure.ac:312: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
macro instead,
configure.ac:312: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
Makefile.am files.
configure.ac:48: error: required file './ltmain.sh' not found
Makefile:4595: recipe for target 'Makefile.in' failed
make: *** [Makefile.in] Error 1
snap
I am running automake 1.14 and autoconf 2.69 on Debian here.
Further, I can build evas, emotion and elementary just fine.
Any ideas are greatly appreciated. :-)
Cheers
Florian
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] ecore_x_version.h
Done. T1148. Cheers, Florian On 01.04.2014 18:40, Stefan Schmidt wrote: Hello. On Tue, 2014-04-01 at 12:03, Florian Schaefer wrote: thanks for taking your time. I actually tried among the first things rm -rf efl git clone git://git.enlightenment.org/core/efl.git No help. But I took your clue to look again at my all-inclusive compile command line: export CPPFLAGS=$CPPFLAGS -march=pentium-m -I/opt/e/include; export LDFLAGS=$LDFLAGS -L/opt/e/lib; export PATH=$PATH:/opt/e/bin; export PKG_CONFIG_PATH=/opt/e/lib/pkgconfig; ./autogen.sh --prefix=/opt/e --disable-static --enable-xinput22 --enable-multisense --enable-systemd --enable-image-loader-webp --enable-harfbuzz make clean make -j4 make install Playing around with it a bit I found the problem: I am first calling autogen and then make clean. It seems that make clean removes something that it should better not touch. So is this a bug with the Makefile? I cannot imagine that a make clean should render a project not compilable any more unless reconfigured. And I was actually using above compile line (with varying options for autogen) since the first bits of E17 appeared and never encountered this kind of trouble. Its odd that you have the make clean in between but a normal make clean should not require a new configure or autogen run. I was able to reproduce this. Please fill a bug on phab.enlightenment.org and assign it to me. I will have a look when I have a moment. regards Stefan Schmidt -- ___ 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
Re: [e-users] ecore_x_version.h
Hi Stefan, thanks for taking your time. I actually tried among the first things rm -rf efl git clone git://git.enlightenment.org/core/efl.git No help. But I took your clue to look again at my all-inclusive compile command line: export CPPFLAGS=$CPPFLAGS -march=pentium-m -I/opt/e/include; export LDFLAGS=$LDFLAGS -L/opt/e/lib; export PATH=$PATH:/opt/e/bin; export PKG_CONFIG_PATH=/opt/e/lib/pkgconfig; ./autogen.sh --prefix=/opt/e --disable-static --enable-xinput22 --enable-multisense --enable-systemd --enable-image-loader-webp --enable-harfbuzz make clean make -j4 make install Playing around with it a bit I found the problem: I am first calling autogen and then make clean. It seems that make clean removes something that it should better not touch. So is this a bug with the Makefile? I cannot imagine that a make clean should render a project not compilable any more unless reconfigured. And I was actually using above compile line (with varying options for autogen) since the first bits of E17 appeared and never encountered this kind of trouble. Thanks a lot, Florian On 31.03.2014 21:20, Stefan Schmidt wrote: Hello. On Sat, 2014-03-29 at 07:33, Florian Schaefer wrote: Hi everybody, since about three weeks I cannot manage to compile efl from git. It always bails out with the following error message CC lib/eolian/lib_eolian_libeolian_la-eolian.lo make[2]: *** No rule to make target `../src/lib/ecore_x/ecore_x_version.h', needed by `all'. Stop. make[2]: *** Waiting for unfinished jobs CC lib/eolian/lib_eolian_libeolian_la-eolian_database.lo make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The only file related to this ecore_x_version.h I have is src/lib/ecore_x/ecore_x_version.h.in. I am prette sure to again miss the obvious. Do you have an idea what it might be? Hmm, it works fine for all our build slaves from the automated build as well as for all developers over these three weeks. Did you try to do a completely clean run? Like running make distclean and autogen.sh again or even doing a clean checkout of the git repo? regards Stefan Schmidt -- ___ 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
[e-users] ecore_x_version.h
Hi everybody, since about three weeks I cannot manage to compile efl from git. It always bails out with the following error message CC lib/eolian/lib_eolian_libeolian_la-eolian.lo make[2]: *** No rule to make target `../src/lib/ecore_x/ecore_x_version.h', needed by `all'. Stop. make[2]: *** Waiting for unfinished jobs CC lib/eolian/lib_eolian_libeolian_la-eolian_database.lo make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The only file related to this ecore_x_version.h I have is src/lib/ecore_x/ecore_x_version.h.in. I am prette sure to again miss the obvious. Do you have an idea what it might be? Cheers Florian -- ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
On 19.02.2014 15:46, Carsten Haitzler (The Rasterman) wrote: On Wed, 19 Feb 2014 12:38:53 +0900 Florian Schaefer list...@netego.de said: OK, I think I figured out part of the mystery: My E is installed to /opt/e. Hence also the efreet dbus service files finished up in this location and my dbus was, of course, not picking up those files. Now I've symlinked them to a proper location, E can talk with Efreet, icon themes show up and most of my icons are back. OH! aha! I felt something similar. :-) If we are already given big big warnings about disabling stuff like physics during configuration time, how about adding a warning when putting custom installation prefixes that it is essential that those dbus service files need to be taken care of? yes. good point. i'll stuff a warning bonanza in about this. Thanks. Still, for programs like firefox, thunderwirds, wicd, my icons are missing. Can it be that E is giving precedence to SVG files even though I do not have svg support in E? wtf? no svg support! fredesktop.org icon specs make that a requirement... from memory Well, the FDO spec says, quote, Support for SVGs is optional.. Anyway, if for E the handling is like this then support for SVG should not be in an optional evas_generic_loaders package, but in a mandatory requirement. Better yet, make it a part of Evas or E, as without it the WM is pretty much useless ... in contrast to having a physics engine installed ... sorry, I have to dwell on that point a bit more. ;-) Florian On 19.02.2014 09:07, Florian Schaefer wrote: Hello David! On 18.02.2014 21:15, David Seikel wrote: [...] I agree, that could be at it's heart. So now the question is how to make E recognize my icon theme. Is there some file in which the available themes are listed? Or according to which kind of black magic is that determined? The FreeDestop.Org specification that most Linux distros follow to get this to all work is kinda black magic. I suspect in your efforts to trim down your OS you forgot to dance Gangnam style widershins around the pile of fresh three headed chicken wings. Or something. Maybe add BBQ sauce? I think these are the most relevant mystical tomes - http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html But it probably boils down to - you shaved a bit too much off to save space, and some crucial bit is missing. The problem is identifying that missing bit. [...] I dunno whether I shaved off too much. Probably I just didn't install everything. I think I installed this system about 10 years ago. Ever since being on Debian/sid, copying it from one computer to the next and doing the daily updates in order to keep the edge (or at least trying to). But as in those years the Linux experience evolved from something I can understand as everything is in plain text config files, to something very difficult to disentangle as most stuff is handled by strange daemons, buses and IPCs, it might be I missed something. ;-) Anyway, thank you for those helpful FDO links. Tried to do my homework here, matching with what is written there to my system: Quote: By default, apps should look in $HOME/.icons (for backwards compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps My $XDG_DATA_DIRS is /opt/e/share/enlightenment:/opt/e/share:/usr/local/share:/usr/share. That's already interesting. As the folder [...]/enlightenment/icons is empty. Instead my E icons are in [...]/enlightenment/data/icons. Who adds this entry to my XDG_DATA_DIRS? Anyway, most of my stock icons are in /usr/share/icons, so this dir is also covered. Quote: Implementations are required to look in the hicolor theme if an icon was not found in the current theme. I have a hicolor subdirectory in the icons folder, and it is populated with all the icons I'd every need for my humble set of applications. Quote: In at least one of the theme directories there must be a file called index.theme that describes the theme. My hicolor directory contains an index.theme file, giving the theme the name Hicolor. However, it contains Hidden=true. So I set this to false, just in case. Still, it doesn't show up. Anyway, an application is required to use this theme in case should an icon not be found anywhere else. Therefore, I'd expect my icons to show up. So in this respect it themes my system is not so completely badly set up. Any more ideas? Thanks for you help/patience, Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
Re: [e-users] Some issues with the current state of E
On 19.02.2014 21:53, mh wrote: On 02/19/2014 01:46 AM, Carsten Haitzler (The Rasterman) wrote: On Wed, 19 Feb 2014 12:38:53 +0900 Florian Schaefer list...@netego.de said: OK, I think I figured out part of the mystery: My E is installed to /opt/e. Hence also the efreet dbus service files finished up in this location and my dbus was, of course, not picking up those files. Now I've symlinked them to a proper location, E can talk with Efreet, icon themes show up and most of my icons are back. OH! aha! This sounds like it would fix my problem with missing icons as well. I'm not sure what to symlink where, but I'd like to give this a try. Good if I was not the only one stupid enough. ;-) Anyway, I symlinked org.enlightenment.Efreet.service and org.enlightenment.Ethumb.service from my E installation directory (subdir share/dbus-1/services) to /usr/share/dbus-1/services/. Good luck, Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
On 18.02.2014 18:45, Carsten Haitzler (The Rasterman) wrote: [...] That's an excellent point. My Icons theme list is empty. I have, however, the gnome-icon-theme deb package installed. What am I missing for it to show up on the icons theme list? well i suspect that is your core problem. no working/found/usable icon theme. ican't say what gnome-icon-theme deb pkgs does... but i have themes listed - i installed some icon theme pkgs, i selected one i liked (faenza) and everything is fine. :) I agree, that could be at it's heart. So now the question is how to make E recognize my icon theme. Is there some file in which the available themes are listed? Or according to which kind of black magic is that determined? Just as a try I tried to additionally install the gnome-brave-icon-theme, but after a restart of E still nothing shows up. So I guess I am missing a mechanism that E is relying on to compile its list of themes. But which? And somehow I still do not get the point. I have a .desktop file for my application. In this desktop file an icon is defined. This icon (correct me if I am wrong) does not need to belong to some icon theme as it might be a 3rd party application. So at least if I give a full path there, E should not care about such things as application themes. Or not? Anyway, it appears that somehow my understanding of how application entries, icons for windows and .desktop files work together is slightly out of sync. I am glad for any enlightenment. if you have a full path there - yes. it should absolutely work using the full path. most desktop files for most apps do not give full paths,. they give simple names and expect code to hunt icons down from an icon theme... :) OK, trying to dig a bit into this it seems (at least for the two cases I tested) that a full path actually works. Just I don't feel like changing all my .desktop files by hand... Cheers Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
OK, I think I figured out part of the mystery: My E is installed to /opt/e. Hence also the efreet dbus service files finished up in this location and my dbus was, of course, not picking up those files. Now I've symlinked them to a proper location, E can talk with Efreet, icon themes show up and most of my icons are back. If we are already given big big warnings about disabling stuff like physics during configuration time, how about adding a warning when putting custom installation prefixes that it is essential that those dbus service files need to be taken care of? Still, for programs like firefox, thunderwirds, wicd, my icons are missing. Can it be that E is giving precedence to SVG files even though I do not have svg support in E? Cheers Florian On 19.02.2014 09:07, Florian Schaefer wrote: Hello David! On 18.02.2014 21:15, David Seikel wrote: [...] I agree, that could be at it's heart. So now the question is how to make E recognize my icon theme. Is there some file in which the available themes are listed? Or according to which kind of black magic is that determined? The FreeDestop.Org specification that most Linux distros follow to get this to all work is kinda black magic. I suspect in your efforts to trim down your OS you forgot to dance Gangnam style widershins around the pile of fresh three headed chicken wings. Or something. Maybe add BBQ sauce? I think these are the most relevant mystical tomes - http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html But it probably boils down to - you shaved a bit too much off to save space, and some crucial bit is missing. The problem is identifying that missing bit. [...] I dunno whether I shaved off too much. Probably I just didn't install everything. I think I installed this system about 10 years ago. Ever since being on Debian/sid, copying it from one computer to the next and doing the daily updates in order to keep the edge (or at least trying to). But as in those years the Linux experience evolved from something I can understand as everything is in plain text config files, to something very difficult to disentangle as most stuff is handled by strange daemons, buses and IPCs, it might be I missed something. ;-) Anyway, thank you for those helpful FDO links. Tried to do my homework here, matching with what is written there to my system: Quote: By default, apps should look in $HOME/.icons (for backwards compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps My $XDG_DATA_DIRS is /opt/e/share/enlightenment:/opt/e/share:/usr/local/share:/usr/share. That's already interesting. As the folder [...]/enlightenment/icons is empty. Instead my E icons are in [...]/enlightenment/data/icons. Who adds this entry to my XDG_DATA_DIRS? Anyway, most of my stock icons are in /usr/share/icons, so this dir is also covered. Quote: Implementations are required to look in the hicolor theme if an icon was not found in the current theme. I have a hicolor subdirectory in the icons folder, and it is populated with all the icons I'd every need for my humble set of applications. Quote: In at least one of the theme directories there must be a file called index.theme that describes the theme. My hicolor directory contains an index.theme file, giving the theme the name Hicolor. However, it contains Hidden=true. So I set this to false, just in case. Still, it doesn't show up. Anyway, an application is required to use this theme in case should an icon not be found anywhere else. Therefore, I'd expect my icons to show up. So in this respect it themes my system is not so completely badly set up. Any more ideas? Thanks for you help/patience, Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] Some issues with the current state of E
Hello enlightenment, thanks to everybody for their hard efforts in developing this amazing piece of software. Been using E for 10+ years now (I guess). Though, lately it is making my life a bit more difficult (to say the least) and I am getting to the point where I seriously considered switching to a different WM as I cannot get my most basic tasks done any more. So I decided to join the users discussions and try to slowly get my troubles mended out. ;-) I am running the latest (ok, currently dating back to Sunday) git of pretty much everything on a Debian/sid, and my problems started about two or three weeks ago, I guess. One of them is related to window focus. I use sloppy focus and ever so often it goes astray: I have, e.g., a java application, Pauker, that at some point emits some kind of alert, getting the focus. However, the window is at that time on another virtual desktop and the window my mouse cursor currently resides in is still having the decorations to tell me hey, I have currently the focus. Even moving the mouse between some windows does not recover the focus (even though the title bars indicate activated windows as expected). I am forced to switch to the Pauker application, do something there and only after that I finally regain control over my focus. I am experiencing a similar issue sometimes with the Wicd Network Manager GUI window. It seems to have the focus when I hover with the mouse over it. But then I try to press the connect button and just at that moment it goes out of focus and the click gets to the underlying window instead. To fix this I need to switch a bit between virtual desktops and other windows until I can finally click this nasty connect button. Very unnerving. Another point is application icons. Most of my application icons have disappeared, both in the start menus (that's not so bad) and in the windows itself (it get's kind of tricky to distinguish between several minimized applications if all of them are without any kind of icon). The point is that I cannot make out the system behind which icons are missing. Some system applications are fine, some are not. Some of my .desktop files in ~/.local/share/applications are fine, some are not. And it also does not seem to be related to a particular type of image format. Tried to delete the efreet cache, to no avail. I also tried to define the application icons again by using the create icon function, but this also does not work, the icon is shown in the configuration dialog but seems to be discarded I closed this dialog (well, honestly speaking I cannot remember a time in all those years where the create icon function really reliably worked for me). Perhaps related to that, most applications have also vanished from Everything, and I get messages such as app not found acroread on the console. Even though my acroread is still there and happily around. I think that are my two main points for now: Trouble working at all because I cannot get to focus the windows I need to be in focus and trouble identifying them as they do not have any icons. I complied all e related stuff for a long time now without physics, without gstreamer and without pulseaudio. But as someone introduced this --really-nice-new-super-long-configure-option I tried to get at least physics and gstreamer into efl. But really, I do not need a desktop environment, just a window manager. I disabled anything related to efm and could curse any program that creates a ~/Desktop folder. I do not want this dammed thing. Therefore I also do not understand why I am forced into compiling fancy stuff like physics simulation or video playback into my WM. (I am happy using mplayer and and additonal video libraries I am forced to install are just bloating my system without any additional benefit to me.) But that's another, more philosophical, question for now I guess... ;-) OK, sorry for the long rant, and cheers to everyone, Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
Hi Jeff, are you honestly complaining about a user trying to give some feedback on the software he loves to use in order to help turning it into a better product? ;-) So you propose that all my issues will be solved just by using e-0.18.3 and efl-1.8.5? If so I will give it a shot. It's just that I somehow doubt this alone will be the solution. I think that something might be strange/wrong with my setup (if my issues raised before were really things that are present to everyone in the current development tree, I bet someone would have long since gone out there to squash these things out). Hence, I am turning to this users list, seeking sincerely help and advice. Best regards, Florian On 18.02.2014 10:17, Jeff Hoogland wrote: Are you honestly complaining about issues with software you've compiled from a development repository? If you want super stable, consistent software use the *releases*. They are there for a reason. On Mon, Feb 17, 2014 at 6:20 PM, Florian Schaefer list...@netego.de wrote: Hello enlightenment, thanks to everybody for their hard efforts in developing this amazing piece of software. Been using E for 10+ years now (I guess). Though, lately it is making my life a bit more difficult (to say the least) and I am getting to the point where I seriously considered switching to a different WM as I cannot get my most basic tasks done any more. So I decided to join the users discussions and try to slowly get my troubles mended out. ;-) I am running the latest (ok, currently dating back to Sunday) git of pretty much everything on a Debian/sid, and my problems started about two or three weeks ago, I guess. One of them is related to window focus. I use sloppy focus and ever so often it goes astray: I have, e.g., a java application, Pauker, that at some point emits some kind of alert, getting the focus. However, the window is at that time on another virtual desktop and the window my mouse cursor currently resides in is still having the decorations to tell me hey, I have currently the focus. Even moving the mouse between some windows does not recover the focus (even though the title bars indicate activated windows as expected). I am forced to switch to the Pauker application, do something there and only after that I finally regain control over my focus. I am experiencing a similar issue sometimes with the Wicd Network Manager GUI window. It seems to have the focus when I hover with the mouse over it. But then I try to press the connect button and just at that moment it goes out of focus and the click gets to the underlying window instead. To fix this I need to switch a bit between virtual desktops and other windows until I can finally click this nasty connect button. Very unnerving. Another point is application icons. Most of my application icons have disappeared, both in the start menus (that's not so bad) and in the windows itself (it get's kind of tricky to distinguish between several minimized applications if all of them are without any kind of icon). The point is that I cannot make out the system behind which icons are missing. Some system applications are fine, some are not. Some of my .desktop files in ~/.local/share/applications are fine, some are not. And it also does not seem to be related to a particular type of image format. Tried to delete the efreet cache, to no avail. I also tried to define the application icons again by using the create icon function, but this also does not work, the icon is shown in the configuration dialog but seems to be discarded I closed this dialog (well, honestly speaking I cannot remember a time in all those years where the create icon function really reliably worked for me). Perhaps related to that, most applications have also vanished from Everything, and I get messages such as app not found acroread on the console. Even though my acroread is still there and happily around. I think that are my two main points for now: Trouble working at all because I cannot get to focus the windows I need to be in focus and trouble identifying them as they do not have any icons. I complied all e related stuff for a long time now without physics, without gstreamer and without pulseaudio. But as someone introduced this --really-nice-new-super-long-configure-option I tried to get at least physics and gstreamer into efl. But really, I do not need a desktop environment, just a window manager. I disabled anything related to efm and could curse any program that creates a ~/Desktop folder. I do not want this dammed thing. Therefore I also do not understand why I am forced into compiling fancy stuff like physics simulation or video playback into my WM. (I am happy using mplayer and and additonal video libraries I am forced to install are just bloating my system without any additional benefit to me.) But that's another, more philosophical, question for now I guess... ;-) OK, sorry for the long rant
Re: [e-users] Some issues with the current state of E
On 18.02.2014 11:34, Carsten Haitzler (The Rasterman) wrote: On Tue, 18 Feb 2014 10:47:42 +0900 Florian Schaefer list...@netego.de said: Hi Jeff, are you honestly complaining about a user trying to give some feedback on the software he loves to use in order to help turning it into a better product? ;-) don't worry florian... we care. what we would like is if you file bug reports on https://phab.enlightenment.org 0 that way they get seen, tracked nd not lost. each problem/bug can be discussed in its own thread and you can help point us to ways of reproducing the issue. :) OK, I will try to file a bug where applicable. It is just bugging myself that I cannot find ways to reproduce some of those guys. Anyway, can anyone give my a short guide on what to do on the phab thingy. Incomprehensible as hell. Is tasks phab-speak for bug? Then how would I for example find this T870 that was pointed out later in the thread? I cannot see it even under All Tasks... Ciao Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
On 18.02.2014 12:22, P Purkayastha wrote: [...] Latest git has got window focus issues. Stay away from git if you want stable software. Most stable is the latest e17 release. I would hold e18 releases as next in stability. But then people are also writing don't use e17, it's old as hell. ;-) Well, I actually used it since the famous days hell froze over. And always from cvs/svn/git (or whatever the repro manager of the year was called). So I am used to things breaking once in a while... [...] You need to set an icon theme in e. *Any* reasonably complete icon theme. Also, either install evas-generic-loaders if you want to use svg based icon theme, or set a png based icon theme. Icon theme, hmmm. I always thought that the definition of the application is with it's desktop file. There is specified an icon file. And the icon file exists in the standard icon folders. And it also doesn't get displayed if I specify the absolute path in desktop file. Further, E seems to be able to handle the image file type as I can see it in the create icon dialoge. E just doesn't want to remember this. Perhaps related to that, most applications have also vanished from Everything, and I get messages such as app not found acroread on the console. Even though my acroread is still there and happily around. No idea what causes this. Maybe something wrong with your efreet cache files? Try removing efreet cache files from ~/.cache. Jep, tried this several times before. In the latest installment just made things worse (see my other post). environment, just a window manager. I disabled anything related to efm and could curse any program that creates a ~/Desktop folder. I do not This can be easily fixed by setting the following your desktop directory in ~/.config/user-dirs.dirs XDG_DESKTOP_DIR=$HOME/.config/Desktop That's cool. Thanks! :-) I was looking for such an option for ages. Now if some gnome of E program revives this folder at least I don't have to see it all the time hanging around in my home folder. :-) Ciao Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
Hi there! On 18.02.2014 12:39, mh wrote: [...] Another possibility for the missing icons is apparently an efreet bug. I filled out a phab bug report on this: https://phab.enlightenment.org/T870 Yes, seems to be the same thing. I actually knew that you reported this before and that you were told to report a bug. I was just never able to find this bug report on phab. Even now, I am unable to find it, if it were not for your link. Cheers, Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
On 18.02.2014 15:42, Carsten Haitzler (The Rasterman) wrote: On Tue, 18 Feb 2014 12:50:58 +0900 Florian Schaefer list...@netego.de said: On 18.02.2014 11:34, Carsten Haitzler (The Rasterman) wrote: On Tue, 18 Feb 2014 10:47:42 +0900 Florian Schaefer list...@netego.de said: Hi Jeff, are you honestly complaining about a user trying to give some feedback on the software he loves to use in order to help turning it into a better product? ;-) don't worry florian... we care. what we would like is if you file bug reports on https://phab.enlightenment.org 0 that way they get seen, tracked nd not lost. each problem/bug can be discussed in its own thread and you can help point us to ways of reproducing the issue. :) OK, I will try to file a bug where applicable. It is just bugging myself that I cannot find ways to reproduce some of those guys. Anyway, can anyone give my a short guide on what to do on the phab thingy. Incomprehensible as hell. Is tasks phab-speak for bug? Then how would I for example find this T870 that was pointed out later in the thread? I cannot see it even under All Tasks... https://phab.enlightenment.org/T870 :) pretty simple. :) Once you already know what to look for, i.e. the bug number. Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Some issues with the current state of E
On 18.02.2014 15:44, Carsten Haitzler (The Rasterman) wrote: On Tue, 18 Feb 2014 13:01:22 +0900 Florian Schaefer list...@netego.de said: Hi Cedric! On 18.02.2014 10:51, Cedric BAIL wrote: [...] So you did destroy ~/.cache/efreet/ ? Did you try to manually run efreet_desktop_cache_create afterward (can be found in /usr/lib/efreet/v-1.9/) ? I saw that problem once in the past week, and Carsten to, but it did vanish after a rebuild and restart of E. So I am currently lacking a clue of what is going on here. Just to be sure I redid this. Logged out of E, deleted the efreet cache directory from my text console, executed efreet_desktop_cache_create (the only output I got was the single char 'c'), and restarted X and E. Result: Menu icons still missing and as a bonus now also the icons for my iceweasel and icedove windows are missing (not even replaced by the question mark icon). do you even have an application icon theme selected (settings-look-application theme-icons) ? That's an excellent point. My Icons theme list is empty. I have, however, the gnome-icon-theme deb package installed. What am I missing for it to show up on the icons theme list? And somehow I still do not get the point. I have a .desktop file for my application. In this desktop file an icon is defined. This icon (correct me if I am wrong) does not need to belong to some icon theme as it might be a 3rd party application. So at least if I give a full path there, E should not care about such things as application themes. Or not? Anyway, it appears that somehow my understanding of how application entries, icons for windows and .desktop files work together is slightly out of sync. I am glad for any enlightenment. Cheers, Florian -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
