Re: [E-devel] evas_cache segfaults
On Fri, Nov 27, 2009 at 8:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. Are you on svn head ? Anyway, i believe that a cleanup is needed. Currently I much prefer the ecore_thread_run API that provide a clean way to do the same kind of work. But using Ecore API in Evas is not easy to do, and clean. I don't know yet how to move this feature in Evas or Eina yet, but I will look at it this weekend. -- Cedric BAIL -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_cache segfaults
On Fri, 2009-11-27 at 14:08 +0100, Cedric BAIL wrote: On Fri, Nov 27, 2009 at 8:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. Are you on svn head ? Anyway, i believe that a cleanup is needed. Currently I much prefer the ecore_thread_run API that provide a clean way to do the same kind of work. But using Ecore API in Evas is not easy to do, and clean. I don't know yet how to move this feature in Evas or Eina yet, but I will look at it this weekend. Last update was a couple of hours ago. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_cache segfaults
At 9:48am, Viktor Kojouharov wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. I wonder if my e17 segfaults are related to this. I have been getting frequent segfaults since an update of e from svn yesterday. An example bt is given below: #0 0x003f4e20d504 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x003f4e208ee5 in _L_lock_508 () from /lib/libpthread.so.0 #2 0x003f4e208d08 in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7fd6ff3784ac in evas_common_rgba_image_scalecache_prepare (ie=0x24ecb30, dst=0x80, dc=0x20850c0, smooth=1, src_region_x=0, src_region_y=0, src_region_w=128, src_region_h=128, dst_region_x=0, dst_region_y=0, dst_region_w=22, dst_region_h=22) at evas_image_scalecache.c:359 #4 0x7fd6fd8352b8 in eng_image_draw (data=value optimized out, context=0x20850c0, surface=0x23aa0e0, image=0x24ecb30, src_x=0, src_y=0, src_w=128, src_h=128, dst_x=0, dst_y=0, dst_w=22, dst_h=22, smooth=1) at evas_engine.c:759 #5 0x7fd6ff30f05d in evas_object_image_render (obj=0x24edce0, output=value optimized out, context=value optimized out, surface=value optimized out, x=value optimized out, y=value optimized out) at evas_object_image.c:2402 #6 0x7fd6ff338e60 in evas_render_mapped (e=0x2084a80, obj=0x24edce0, context=value optimized out, surface=value optimized out, off_x=value optimized out, off_y=value optimized out, mapped=0) at evas_render.c:769 #7 0x7fd6ff33af4f in evas_render_updates_internal (e=0x2084a80, make_updates=value optimized out, do_draw=value optimized out) at evas_render.c:1034 #8 0x7fd6ff33b3fa in evas_render_updates (e=0x24ecc68) at evas_render.c:1175 #9 0x7fd701309a6d in _ecore_evas_x_render (ee=0x20848b0) at ecore_evas_x.c:161 #10 0x7fd70130b78f in _ecore_evas_x_idle_enter (data=value optimized out) at ecore_evas_x.c:1014 #11 0x7fd6ff5e5ace in _ecore_idle_enterer_call () at ecore_idle_enterer.c:106 #12 0x7fd6ff5e83ad in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:671 #13 0x7fd6ff5e8690 in ecore_main_loop_begin () at ecore_main.c:114 #14 0x0042fa74 in main (argc=1, argv=value optimized out) at e_main.c:1074 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 22997 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_cache segfaults
At 4:30pm, Cedric BAIL wrote: On Fri, Nov 27, 2009 at 4:17 PM, P Purkayastha ppu...@gmail.com wrote: At 9:48am, Viktor Kojouharov wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. I wonder if my e17 segfaults are related to this. I have been getting frequent segfaults since an update of e from svn yesterday. An example bt is given below: #0 0x003f4e20d504 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x003f4e208ee5 in _L_lock_508 () from /lib/libpthread.so.0 #2 0x003f4e208d08 in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7fd6ff3784ac in evas_common_rgba_image_scalecache_prepare This one sounds like referring to the scalecache, not preload. This is just one of the bt's I have been getting. And they all crash at different points. Maybe some common code is triggering all these crashes? Here are some others. The first one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4760 This is very bad. Enlightenment SIGABRT'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebu...) at e_alert.c:129 #8 0x00461ef4 in e_sigabrt_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:208 #9 signal handler called #10 0x003f4d232085 in raise () from /lib/libc.so.6 #11 0x003f4d2334b0 in abort () from /lib/libc.so.6 #12 0x003f4d22b10a in __assert_fail () from /lib/libc.so.6 #13 0x7f8783d6e800 in evas_cache_image_preload_cancel (im=0x2807630, target=value optimized out) at evas_cache_image.c:1327 #14 0x7f87822643b2 in eng_image_data_preload_cancel (data=value optimized out, image=0x1c47, target=0x6) at evas_engine.c:729 #15 0x7f8783d422e6 in evas_object_image_free (obj=0x286d680) at evas_object_image.c:2272 #16 0x7f8783d452ba in evas_object_free (obj=0x286d680, clean_layer=1) at evas_object_main.c:61 #17 0x7f8783d69136 in evas_render_updates_internal (e=0x2337a40, make_updates=value optimized out, do_draw=1 '\001') at evas_render.c:1102 #18 0x7f8783d693fa in evas_render_updates (e=0x1c47) at evas_render.c:1175 #19 0x7f877fd63440 in _eco_cb_border_icon_change (data=value optimized out, ev_type=value optimized out, ev=value optimized out) at eco_event.c:1029 #20 0x7f878400de25 in _ecore_event_call () at ecore_events.c:420 #21 0x7f8784016647 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:791 #22 0x7f8784016690 in ecore_main_loop_begin () at ecore_main.c:114 #23 0x0042fa74 in main (argc=1, argv=value optimized out) at e_main.c:1074 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 7239 The second one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4b68 This is very bad. Enlightenment SEGV'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebug i...) at e_alert.c:129 #8 0x00461fb8 in e_sigseg_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:124 #9 signal handler called #10 _evas_cache_image_entry_preload_remove (ie=0x2908380, target=0x2c000d0) at evas_cache_image.c:442 #11 0x7fd0b0ea980a in evas_cache_image_preload_cancel (im=0xff00ff00, target=0x0) at evas_cache_image.c:1332 #12 0x7fd0af39e3b2 in eng_image_data_preload_cancel (data=value optimized out, image=0xff00ff00, target=0x2c000d0) at evas_engine.c:729 #13 0x7fd0b0e7d2e6 in evas_object_image_free (obj=0x2c000d0) at evas_object_image.c:2272 #14 0x7fd0b0e802ba in evas_object_free
Re: [E-devel] evas_cache segfaults
This last two are the same as problem as Viktor. I am definitively thinking on using ecore_thread_run or some infra like this in evas. It would solve most of our problem I believe, just need a clean way to do it. On Fri, Nov 27, 2009 at 4:45 PM, P Purkayastha ppu...@gmail.com wrote: At 4:30pm, Cedric BAIL wrote: On Fri, Nov 27, 2009 at 4:17 PM, P Purkayastha ppu...@gmail.com wrote: At 9:48am, Viktor Kojouharov wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. I wonder if my e17 segfaults are related to this. I have been getting frequent segfaults since an update of e from svn yesterday. An example bt is given below: #0 0x003f4e20d504 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x003f4e208ee5 in _L_lock_508 () from /lib/libpthread.so.0 #2 0x003f4e208d08 in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7fd6ff3784ac in evas_common_rgba_image_scalecache_prepare This one sounds like referring to the scalecache, not preload. This is just one of the bt's I have been getting. And they all crash at different points. Maybe some common code is triggering all these crashes? Here are some others. The first one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4760 This is very bad. Enlightenment SIGABRT'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebu...) at e_alert.c:129 #8 0x00461ef4 in e_sigabrt_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:208 #9 signal handler called #10 0x003f4d232085 in raise () from /lib/libc.so.6 #11 0x003f4d2334b0 in abort () from /lib/libc.so.6 #12 0x003f4d22b10a in __assert_fail () from /lib/libc.so.6 #13 0x7f8783d6e800 in evas_cache_image_preload_cancel (im=0x2807630, target=value optimized out) at evas_cache_image.c:1327 #14 0x7f87822643b2 in eng_image_data_preload_cancel (data=value optimized out, image=0x1c47, target=0x6) at evas_engine.c:729 #15 0x7f8783d422e6 in evas_object_image_free (obj=0x286d680) at evas_object_image.c:2272 #16 0x7f8783d452ba in evas_object_free (obj=0x286d680, clean_layer=1) at evas_object_main.c:61 #17 0x7f8783d69136 in evas_render_updates_internal (e=0x2337a40, make_updates=value optimized out, do_draw=1 '\001') at evas_render.c:1102 #18 0x7f8783d693fa in evas_render_updates (e=0x1c47) at evas_render.c:1175 #19 0x7f877fd63440 in _eco_cb_border_icon_change (data=value optimized out, ev_type=value optimized out, ev=value optimized out) at eco_event.c:1029 #20 0x7f878400de25 in _ecore_event_call () at ecore_events.c:420 #21 0x7f8784016647 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:791 #22 0x7f8784016690 in ecore_main_loop_begin () at ecore_main.c:114 #23 0x0042fa74 in main (argc=1, argv=value optimized out) at e_main.c:1074 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 7239 The second one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4b68 This is very bad. Enlightenment SEGV'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebug i...) at e_alert.c:129 #8 0x00461fb8 in e_sigseg_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:124 #9 signal handler called #10 _evas_cache_image_entry_preload_remove (ie=0x2908380, target=0x2c000d0) at evas_cache_image.c:442 #11 0x7fd0b0ea980a in evas_cache_image_preload_cancel (im=0xff00ff00,
Re: [E-devel] evas_cache segfaults
On Fri, 27 Nov 2009 17:05:37 +0100 Cedric BAIL cedric.b...@free.fr said: This last two are the same as problem as Viktor. I am definitively thinking on using ecore_thread_run or some infra like this in evas. It would solve most of our problem I believe, just need a clean way to do it. but you can't... maybe just change the infra to be the same as ecore_thread_run inside evas. though it is a queue and it should do things right - whats probably missing is something that ecore_thread wouldnt solve - a missing lock or case somewhere. as long as there is a threaded loader and u are trying to not block the main loop - the problem is the same. On Fri, Nov 27, 2009 at 4:45 PM, P Purkayastha ppu...@gmail.com wrote: At 4:30pm, Cedric BAIL wrote: On Fri, Nov 27, 2009 at 4:17 PM, P Purkayastha ppu...@gmail.com wrote: At 9:48am, Viktor Kojouharov wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. I wonder if my e17 segfaults are related to this. I have been getting frequent segfaults since an update of e from svn yesterday. An example bt is given below: #0 0x003f4e20d504 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x003f4e208ee5 in _L_lock_508 () from /lib/libpthread.so.0 #2 0x003f4e208d08 in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7fd6ff3784ac in evas_common_rgba_image_scalecache_prepare This one sounds like referring to the scalecache, not preload. This is just one of the bt's I have been getting. And they all crash at different points. Maybe some common code is triggering all these crashes? Here are some others. The first one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4760 This is very bad. Enlightenment SIGABRT'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebu...) at e_alert.c:129 #8 0x00461ef4 in e_sigabrt_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:208 #9 signal handler called #10 0x003f4d232085 in raise () from /lib/libc.so.6 #11 0x003f4d2334b0 in abort () from /lib/libc.so.6 #12 0x003f4d22b10a in __assert_fail () from /lib/libc.so.6 #13 0x7f8783d6e800 in evas_cache_image_preload_cancel (im=0x2807630, target=value optimized out) at evas_cache_image.c:1327 #14 0x7f87822643b2 in eng_image_data_preload_cancel (data=value optimized out, image=0x1c47, target=0x6) at evas_engine.c:729 #15 0x7f8783d422e6 in evas_object_image_free (obj=0x286d680) at evas_object_image.c:2272 #16 0x7f8783d452ba in evas_object_free (obj=0x286d680, clean_layer=1) at evas_object_main.c:61 #17 0x7f8783d69136 in evas_render_updates_internal (e=0x2337a40, make_updates=value optimized out, do_draw=1 '\001') at evas_render.c:1102 #18 0x7f8783d693fa in evas_render_updates (e=0x1c47) at evas_render.c:1175 #19 0x7f877fd63440 in _eco_cb_border_icon_change (data=value optimized out, ev_type=value optimized out, ev=value optimized out) at eco_event.c:1029 #20 0x7f878400de25 in _ecore_event_call () at ecore_events.c:420 #21 0x7f8784016647 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:791 #22 0x7f8784016690 in ecore_main_loop_begin () at ecore_main.c:114 #23 0x0042fa74 in main (argc=1, argv=value optimized out) at e_main.c:1074 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 7239 The second one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4b68 This is very bad. Enlightenment SEGV'd.\n\nThis is not meant to happen
Re: [E-devel] evas_cache segfaults
On Sat, 28 Nov 2009, Carsten Haitzler (The Rasterman) wrote: On Fri, 27 Nov 2009 17:05:37 +0100 Cedric BAIL cedric.b...@free.fr said: This last two are the same as problem as Viktor. I am definitively thinking on using ecore_thread_run or some infra like this in evas. It would solve most of our problem I believe, just need a clean way to do it. but you can't... maybe just change the infra to be the same as ecore_thread_run inside evas. though it is a queue and it should do things right - whats probably missing is something that ecore_thread wouldnt solve - a missing lock or case somewhere. as long as there is a threaded loader and u are trying to not block the main loop - the problem is the same. can't hellgrind help for those kind of problems ? Vincent On Fri, Nov 27, 2009 at 4:45 PM, P Purkayastha ppu...@gmail.com wrote: At 4:30pm, Cedric BAIL wrote: On Fri, Nov 27, 2009 at 4:17 PM, P Purkayastha ppu...@gmail.com wrote: At 9:48am, Viktor Kojouharov wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. I wonder if my e17 segfaults are related to this. I have been getting frequent segfaults since an update of e from svn yesterday. An example bt is given below: #0 0x003f4e20d504 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x003f4e208ee5 in _L_lock_508 () from /lib/libpthread.so.0 #2 0x003f4e208d08 in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7fd6ff3784ac in evas_common_rgba_image_scalecache_prepare This one sounds like referring to the scalecache, not preload. This is just one of the bt's I have been getting. And they all crash at different points. Maybe some common code is triggering all these crashes? Here are some others. The first one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4760 This is very bad. Enlightenment SIGABRT'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebu...) at e_alert.c:129 #8 0x00461ef4 in e_sigabrt_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:208 #9 signal handler called #10 0x003f4d232085 in raise () from /lib/libc.so.6 #11 0x003f4d2334b0 in abort () from /lib/libc.so.6 #12 0x003f4d22b10a in __assert_fail () from /lib/libc.so.6 #13 0x7f8783d6e800 in evas_cache_image_preload_cancel (im=0x2807630, target=value optimized out) at evas_cache_image.c:1327 #14 0x7f87822643b2 in eng_image_data_preload_cancel (data=value optimized out, image=0x1c47, target=0x6) at evas_engine.c:729 #15 0x7f8783d422e6 in evas_object_image_free (obj=0x286d680) at evas_object_image.c:2272 #16 0x7f8783d452ba in evas_object_free (obj=0x286d680, clean_layer=1) at evas_object_main.c:61 #17 0x7f8783d69136 in evas_render_updates_internal (e=0x2337a40, make_updates=value optimized out, do_draw=1 '\001') at evas_render.c:1102 #18 0x7f8783d693fa in evas_render_updates (e=0x1c47) at evas_render.c:1175 #19 0x7f877fd63440 in _eco_cb_border_icon_change (data=value optimized out, ev_type=value optimized out, ev=value optimized out) at eco_event.c:1029 #20 0x7f878400de25 in _ecore_event_call () at ecore_events.c:420 #21 0x7f8784016647 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:791 #22 0x7f8784016690 in ecore_main_loop_begin () at ecore_main.c:114 #23 0x0042fa74 in main (argc=1, argv=value optimized out) at e_main.c:1074 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 7239 The second one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4b68 This is very bad. Enlightenment SEGV'd.\n\nThis is not meant to happen and is likely a sign
Re: [E-devel] evas_cache segfaults
On Sat, 28 Nov 2009 06:29:09 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sat, 28 Nov 2009, Carsten Haitzler (The Rasterman) wrote: On Fri, 27 Nov 2009 17:05:37 +0100 Cedric BAIL cedric.b...@free.fr said: This last two are the same as problem as Viktor. I am definitively thinking on using ecore_thread_run or some infra like this in evas. It would solve most of our problem I believe, just need a clean way to do it. but you can't... maybe just change the infra to be the same as ecore_thread_run inside evas. though it is a queue and it should do things right - whats probably missing is something that ecore_thread wouldnt solve - a missing lock or case somewhere. as long as there is a threaded loader and u are trying to not block the main loop - the problem is the same. can't hellgrind help for those kind of problems ? not that i've found. Vincent On Fri, Nov 27, 2009 at 4:45 PM, P Purkayastha ppu...@gmail.com wrote: At 4:30pm, Cedric BAIL wrote: On Fri, Nov 27, 2009 at 4:17 PM, P Purkayastha ppu...@gmail.com wrote: At 9:48am, Viktor Kojouharov wrote: I've been experiencing segfaults in evas_cache for quite some time now. They occur after an image that has been loaded using evas is deleted or moved, however they are not reproducible all the time. Valgrind is also being quite vocal in this situation. I've attached the valgrind output and a gdb backtrace for anyone familiar with the evas internals who has a free time to look into it. I wonder if my e17 segfaults are related to this. I have been getting frequent segfaults since an update of e from svn yesterday. An example bt is given below: #0 0x003f4e20d504 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x003f4e208ee5 in _L_lock_508 () from /lib/libpthread.so.0 #2 0x003f4e208d08 in pthread_mutex_lock () #from /lib/libpthread.so.0 3 0x7fd6ff3784ac in #evas_common_rgba_image_scalecache_prepare This one sounds like referring to the scalecache, not preload. This is just one of the bt's I have been getting. And they all crash at different points. Maybe some common code is triggering all these crashes? Here are some others. The first one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6 #5 0x003f4f24ead1 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x003f4f235478 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0047752c in e_alert_show ( text=0x4d4760 This is very bad. Enlightenment SIGABRT'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebu...) at e_alert.c:129 #8 0x00461ef4 in e_sigabrt_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:208 #9 signal handler called #10 0x003f4d232085 in raise () from /lib/libc.so.6 #11 0x003f4d2334b0 in abort () from /lib/libc.so.6 #12 0x003f4d22b10a in __assert_fail () from /lib/libc.so.6 #13 0x7f8783d6e800 in evas_cache_image_preload_cancel (im=0x2807630, target=value optimized out) at evas_cache_image.c:1327 #14 0x7f87822643b2 in eng_image_data_preload_cancel (data=value optimized out, image=0x1c47, target=0x6) at evas_engine.c:729 #15 0x7f8783d422e6 in evas_object_image_free (obj=0x286d680) at evas_object_image.c:2272 #16 0x7f8783d452ba in evas_object_free (obj=0x286d680, clean_layer=1) #at evas_object_main.c:61 #17 0x7f8783d69136 in evas_render_updates_internal (e=0x2337a40, make_updates=value optimized out, do_draw=1 '\001') at evas_render.c:1102 #18 0x7f8783d693fa in evas_render_updates (e=0x1c47) at evas_render.c:1175 #19 0x7f877fd63440 in _eco_cb_border_icon_change (data=value #optimized out, ev_type=value optimized out, ev=value optimized out) at eco_event.c:1029 #20 0x7f878400de25 in _ecore_event_call () at ecore_events.c:420 #21 0x7f8784016647 in _ecore_main_loop_iterate_internal (once_only=0) #at ecore_main.c:791 #22 0x7f8784016690 in ecore_main_loop_begin () at ecore_main.c:114 #23 0x0042fa74 in main (argc=1, argv=value optimized out) at e_main.c:1074 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 7239 The second one: #0 0x003f4d2c50d3 in poll () from /lib/libc.so.6 #1 0x003f4f60ab4a in ?? () from /usr/lib/libxcb.so.1 #2 0x003f4f60c15f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x003f4f24ded8 in ?? () from /usr/lib/libX11.so.6 #4 0x003f4f24e27d in ?? () from /usr/lib/libX11.so.6
