Hi! No need for a trace, I've reproduced the issue and this is the same bug as
https://ng.gnunet.org/bugs/view.php?id=1493 The problem is (ultimately) in libgsf / glib and caused by some strange (glib- based) interaction between libgsf (ole2 extractor) and the GTK-based thumbnail extractor (both use glib). I've already implemented a fix that prevents this kind of crash in general in libextractor 0.6.0 (unreleased), but that version of LE will require GNUnet 0.9.x (also unreleased). In the meantime, possible workarounds include removing the "thumbnail" entry from gnunet.conf (under [FS] the line "EXTRACTORS=" typically lists "- libextractor_thumbnail", which is one of the two plugins causing the issue) or simply deleting the respective plugins (rm /usr/lib/libextractor/libextractorthumb*). With either of these changes, gnunet-gtk / gnunet-auto-share should at least not crash. For those interested, here is what a valgrind-trace looks like: ==11038== ==11038== Jump to the invalid address stated on the next line ==11038== at 0x4BD78E0: ??? ==11038== by 0x42370F7: g_type_class_ref (gtype.c:2647) ==11038== by 0x421E125: g_object_newv (gobject.c:1157) ==11038== by 0x421E589: g_object_new_valist (gobject.c:1323) ==11038== by 0x421E70D: g_object_new (gobject.c:1086) ==11038== by 0x41E79EA: gsf_input_memory_new (gsf-input-memory.c:77) ==11038== by 0x403FEA5: libextractor_ole2_extract (ole2extractor.c:457) ==11038== by 0x404F398: getKeywords (extractor.c:1271) ==11038== by 0x404F539: EXTRACTOR_getKeywords (extractor.c:1338) ==11038== by 0x804A50D: main (extract.c:666) ==11038== Address 0x4bd78e0 is not stack'd, malloc'd or (recently) free'd ==11038== ==11038== ==11038== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==11038== Access not within mapped region at address 0x4BD78E0 ==11038== at 0x4BD78E0: ??? ==11038== by 0x42370F7: g_type_class_ref (gtype.c:2647) ==11038== by 0x421E125: g_object_newv (gobject.c:1157) ==11038== by 0x421E589: g_object_new_valist (gobject.c:1323) ==11038== by 0x421E70D: g_object_new (gobject.c:1086) ==11038== by 0x41E79EA: gsf_input_memory_new (gsf-input-memory.c:77) ==11038== by 0x403FEA5: libextractor_ole2_extract (ole2extractor.c:457) ==11038== by 0x404F398: getKeywords (extractor.c:1271) ==11038== by 0x404F539: EXTRACTOR_getKeywords (extractor.c:1338) ==11038== by 0x804A50D: main (extract.c:666) ==11038== If you believe this happened as a result of a stack ==11038== overflow in your program's main thread (unlikely but ==11038== possible), you can try to increase the size of the ==11038== main thread stack using the --main-stacksize= flag. ==11038== The main thread stack size used in this run was 8388608. Best, Christian On Saturday 19 December 2009 02:57:02 pm [email protected] wrote: > Christian said:--------------- > If you can make the specific file available and specify the version of > libextractor that is in use (dpkg --list | grep libextractor) we can either > see if this has been fixed or can easily be fixed. > > Result:----------------------- > See the png file attached to this message. This one crashed gnunet-gtk, as > do others. > > dpkg --list | grep libextractor > ii libextractor-plugins 0.5.21+dfsg-3ubuntu1 > extracts meta-data from files of arbitrary t ii libextractor1c2a > 0.5.21+dfsg-3ubuntu1 extracts > meta-data from files of arbitrary t > _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
