[gpgme] fork() problem

[Stephan Menzel]

Am Mittwoch, 14. Februar 2007 16:32:03 schrieb Stephan Menzel:
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xb711d885 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2  0xb711f002 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3  0xb7117318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
> #4  0xb6731e03 in _gpgme_ath_mutex_lock (lock=0x0) at ath.c:71
> #5  0xb6741e2f in _gpgme_sema_cs_enter (s=0xb674db40) at posix-sema.c:48
> #6  0xb673bd3b in _gpgme_engine_info_copy (r_info=0x0) at engine.c:225
> #7  0xb6743070 in gpgme_new (r_ctx=0x0) at gpgme.c:58

... but not all of them.
Got another one like this:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb70c4885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb70c6002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb70be318 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0xb66d8e52 in _gpgme_ath_mutex_unlock (lock=0x0) at ath.c:83
#5  0xb66e8e5f in _gpgme_sema_cs_leave (s=0xb66f4b20) at posix-sema.c:54
#6  0xb66e2e84 in _gpgme_engine_info_copy (r_info=0x0) at engine.c:298
#7  0xb66ea074 in gpgme_new (r_ctx=0x0) at gpgme.c:55

perhaps those Macros LOCK and UNLOCK act on null initailized pointers when you 
do

int ath_mutex_unlock (ath_mutex_t *lock)
{
#ifndef NDEBUG
  assert (*lock == MUTEX_LOCKED);

  *lock = MUTEX_UNLOCKED;
#endif
  return 0;
}

It looks like there is a null pointer coming in all those cases.


Stephan, hth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070214/06916d78/attachment.pgp