[cfe-dev] Clang generates segfaulting executables on Gentoo/FreeBSD (FreeBSD with Portage and more)

Johnson Steward via cfe-dev cfe-dev at lists.llvm.org
Mon Aug 28 18:02:41 PDT 2017 

I've recompiled freebsd-libexec (to which ld-elf.so.1 belongs) with
-ggdb and nostrip feature of portage. The backtrace is as follows:
(sorry I can't get lldb working here as the _oldest_ version in the
portage tree is 4.0.1 which requires a newer llvm/clang)

root at G-FBSD-Clang ncurses # gdb ./make_hash make_hash.core
GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-gentoo-freebsd10.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./make_hash...done.
[New LWP 100081]

warning: Unexpected size of section `.reg-xstate/100081' in core file.
Core was generated by `make_hash'.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Unexpected size of section `.reg-xstate/100081' in core file.
#0  0x0000000800611c66 in memcpy () from /libexec/ld-elf.so.1
(gdb) bt
#0  0x0000000800611c66 in memcpy () from /libexec/ld-elf.so.1
#1  0x0000000800603395 in do_copy_relocations (dstobj=<optimized out>)
    at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.3/work/libexec/rtld-elf/amd64/reloc.c:104
#2  0x0000000800604ad4 in _rtld (sp=0x7fffffffeb68,
    exit_proc=<optimized out>, objp=<optimized out>)
    at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.3/work/libexec/rtld-elf/rtld.c:609
#3  0x0000000800603259 in .rtld_start ()
    at /var/tmp/portage/sys-freebsd/freebsd-libexec-10.3/work/libexec/rtld-elf/amd64/rtld_start.S:39
#4  0x0000000000000000 in ?? ()
(gdb)

The make_hash executable was re-compiled with -ggdb appended to the
compile commandline, and re-executed to have the core dump
re-generated.

2017-08-29 2:14 GMT+08:00 Dimitry Andric <dimitry at andric.com>:
> Can you generate a backtrace on the system itself, with full debug info?  It seems to be some issue in the dynamic linker, ld-elf.so.1, but lldb and gdb have different opinions on the backtrace:
>
> $ lldb -f make_hash -c make_hash.core
> (lldb) target create "make_hash" --core "make_hash.core"
> Core file '/home/dim/tmp/make_hash.core' (x86_64) was loaded.
> (lldb) bt
> * thread #1, name = 'make_hash', stop reason = signal SIGSEGV
>   * frame #0: 0x0000000800611e36 ld-elf.so.1`lm_add(p="", f="", t="") at libmap.c:344
>     frame #1: 0x0000000800604bc4 ld-elf.so.1`_rtld(sp=0x0000000000000000, exit_proc=0x0000000000000000, objp=0x0000000000000000) at rtld.c:570
>
> $ gdb ./make_hash make_hash.core
> GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./make_hash...(no debugging symbols found)...done.
> [New LWP 100141]
>
> warning: Unexpected size of section `.reg-xstate/100141' in core file.
>
> warning: .dynamic section for "/lib/libc.so.7" is not at the expected address (wrong library or version mismatch?)
>
> warning: .dynamic section for "/libexec/ld-elf.so.1" is not at the expected address (wrong library or version mismatch?)
> Core was generated by `make_hash'.
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> warning: Unexpected size of section `.reg-xstate/100141' in core file.
> #0  0x0000000800611e36 in setup (list1=0x4007f0 "\330\035`",
>     list2=0x8d3c9ed3 <error: Cannot access memory at address 0x8d3c9ed3>, n=<optimized out>, size=34366166016,
>     cmp=<optimized out>) at /usr/src/lib/libc/stdlib/merge.c:320
> 320                                                     reverse(f1, f2-size);
> (gdb) bt
> #0  0x0000000800611e36 in setup (list1=0x4007f0 "\330\035`",
>     list2=0x8d3c9ed3 <error: Cannot access memory at address 0x8d3c9ed3>, n=<optimized out>, size=34366166016,
>     cmp=<optimized out>) at /usr/src/lib/libc/stdlib/merge.c:320
> #1  mergesort (base=0x4007f0, nmemb=<optimized out>, size=<optimized out>, cmp=0x7fffffffa940)
>     at /usr/src/lib/libc/stdlib/merge.c:144
> #2  0x0000000800604bc4 in free_tls (tls=<optimized out>, tcbalign=8, tcbsize=<optimized out>)
>     at /usr/src/libexec/rtld-elf/rtld.c:4833
> #3  allocate_tls (objs=0x0, oldtls=0x80081e628 <iswcntrl_l+16>, tcbsize=<optimized out>, tcbalign=<optimized out>)
>     at /usr/src/libexec/rtld-elf/rtld.c:4803
> #4  0x00000008006032a9 in symlook_list (objlist=<optimized out>, req=<optimized out>, dlp=<optimized out>)
>     at /usr/src/libexec/rtld-elf/rtld.c:4120
> #5  do_dlsym (handle=<optimized out>, name=<optimized out>, retaddr=<optimized out>, ve=<optimized out>, flags=2)
>     at /usr/src/libexec/rtld-elf/rtld.c:3466
> Backtrace stopped: Cannot access memory at address 0x8
>
> -Dimitry
>
>> On 28 Aug 2017, at 16:43, Johnson Steward via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>
>> Hello everyone,
>>
>> Greetings! I'm recently working on the Gentoo/FreeBSD project, trying to
>> upgrade the outdated (and in lack of maintainers) G-FBSD stages to the current
>> version. Bootstrapping GCC turned out to be a complete nightmare on such a
>> platform, so I chose clang. Everything seems to be going pretty well and I've
>> updated libcxx, llvm and clang to 3.9.1. Yet sometimes clang generates faulty
>> C executables which segfaults such as pkg-config and thre intermediate
>> "make_hash" utility generated while compiling ncurses.
>>
>> I'm pretty new to dealing with toolchains, and if I made any stupid mistakes
>> don't hesitate to point them out. The following links hold the base64'ed
>> executable "make_hash" from ncurses and its core dump. The compile commandline
>> is as follows.
>>
>> compile commandline:
>>
>> clang -o make_hash -DHAVE_CONFIG_H -DUSE_BUILD_CC -I../ncurses -I/var/
>> tmp/portage/sys-libs/ncurses-6.0-r1/work/ncurses-6.0/ncurses -I../include -I/
>> var/tmp/portage/sys-libs/ncurses-6.0-r1/work/ncurses-6.0/ncurses/../include
>> -D_GNU_SOURCE -O1 -pipe /var/tmp/portage/sys-libs/ncurses-6.0-r1/work/
>> ncurses-6.0/ncurses/tinfo/make_hash.c
>>
>> make_hash: (get it with curl ${URL} | base64 -d | bzip2 -d > make_hash)
>>
>> URL=https://paste.pound-python.org/raw/laRZK3NxtxAtL7aUXSbY/
>>
>> make_hash.core: (same as above)
>>
>> URL=https://paste.pound-python.org/raw/RHvAMBnj0yJMm4fxPxBW/
>>
>> make_hash.c: (plain text)
>>
>> URL=https://paste.pound-python.org/raw/Fxot8FaEgVDfwMBRw34c/
>>
>> If more information is needed don't hesitate to ask for them in the following-
>> up mails. Any form of opinions are welcomed.
>>
>> Thanks in advance!
>>
>> Yours,
>> KireinaHoro
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

More information about the cfe-dev mailing list