Re: dynamic linker issue

[Rich Felker <dalias@libc.org>]

On Thu, Jul 09, 2015 at 05:11:59PM +0200, Natanael Copa wrote:
> Hi,
> 
> I have a weird issue with libvirtd segfaulting:
> 
> BUG at file position route/tc.c:1009:rtnl_tc_register
> Assertion failed: 0 (route/tc.c: rtnl_tc_register: 1009)
> Aborted (core dumped)
> 
> It happens here:
> https://github.com/thom311/libnl/blob/48182486341d1de7892494f272e892c0b18ebef5/lib/route/tc.c#L1008
> 
> gdb with a breakpoint showed that to_kind is set, but to_type is definitively wrong:
> <ncopa> (gdb) print blackhole_ops
> <ncopa> $1 = {to_kind = 0x614d43a1026e "blackhole", to_type = 1136841632, to_size = 0, 
> <ncopa>   to_dump = {0x0, 0x0, 0x0}, to_msg_fill = 0x0, to_msg_fill_raw = 0x0, 
> <ncopa>   to_msg_parser = 0x0, to_free_data = 0x0, to_clone = 0x0, to_list = {
> <ncopa>     next = 0x0, prev = 0x0}}
> 
> ..to_type is initialized here:
> 
> https://github.com/thom311/libnl/blob/48182486341d1de7892494f272e892c0b18ebef5/lib/route/qdisc/blackhole.c
> 
> So this smells like the dynamic linker is corrupting memory when gnu
> hash is used.

I don't see any evidence to believe the problem is gnu_hash, and the
fact that Alpine seems to have patched binutils to suppress generation
of the standard sysv hash tables makes it impossible to test this
hypothesis by disabling the gnu_hash code path without rebuilding the
whole system from source. :( There should not be any way that the
gnu_hash code could result in incorrect writes to memory addresses
that don't even have a relocation.

Can you please reconsider disabling the sysv hash (note: as mentioned
on IRC, this also eliminates the only place to get the size of the
symbol table without iterating over the whole gnu hash table, which
dladdr needs to do and which applications processing ELF structures
might reasonably want to do)? If you have other ideas for debugging
I'm open to trying them but I don't want to spend a lot of time trying
to track down an alleged bug in the dynamic linker when we're missing
a good way to confirm that this is even the cause of the bug.

Rich