Re: [Help-gnunet] Gnunet segmentation fault on png publish

[awd-s]

I edited gnunet-conf, removing ":-libextractor_thumbnail". Publication of the 
png file proceeded without problem.

Thank you both for your help.


-----Original Message-----
From: Christian Grothoff [mailto:address@hidden
Sent: Saturday, December 19, 2009 04:41 PM
To: address@hidden
Cc: address@hidden, 'Milan Bouchet-Valat'
Subject: Re: [Help-gnunet] Gnunet segmentation fault on png publish

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 address@hidden 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
>