Am Fri, 8 Apr 2016 12:43:45 +0930 schrieb Simon Lees: > > > On 04/08/2016 12:17 PM, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 7 Apr 2016 20:43:28 +0200 Andreas Volz > > <[email protected]> said: > > > >> Am Thu, 7 Apr 2016 08:14:29 +0900 schrieb Carsten Haitzler (The > >> Rasterman): > >> > >>> On Wed, 6 Apr 2016 22:25:09 +0200 Andreas Volz > >>> <[email protected]> said: > >>> > >>>> Am Tue, 5 Apr 2016 11:01:51 +0900 schrieb Carsten Haitzler (The > >>>> Rasterman): > >>>> > >>>>> On Mon, 4 Apr 2016 23:34:47 +0200 Andreas Volz > >>>>> <[email protected]> said: > >>>>> > >>>>>> Am Mon, 4 Apr 2016 13:30:15 +0900 schrieb Carsten Haitzler (The > >>>>>> Rasterman): > >>>>>> > >>>>>>> On Sun, 3 Apr 2016 22:15:19 +0200 Andreas Volz > >>>>>>> <[email protected]> said: > >>>>>>> > >>>>>>>> Am Fri, 1 Apr 2016 16:31:42 -0700 schrieb Cedric BAIL: > >>>>>>>> > >>>>>>>>>> I tried to start my application with the default Gtk > >>>>>>>>>> based window manager, but it's strange. As long as I > >>>>>>>>>> activate alpha and shaped window support in my > >>>>>>>>>> application the application is somehow broken and hangs > >>>>>>>>>> in the beginning. I didn't yet trace it out where it > >>>>>>>>>> hangs. > >>>>>>>>>> > >>>>>>>>>> Do you have any ideas or explanations? > >>>>>>>>> > >>>>>>>>> Not for the last problem. > >>>>>>>> > >>>>>>>> I didn't change much in my application, but now I get a > >>>>>>>> crash of E20 and X back to the console if I start my > >>>>>>>> application on the Raspberry Pi. > >>>>>>>> > >>>>>>>> In LXDE it still just hangs my application at the point it > >>>>>>>> starts the window. Need to start my application in the > >>>>>>>> debugger and see where it exact hangs. > >>>>>>>> > >>>>>>>> See here the E crash dump: > >>>>>>>> > >>>>>>>> http://tux-style.com/tmp/e-crashdump.txt > >>>>>>> > >>>>>>> like 633? that's in bgr565 - 16bit handling. this will cause > >>>>>>> even more slowness as e has to use efl to convert 16bpp to > >>>>>>> 32bpp then render in 32bpp then render/dither back to 16bpp > >>>>>>> for the display... > >>>>>> > >>>>>> Ok, have I influenced this in my application setup? > >>>>>> > >>>>>>> try 24/32bpp for best results. but anyway. this says the 16bit > >>>>>>> converter has a bug maybe - > thats s16 (src 16bit) ptr - and > >>>>>>> it uses sbpl to multiply y + row.... so what's up with this? > >>>>>>> sbpl is src bytes per line. so 640 there. i assume its a 320 > >>>>>>> wide window then. is y and row ... wrong? row is the current > >>>>>>> row we are looking at? y + h > >>>>>>>> image height? height says it's 240. row is 0... src pts and > >>>>>>>> s16 are the same - so that's right. ... so it's not src. dp > >>>>>>>> (destination pointer) is the issue. in > >>>>>>> fact see dst - its NULL. (0x0). thats the issue. why is it > >>>>>>> null? that's odd. :( > >>>>>> > >>>>>> No my window is 800x480 pixels big. Maybe that's the LXTerminal > >>>>>> size. I had two terminals open at this time. > >>>>> > >>>>> well the backtrace deals with a window that is 320 wide... and > >>>>> data is null to write the grabbed data (converted data from > >>>>> rgb565 to 32bit agb8888) to.. and that is super odd. > >>>> > >>>> I attached gdb when the crash dialog comes up. This is the > >>>> result. Maybe it helps. > >>>> > >>>> http://tux-style.com/tmp/e_backtrace.log > >>> > >>> same problem there too. dest pixel buffer is NULL. thats why it > >>> crashes. i don't know why it's null. evas_object_image_data_get() > >>> is obviously returning NULL. why? is image size 0x0? has > >>> something else happened? e's code doesnt handle a null return > >>> there - so thats why the crash. so you'd get garbage or > >>> blank/black instead if e did... > >>> > >>> e_comp_object.c:e_comp_object_render() > >>> > >>> pix = evas_object_image_data_get() <- there > >>> > >>> why is it null? is is because it was even set to null? i don't > >>> know. i haven't seen this happen with e under xephyr... > >> > >> But xephyr is a good hint. For sure I use this also on my > >> development pc. So I installed it on my Raspi and tried the same. > >> I get an E crash just if I start *ANY* application window inside. > >> Interesting is that Xephyr and the application is still living and > >> usable after the crash in this setup. E own windows like e.g. the > >> file manager are working. > >> > >> I don't understand this. I'm thinking of removing all binaries and > >> install everything again - just to be sure. :-( > >> > >> BTW: I used these releases: > >> > >> econnman-1.1 emotion_generic_players-1.16.0 > >> terminology-0.9.1 efl-1.16.1 enlightenment-0.20.1 > >> elementary-1.16.1 evas_generic_loaders-1.16.0 > >> > >> Do you think there's a chance this is working from GIT? > > > > it should... i see no reason it should not. :/ > > > > enlightenment 20.6 has lots of Fixes for crashes and other issues but > there is also a few more fixes in git so 20.6 could be worth testing > if you want a little more stability.
Hm, the 20.6 seems to work more stable. I don't get this crash. At least other applications seem to work in E20 now. My application has still a problem, but no crash. It seems to be an threading problem. Application mutex is wrong and I didn't notice on my fast pc. But seems not connected to E itself. I'll inform you if I've further problems. thanks!! Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
