|
|
Related packages:
libglib2.0-0 2.20.4-1
libgtk2.0-0 2.16.4-1 |
|
|
|
(10:55:17) fiddur: nil1: This will probably be more helpful: http://pastebin.com/m447139d5 ...but now it's not rpm that segfaults anymore?!
(10:55:49) fiddur: another strange thing is that is seems to take that file twice... and the first time it works... or maybe it indexes it first and extracts the keywords afterwards?
(10:56:02) nil: okay, that'd explain it
(10:56:22) nil: the OLE extractor is/was known to behave badly
(10:57:57) nil: fiddur: move the ole extractor away (by renaming) and try again
(11:00:15) fiddur: now it segfaults on thumnailextractor instead.... #8 0xf6a8aae2 in libextractor_thumbnailgtk_extract (filename=0x8099a70 "/media/freya/sorted/6/666/artist.jpg", data=0xf6904000 "\377\330\377", <incomplete sequence \340>, size=11326, prev=0x80744b0) at thumbnailextractor.c:116 |
|
|
|
$ extract -V -l libextractor_thumbnailgtk.so artist.jpg
Segmentation fault |
|
|
|
Here is another trace of this crash:
$ valgrind --tool=memcheck extract -V -l libextractor_thumbnailgtk.so artist.jpg
==27780== Memcheck, a memory error detector
==27780== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==27780== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==27780== Command: extract -V -l libextractor_thumbnailgtk.so artist.jpg
==27780==
==27780== Jump to the invalid address stated on the next line
==27780== at 0x4EA38E0: ???
==27780== by 0x42370F7: g_type_class_ref (gtype.c:2647)
==27780== by 0x421E125: g_object_newv (gobject.c:1157)
==27780== by 0x421E589: g_object_new_valist (gobject.c:1323)
==27780== by 0x421E70D: g_object_new (gobject.c:1086)
==27780== by 0x41E79EA: gsf_input_memory_new (gsf-input-memory.c:77)
==27780== by 0x4A94EB5: libextractor_ole2_extract (ole2extractor.c:457)
==27780== by 0x402D3D8: getKeywords (extractor.c:1280)
==27780== by 0x402D579: EXTRACTOR_getKeywords (extractor.c:1347)
==27780== by 0x804A51D: main (extract.c:666)
==27780== Address 0x4ea38e0 is not stack'd, malloc'd or (recently) free'd
==27780==
==27780==
==27780== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==27780== Access not within mapped region at address 0x4EA38E0
==27780== at 0x4EA38E0: ???
==27780== by 0x42370F7: g_type_class_ref (gtype.c:2647)
==27780== by 0x421E125: g_object_newv (gobject.c:1157)
==27780== by 0x421E589: g_object_new_valist (gobject.c:1323)
==27780== by 0x421E70D: g_object_new (gobject.c:1086)
==27780== by 0x41E79EA: gsf_input_memory_new (gsf-input-memory.c:77)
==27780== by 0x4A94EB5: libextractor_ole2_extract (ole2extractor.c:457)
==27780== by 0x402D3D8: getKeywords (extractor.c:1280)
==27780== by 0x402D579: EXTRACTOR_getKeywords (extractor.c:1347)
==27780== by 0x804A51D: main (extract.c:666)
==27780== If you believe this happened as a result of a stack
==27780== overflow in your program's main thread (unlikely but
==27780== possible), you can try to increase the size of the
==27780== main thread stack using the --main-stacksize= flag.
==27780== The main thread stack size used in this run was 8388608.
==27780==
==27780== HEAP SUMMARY:
==27780== in use at exit: 74,208 bytes in 816 blocks
==27780== total heap usage: 3,733 allocs, 2,917 frees, 510,093 bytes allocated
==27780==
==27780== LEAK SUMMARY:
==27780== definitely lost: 120 bytes in 1 blocks
==27780== indirectly lost: 0 bytes in 0 blocks
==27780== possibly lost: 18,116 bytes in 328 blocks
==27780== still reachable: 54,088 bytes in 440 blocks
==27780== suppressed: 1,884 bytes in 47 blocks
==27780== Rerun with --leak-check=full to see details of leaked memory
==27780==
==27780== For counts of detected and suppressed errors, rerun with: -v
==27780== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 203 from 8)
Segmentation fault |
|
|
|
More info (especially versions):
$ ldd bin/extract
linux-gate.so.1 => (0x00509000)
libextractor.so.1 => /home/grothoff/lib/libextractor.so.1 (0x00dae000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00151000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x001f2000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00602000)
libz.so.1 => /lib/libz.so.1 (0x00c85000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00c13000)
libgsf-1.so.114 => /usr/lib/debug/libgsf-1.so.114 (0x00827000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00110000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00a6c000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00336000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00155000)
/lib/ld-linux.so.2 (0x00726000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00f26000)
libpcre.so.3 => /lib/libpcre.so.3 (0x0086a000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x0016e000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x0077b000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0x0049e000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0098a000) |
|
|
|
This problemno longer arises in SVN HEAD (using new libextractor 0.6.0 out-of-process plugin API). The fact that threads are not used and that the entire linkage doesn't happen in the main process seems to prevent the crash itself, not just hide it. |
|
