Re: Segfaults and double free errors using getaddrinfo_a

["Ryan S. Arnold" <ryan dot arnold at gmail dot com>]

On Wed, Jul 11, 2012 at 11:46 AM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 3:25 AM, Daurnimator <quae@daurnimator.com> wrote:
>> While using getaddrinfo_a through the luajit ffi
>> (http://luajit.org/ext_ffi.html) I keep getting segfaults or double
>> free errors.
>> The errors seems to disappear if I use LD_PRELOAD=/lib/libpthread.so
>> I've been unable to reduce the code down to a C test case, so all I
>> can show is some luajit code: http://codepad.org/lyLVwfAd
>>
>> Example backtrace:
>>
>> *** glibc detected *** luajit: double free or corruption (out):
>> 0x00007fc000000940 ***
>> ======= Backtrace: =========
>> /lib/libc.so.6(+0x784a6)[0x7fc00e62a4a6]
>> /lib/libc.so.6(fclose+0x14d)[0x7fc00e61adcd]
>> /lib/libnss_files.so.2(+0x3a25)[0x7fc00df88a25]
>> /lib/libnss_files.so.2(_nss_files_gethostbyname4_r+0x2e9)[0x7fc00df89e69]
>> /lib/libc.so.6(+0xce95a)[0x7fc00e68095a]
>> /lib/libc.so.6(getaddrinfo+0xf4)[0x7fc00e683d34]
>> /usr/lib/libanl.so(+0x1029)[0x7fc00e3af029]
>> /lib/libpthread.so.0(+0x7e0f)[0x7fc00e199e0f]
>> /lib/libc.so.6(clone+0x6d)[0x7fc00e69604d]

So what seems to be happening here is the the lock guarding the
critical sections in the _nss_files_gethostbyname4_r function, namely
__libc_lock_lock (lock), is actually no-oping and therefore we're
seeing two threads executing in the same critical section, which
explains why, under observation, the program fails in several
different ways (in the same code path).

This is happening because that lock is in libnss_files.so.2 and this
__libc_lock_lock (lock) translates to a
__libc_maybe_call(__pthread_mutex_lock).

The application has no hard dependency on pthread_mutex_lock.  At the
point where this is called the libpthread library hasn't been loaded
and therefore the __pthread_mutex_lock symbol hasn't been resolved
into the PLT and therefore libc_maybe_call simply no-ops the lock.

This would explain why the program works when you
LD_PRELOAD=libpthread.so.2.  The symbol is resolved and the PLT entry
is there when the __libc_maybe_call(__pthread_mutex_lock) calls checks
for it.

I've verified that this is indeed the case under the debugger.

I'm not sure how to rectify this situation.  Perhaps if luajit does
some linking of the foreign interface code under the covers and you
can force it to link in the pthread_mutex_lock symbol in the
dependency list.  You'll probably have to make sure the symbol isn't
purged, via -lpthread -Wl,-u,__pthread_mutex_lock.

I hope this helps.

Ryan S. Arnold