On Tuesday 01 December 2009 16:40:50 Andreas Volz wrote: > Am Fri, 27 Nov 2009 09:48:17 +0200 schrieb Viktor Kojouharov: > > 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. > > Hello, > > same problem another stack trace: > > #6 0xb75a7917 in _XReadEvents () from /usr/lib/libX11.so.6 > #7 0xb758d538 in XNextEvent () from /usr/lib/libX11.so.6 > #8 0x080d82ed in e_alert_show ( > text=0x81594d8 "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 > #9 0x080bb71f in e_sigabrt_act (x=6, info=0xbffda98c, data=0xbffdaa0c) > at e_signals.c:208 > #10 <signal handler called> > #11 0xb7fc2430 in __kernel_vsyscall () > #12 0xb741e8a0 in raise () from /lib/tls/i686/cmov/libc.so.6 > #13 0xb7420268 in abort () from /lib/tls/i686/cmov/libc.so.6 > #14 0xb741772e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #15 0xb79343b5 in evas_cache_image_load_data (im=0x8f2bb30) > at evas_cache_image.c:1247 > #16 0xb7980ff1 in evas_common_rgba_image_scalecache_do (ie=0x8f2bb30, > dst=0x93010e8, dc=0x8ede960, smooth=1, src_region_x=0, > src_region_y=0, src_region_w=48, src_region_h=48, dst_region_x=58, > dst_region_y=7, dst_region_w=14, dst_region_h=14) at > evas_image_scalecache.c:680 #17 0xb7066b8a in eng_image_draw > (data=0x8edc3a0, context=0x8ede960, surface=0x93010e8, > image=0x8f2bb30, src_x=0, src_y=0, src_w=48, src_h=48, dst_x=58, > dst_y=7, dst_w=14, dst_h=14, smooth=1) at evas_engine.c:762 #18 > 0xb78f9545 in evas_object_image_render (obj=0x90d59a8, > output=0x8edc3a0, context=0x8ede960, surface=0x93010e8, x=-112, y=-6) > at evas_object_image.c:2402 > #19 0xb792a1c6 in evas_render_mapped (e=0x8edc1f0, obj=0x90d59a8, > context=0x8ede960, surface=0x93010e8, off_x=-112, off_y=-6, > mapped=0) at evas_render.c:769 > #20 0xb792b414 in evas_render_updates_internal (e=0x8edc1f0, > make_updates=1 '\001', do_draw=1 '\001') at evas_render.c:1034 > #21 0xb792b91a in evas_render_updates (e=0x8edc1f0) at > evas_render.c:1175 #22 0xb7f9ad9b in _ecore_evas_x_render > (ee=0x8edc0d8) at ecore_evas_x.c:296 #23 0xb7f9c662 in > _ecore_evas_x_idle_enter (data=0x0) at ecore_evas_x.c:1014 #24 > 0xb7a91ef8 in _ecore_idle_enterer_call () at ecore_idle_enterer.c:106 > #25 0xb7a96236 in _ecore_main_loop_iterate_internal (once_only=0) at > ecore_main.c:801 > #26 0xb7a951bb in ecore_main_loop_begin () at ecore_main.c:114 > #27 0x0807002e in main (argc=1, argv=0xbffde614) at e_main.c:1074 > > Maybe this helps... > > regards > Andreas
It would help if you could tell us *exactly* what you were doing when you got this segfault. This is very hard to reproduce, and happens when you don't expect it. So any information on how to reproduce it will be useful. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
