freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] [bug #43913] Segmentation fault with driver-type=lan20


From: Albert Chu
Subject: [Freeipmi-devel] [bug #43913] Segmentation fault with driver-type=lan20
Date: Tue, 06 Jan 2015 01:21:54 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0

Follow-up Comment #3, bug #43913 (project freeipmi):

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 ...


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43913>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]