From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8144 Path: news.gmane.org!not-for-mail From: Natanael Copa Newsgroups: gmane.linux.lib.musl.general Subject: dynamic linker issue Date: Thu, 9 Jul 2015 17:11:59 +0200 Message-ID: <20150709171159.4f08479e@ncopa-desktop.alpinelinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/JiKNDGjwYxh8dQQjv.eOPBz" X-Trace: ger.gmane.org 1436454745 17383 80.91.229.3 (9 Jul 2015 15:12:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jul 2015 15:12:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8157-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 09 17:12:24 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZDDUs-0003Tu-Pa for gllmg-musl@m.gmane.org; Thu, 09 Jul 2015 17:12:23 +0200 Original-Received: (qmail 23645 invoked by uid 550); 9 Jul 2015 15:12:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23595 invoked from network); 9 Jul 2015 15:12:15 -0000 X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-alpine-linux-musl) X-Virus-Scanned: ClamAV using ClamSMTP Xref: news.gmane.org gmane.linux.lib.musl.general:8144 Archived-At: --MP_/JiKNDGjwYxh8dQQjv.eOPBz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: (gdb) print blackhole_ops $1 = {to_kind = 0x614d43a1026e "blackhole", to_type = 1136841632, to_size = 0, to_dump = {0x0, 0x0, 0x0}, to_msg_fill = 0x0, to_msg_fill_raw = 0x0, to_msg_parser = 0x0, to_free_data = 0x0, to_clone = 0x0, to_list = { 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 believe it is related the fact that libxenlight pulls in libnl-route-3.so.200 and libvirt.so.0 pulls in libnl.so.1. those different versions of libnl libraries provides various symbols with same name. I was able to create a smaller testcase, which is attached. Note that bot libnl-route-3.so.200 and libnl.so.1 provides 'rtnl_addr_alloc'. Problem happens on alpine edge with those versions: musl-1.1.10-r2 libnl3-3.2.26-r2 libnl-1.1.4-r0 gcc-5.1.0-r0 I was not able to preproduce it with alpine v3.2 (stable) with those versions: libnl3-3.2.25-r0 musl-1.1.9-r3 libnl-1.1.4-r0 gcc-4.9.2-r5 On edge I tried to build the libs with clang and the problem appeared. We have changed to using gnu hash by default recently: http://git.alpinelinux.org/cgit/aports/commit/main/binutils?id=ecd6d7d10fc37382bbdd89138199f88429797c7f More, I tried build various musl versions from git (at least back to v1.1.7) and problem happens. (I am only 95% sure i ran the test properly) So I suspect there is a bug in musl dynamic linker with gnu hash that has been there for a long time. It should be easy to reproduce with the 3 attached testfiles on alpine edge. I only tested x86_64. Ideas? Thanks! -nc --MP_/JiKNDGjwYxh8dQQjv.eOPBz Content-Type: application/octet-stream; name=Makefile Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Makefile IyBNYWtlZmlsZQpDRkxBR1MgPSAtZlBJQwpMSUJOTDNfQ0ZMQUdTIDo9ICQoc2hlbGwgcGtnLWNv bmZpZyAtLWNmbGFncyBsaWJubC1yb3V0ZS0zLjApCkxJQk5MM19MSUJTIDo9ICQoc2hlbGwgcGtn LWNvbmZpZyAtLWxpYnMgbGlibmwtcm91dGUtMy4wKQoKTElCTkxfQ0ZMQUdTIDo9ICQoc2hlbGwg cGtnLWNvbmZpZyAtLWNmbGFncyBsaWJubC0xKQpMSUJOTF9MSUJTIDo9ICQoc2hlbGwgcGtnLWNv bmZpZyAtLWxpYnMgbGlibmwtMSkKCnJ1bjogZm9vCglMRF9MSUJSQVJZX1BBVEg9JChQV0QpICQo SE9NRSkvc3JjL211c2wvbGliL2xpYmMuc28gLS0gLi9mb28KCmZvbzogZm9vLmMgbGliZm9vMy5z bwoJJChDQykgJChDRkxBR1MpICQoTElCTkxfQ0ZMQUdTKSAtTC4gLW8gJEAgJDwgJChMSUJOTF9M SUJTKSAtbGZvbzMKCmxpYmZvbzMuc286IGxpYmZvbzMuYyBsaWJmb28zLmgKCSQoQ0MpICQoQ0ZM QUdTKSAkKExJQk5MM19DRkxBR1MpIC1vICRAIC1zaGFyZWQgJDwgJChMSUJOTDNfTElCUykKCmxp YmZvbzMuaDoKCWVjaG8gImludCBmb29fYWxsb2MoKTsiID4kQAoKY2xlYW46CglybSAtZiBsaWJm b28zLnNvIGZvbyBsaWJmb28zLmgKCg== --MP_/JiKNDGjwYxh8dQQjv.eOPBz Content-Type: text/x-c++src Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=foo.c /* foo.c */ #include #include #include "libfoo3.h" int main(void) { struct rtnl_addr *a = rtnl_addr_alloc(); printf("foo_alloc: %i\n", foo_alloc()); return 0; } --MP_/JiKNDGjwYxh8dQQjv.eOPBz Content-Type: text/x-c++src Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=libfoo3.c /* libfoo3.c */ #include int foo_alloc() { struct rtnl_addr *addr = NULL; addr = rtnl_addr_alloc(); return addr != NULL; } --MP_/JiKNDGjwYxh8dQQjv.eOPBz--