Threads shutting down with libextractor. Have you seen this before?

[Dave Myron]

Sorry if this isn't the appropriate way to contact you (though it  
appears to be so from the libextractor page).

I'm getting threads getting stuck when using libextractor. I've  
attached with gdb and here's the pertinent lines from the backtrace:

#0  0x42bd90d4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
#1  0x42bd8708 in __pthread_wait_for_restart_signal () from /lib/i686/
libpthread.so.0
#2  0x42bd8e60 in pthread_create@@GLIBC_2.1 () from /lib/i686/
libpthread.so.0
#3  0xb6c5f6ac in libextractor_exiv2_extract (filename=0x862b970 "/tmp/
CGI.11996.30", data=0xb5f63000 "ÿØÿà", size=341975, prev=0x88713f8) at  
exiv2extractor.cc:466
#4  0xb6f8c037 in getKeywords () from /usr/lib/libextractor.so.1
#5  0xb6f8c1ba in EXTRACTOR_getKeywords () from /usr/lib/
libextractor.so.1

Have you seen that before? Any ideas where to start fixing things?

Thanks so much,
Dave Myron



_______________________________________________
libextractor mailing list
libextractor@...
http://lists.gnu.org/mailman/listinfo/libextractor

[Christian Grothoff]

On Sunday 15 June 2008 12:50:15 am Dave Myron wrote:

> Sorry if this isn't the appropriate way to contact you (though it
> appears to be so from the libextractor page).
>
> I'm getting threads getting stuck when using libextractor. I've
> attached with gdb and here's the pertinent lines from the backtrace:
>
> #0  0x42bd90d4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
> #1  0x42bd8708 in __pthread_wait_for_restart_signal () from /lib/i686/
> libpthread.so.0
> #2  0x42bd8e60 in pthread_create@@GLIBC_2.1 () from /lib/i686/
> libpthread.so.0
> #3  0xb6c5f6ac in libextractor_exiv2_extract (filename=0x862b970 "/tmp/
> CGI.11996.30", data=0xb5f63000 "ÿØÿà", size=341975, prev=0x88713f8) at
> exiv2extractor.cc:466
> #4  0xb6f8c037 in getKeywords () from /usr/lib/libextractor.so.1
> #5  0xb6f8c1ba in EXTRACTOR_getKeywords () from /usr/lib/
> libextractor.so.1
>
> Have you seen that before? Any ideas where to start fixing things?

Three ideas.

1) submit to Mantis the file that you are extracting metadata from (if you
can), then we can see if we can find out what's going on.

2) exiv2 actually starts a second thread -- and waits for that one to
terminate (in order to work around trouble with C++ exceptions and exit
handlers).  So when your run gdb to get stacktraces, you need to look at both
threads (info threads; thread NUM; ba, see also http://gnunet.org/faq.php3 
under reporting deadlocks)

3) You can avoid the threading-mess (at the expense of re-introducing another
bug) by chaning #define WORKAROUND_905 1 to 0 (on top of th exiv2-extractor).  
If you are unfamiliar with threads and do never unload the LE plugins, this
may help your diagnosis.  However, it does not solve the problem and should
not be used in production...


Just to be clear here -- if the code is stuck as your trace seems to indicate,
this is likely a bug in GNU libextractor.  However, you provided insufficient
information for me to try to fix it.  I'll be happy to help given either full
traces for all threads or the input / data given to LE that caused the
problem.

Best,

Christian


_______________________________________________
libextractor mailing list
libextractor@...
http://lists.gnu.org/mailman/listinfo/libextractor