sigsuspend during gpgme_engine_check_version

Максим Зиналь Zlat0 at mail.ru
Tue May 17 21:32:23 CEST 2005


Tyler Retzlaff wrote:
> I don't have any significant experience with threaded programming but 
> maybe someone can tell me whats going on here.  During 
> gpgme_engine_check_version the gpgme thread (I think) ends up it 
> sigsuspend() waiting for a signal.  (A gdb backtrace follows)
> 
> some background about the application:
> The application using gpgme is heavily threaded (though only one 
> "worker" thread is accessing the gpgme library).  In addition the 
> application catches most signals (perhaps a source of the problem?)
> 
> Anyway, since at the point this happens only one thread is normally 
> active this call to gpgme_engine_check_version causes the entire app to 
> hang.  I'm not sure if I have to kick gpgme in the guts somehow to get 
> things moving... advice would be good.
> 
> 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6
> (gdb) bt
> #0  0x42028d69 in sigsuspend () from /lib/i686/libc.so.6
> #1  0x4034e108 in __pthread_wait_for_restart_signal () from 
> /lib/i686/libpthread.so.0
> #2  0x4034e8d3 in pthread_onexit_process () from /lib/i686/libpthread.so.0
> #3  0x4034e744 in pthread_kill_other_threads_np () from 
> /lib/i686/libpthread.so.0
> #4  0x420ae6b5 in execve () from /lib/i686/libc.so.6
> #5  0x420ae742 in execv () from /lib/i686/libc.so.6
> #6  0x40034bf6 in _gpgme_io_spawn (path=0x40037efb "/usr/bin/gpg", 
> argv=0xfffffffc, fd_child_list=0x40037efb, fd_parent_list=0x540b6f7c) at 
> posix-io.c:252
> #7  0x400363d5 in _gpgme_get_program_version (file_name=0x40037efb 
> "/usr/bin/gpg") at version.c:184
> #8  0x40031d64 in gpg_get_version () at rungpg.c:236
> #9  0x40031072 in engine_get_version (proto=1108517584) at engine.c:78
> #10 0x400310ff in gpgme_engine_check_version (proto=1073970939) at 
> engine.c:102
> #11 0x08216e91 in CEncryptionThread (this=0x8692768, esb=0x41fdd528) at 
> /development/CEncryptionThread.cpp:27
> #12 0x082149f4 in io::CEncryptedStreamBuffer::open(char const*, 
> std::_Ios_Openmode) (this=0x41fdd528, file=0x83ddb8c 
> "/var/spool/files/xyz.agf", mode=16)
>     at /development/CEncryptedStreamBuffer.cpp:103
> #13 0x08213d38 in io::CEncryptedStream::open(char const*, 
> std::_Ios_Openmode) (this=0x41fdd508, file=0x83ddb8c 
> "/var/spool/files/xyz.agf", mode=16)
>     at /development/CEncryptedStream.cpp:28
> 

The lockup occured at execv() call, which is not a normal situation.
Perhaps your Linux system has an old threading library (LinuxThreads?)
which doesn't work quite well for complex application, especially
with complex signal handling code. Try testing your code with
magical `LD_ASSIME_KERNEL=2.2.5`. Also consider testing it on a
modern Linux distribution with NPTL support.

--
   Max Zinal.



More information about the Gnupg-devel mailing list