mandos server segfault problem

[Eurobiz computer administration]

at booting mandos server fails. Even a simple 'mandos --version' also fails with
Segmentation fault (core dumped)

syslog says e.g.:
mandos[11084]: segfault at c ip 00427cb7 sp bfeec2b0 error 4 in libpthread-2.15.so[41f000+17000]

this problem is reproducable on

i386, 2 CPUs, Ubuntu precise, mandos version 1.4.0-1
i386, 2 CPUs, Ubuntu precise, mandos manually upgraded to quantal package version 1.5.5-1
amd64, 1 CPU, Ubuntu precise, mandos version 1.4.0-1
amd64, 1 CPU, Ubuntu precise, mandos manually upgraded to quantal package version 1.5.5-1
amd64, 1 CPU, Ubuntu precise, mandos manually downgraded to oneiric package version 1.3.0-1ubuntu1

Mandos does not have this problem on machine with older Ubuntu version, e.g.
amd64, 1 CPU, Ubuntu oneiric, mandos version 1.3.0-1ubuntu1
amd64, 1 CPU, Ubuntu oneiric, mandos manually upgraded to precise package version 1.4.0-1
amd64, 1 CPU, Ubuntu oneiric, mandos manually upgraded to quantal package version 1.5.5-1

a 'python -v /usr/sbin/mandos' says:

dlopen("/usr/lib/pymodules/python2.7/gnutls/library/_init.so", 2);
import gnutls.library._init # dynamically loaded from /usr/lib/pymodules/python2.7/gnutls/library/_init.so
Segmentation fault (core dumped)

[Mandos Maintainers (mandos-maintainers)]

When downgrading libgcrypt11 from version 1.5.0-3ubuntu1 to version 1.5.0-3, the bug disappears.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jason Conti (jconti)]

Looking at the stacktrace top when we crash on 'import gnutls.crypto':

#0 __pthread_mutex_lock (mutex=0x7ffff56f32c4) at pthread_mutex_lock.c:50
#1 0x00007ffff4f6c7bd in mutex_init (lock=0x7ffff520e228, just_check=1) at ath.c:132
#2 0x00007ffff4f6c91d in _gcry_ath_mutex_lock (lock=0x7ffff520e228) at ath.c:186
#3 0x00007ffff4f69b2d in _gcry_secmem_get_flags () at secmem.c:443
#4 0x00007ffff4f633e0 in _gcry_vcontrol (cmd=GCRYCTL_SUSPEND_SECMEM_WARN, arg_ptr=0x7ffffffef158) at global.c:378
#5 0x00007ffff4f600cd in gcry_control (cmd=GCRYCTL_SUSPEND_SECMEM_WARN) at visibility.c:78

We are crashing in gnutls/library/__init__.py. Because of bug 423252, global_init() for libgcrypt is not being called on GCRYCTL_SET_THREAD_CBS anymore, so when GCRYCTL_SUSPEND_SECMEM_WARN is called, it tries to acquire the mutex, which has never been initialized.

As suggested in the comments for global_init(), adding: libgnutls.gcry_check_version(None) just before the call to GCRYCTL_SUSPEND_SECMEM_WARN will force a call to global_init(), and there isn't a crash on 'import gnutls.crypto'.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "gcrypt-call-global-init.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Jason Conti (jconti)]

I'm going to mark this as a duplicate of bug #1013798. It is the same sort of issue, and the patch there should fix it by calling global_init() before GCRYCTL_SUSPEND_SECMEM_WARN.