On Sat, Sep 17, 2011 at 06:06:22PM +0200, Vincent Torri wrote: > > hi everyone, > > > > i'm moving on on my little pdf viewer and I have a segfault bound to > > the photocam widget. > > > > the code is still compiled against latest svn trunk. > > > > reproducing the bug can be done this way: > > > > source code: > > http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/main.c > > two pdf files to open: > > http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/small.pdf > > http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/big.pdf > > > > as a dependency you need poppler-utils (pdfinfo and pdftoppm) > > in case it interest you, there is epdf, a lib that allow you to have an > evas smart object that display a page of a pdf document
hi, thanks for the hint. actually, I saw it when checkouting but the "PROTO" directory discouraged me from using it. anyway, i'd like to keep the dependencies low. as more info for my bug, I managed to avoid the segfault flusing the cache by using evas_render_idle_flush(evas_object_evas_get(photocam)); it doesn't segfault anymore but the image displayed is not correct Fred > > > > two scenarios: > > 1) open small.pdf > > zoom in > > open big.pdf > > > > -> you can only see a subpart of big.pdf with size equal > > to size of small.pdf > > > > 2) open big.pdf > > zoom out > > open small.pdf > > > > -> segfault > > > > here is gdb output: > > > > Program received signal SIGSEGV, Segmentation fault. > > evas_image_load_file_data_jpeg_internal (ie=0x87b1d0, > > map=0x7ffff194c000, > > size=36281, error=0x7fffffffdc6c) at evas_image_load_jpeg.c:658 > > 658 *ptr2 = ARGB_JOIN(0xff, > > ptr[0], ptr[1], ptr[2]); > > > > with the following stack trace: > > > > #0 evas_image_load_file_data_jpeg_internal (ie=0x87b1d0, > > map=0x7ffff194c000, size=36281, error=0x7fffffffdc6c) > > at evas_image_load_jpeg.c:658 > > #1 0x00007ffff14fbf1e in evas_image_load_file_data_jpeg (ie=0x87b1d0, > > file=<optimized out>, key=<optimized out>, error=0x7fffffffdc6c) > > at evas_image_load_jpeg.c:903 > > #2 0x00007ffff784f0fb in evas_common_load_rgba_image_data_from_file ( > > ie=0x87b1d0) at evas_image_load.c:338 > > #3 0x00007ffff7827e87 in evas_cache_image_load_data (im=0x87b1d0) > > at evas_cache_image.c:1197 > > #4 0x00007ffff78515ab in evas_common_rgba_image_scalecache_do ( > > ie=0x87b1d0, dst=0x7fffe8006750, dc=0x63f250, smooth=<optimized out>, > > src_region_x=0, src_region_y=0, src_region_w=512, src_region_h=512, > > dst_region_x=874, dst_region_y=213, dst_region_w=184, dst_region_h=184) > > at evas_image_scalecache.c:799 > > #5 0x00007ffff1f887ad in eng_image_draw (data=<optimized out>, > > context=0x63f250, surface=0x7fffe8006750, image=0x87b1d0, src_x=0, > > src_y=0, src_w=512, src_h=512, dst_x=874, dst_y=213, dst_w=184, > > dst_h=184, smooth=0) at evas_engine.c:544 > > #6 0x00007ffff77e2bab in evas_object_image_render (obj=0x7ffff170a150, > > output=0x62f4c0, context=0x63f250, surface=0x7fffe8006750, x=0, y=0) > > at evas_object_image.c:2898 > > #7 0x00007ffff781c508 in evas_render_mapped (e=0x632fd0, > > obj=0x7ffff170a150, context=0x63f250, surface=0x7fffe8006750, off_x=0, > > off_y=0, mapped=0, ecx=0, ecy=0, ecw=1920, ech=1118) > > at evas_render.c:1062 > > #8 0x00007ffff781efb6 in evas_render_updates_internal (e=0x632fd0, > > make_updates=1 '\001', do_draw=1 '\001') at evas_render.c:1378 > > #9 0x00007ffff6717054 in _ecore_evas_x_render (ee=0x633b30) > > at ecore_evas_x.c:397 > > #10 0x00007ffff67143c1 in _ecore_evas_idle_enter (data=<optimized out>) > > at ecore_evas.c:51 > > #11 0x00007ffff693065e in _ecore_call_task_cb (data=<optimized out>, > > func=<optimized out>) at ecore_private.h:246 > > #12 _ecore_idle_enterer_call () at ecore_idle_enterer.c:165 > > #13 0x00007ffff6931cfb in _ecore_main_loop_iterate_internal (once_only=0) > > at ecore_main.c:1718 > > #14 0x00007ffff693233f in ecore_main_loop_begin () at ecore_main.c:861 > > #15 0x00000000004022bf in elm_main (argc=<optimized out>, > > argv=<optimized out>) at main.c:288 > > #16 0x00007ffff744eead in __libc_start_main () > > from /lib/x86_64-linux-gnu/libc.so.6 > > #17 0x0000000000401759 in _start () > > > > I also tried a quick run of valgrind but he seems to complain about other > > kind of problems. > > > > am I doing something wrong here ? > > I tried to invalidate the caches with elm_all_flush but it didn't > > change anything. > > > > Fred > > -- > > Frederic WAGNER > > Assistant professor ENSIMAG - INPG > > Laboratoire d'Informatique de Grenoble - MOAIS team > > http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/perso.html > > > > ------------------------------------------------------------------------------ > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > > http://p.sf.net/sfu/rim-devcon-copy2 > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Frederic WAGNER Assistant professor ENSIMAG - INPG Laboratoire d'Informatique de Grenoble - MOAIS team http://www-id.imag.fr/Laboratoire/Membres/Wagner_Frederic/perso.html ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel