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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
