Tue 06 Jan 2015 01:21:54 AM UTC, comment #3:
On mailing list, Jean indicates issue is w/ libgcrypt 1.6.2.
After some trial and error, it appears this began with libgcrypt 1.6.0. On my system, I see the trace
Program terminated with signal 11, Segmentation fault.
#0 __pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
50 unsigned int type = PTHREAD_MUTEX_TYPE (mutex);
(gdb) bt
#0 __pthread_mutex_lock (mutex=0x0) at pthread_mutex_lock.c:50
#1 0x00002aaaab80509d in lock_fsm () at fips.c:225
#2 0x00002aaaab805905 in _gcry_fips_is_operational () at fips.c:367
#3 0x00002aaaab7ffee3 in _gcry_vcontrol (cmd=<value optimized out>, arg_ptr=<value optimized out>) at global.c:474
#4 0x00002aaaab7fdfed in gcry_control (cmd=<value optimized out>) at visibility.c:79
#5 0x00002aaaab2a1fcc in crypt_init () at libcommon/ipmi-crypt.c:84
#6 0x00002aaaab2962e9 in ipmi_rmcpplus_init () at interface/ipmi-rmcpplus-interface.c:218
it devolves down into this code in pthread in glibc.
int
__pthread_mutex_lock (mutex)
pthread_mutex_t *mutex;
{
assert (sizeof (mutex->__size) >= sizeof (mutex->__data));
unsigned int type = PTHREAD_MUTEX_TYPE (mutex);
PTHREAD_MUTEX_TYPE is a macro that dereferences the mutex. So there's the segfault.
The issue is why is __pthread_mutex_lock() being called with a bad pointer.
It should be noted that this appears to be an issue that only arises when multiple nodes are specified.
> ipmi-config -h "node1" --listsections --driver-type="lan20"
./ipmi-config: invalid hostname
> ipmi-config -h "node[0-1]" --listsections --driver-type="lan20"
Segmentation fault (core dumped)
So it may have to do with a minor change in the API in regards to initializing the library. More investigation needed ...
|