Re: lldb unusable for regular user

On Monday, September 18, 2017 02:41:06 PM Vladimir Zakharov wrote:
> Hello!
> 
> lldb coredumps for regular user, but works for root.
> 
> > uname -a
> FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r323675: Sun Sep 17 21:14:33 MSK 2017     root_at_vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > cat test.c
> #include <stdio.h>
> #include <unistd.h>
> 
> int main()
> {
>   printf("PID: %d\n", getpid());
>   sleep(10);
>   return 0;
> }
> > cc -O0 -g test.c -o test
> > lldb ./test
> (lldb) target create "./test"
> Current executable set to './test' (x86_64).
> (lldb) run
> Process 37758 launching
> Process 37758 launched: './test' (x86_64)
> Segmentation fault (core dumped)
> Exit 139
> > sudo lldb ./test
> (lldb) target create "./test"
> Current executable set to './test' (x86_64).
> (lldb) run
> Process 37776 launching
> Process 37776 launched: './test' (x86_64)
> PID: 37776
> Process 37776 exited with status = 0 (0x00000000)
> (lldb)
> 
> 
> Postmortem by gdb:
> > gdb ./test test.core
> ...
> [New LWP 101456]
> Core was generated by `./test'.
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> #0  _start (ap=0x7fffffffe858, cleanup=0x800605910 <rtld_exit>) at /usr/src/lib/csu/amd64/crt1.c:50
> 50      {
> (gdb) bt
> #0  _start (ap=0x7fffffffe858, cleanup=0x800605910 <rtld_exit>) at /usr/src/lib/csu/amd64/crt1.c:50
> (gdb) f
> #0  _start (ap=0x7fffffffe858, cleanup=0x800605910 <rtld_exit>) at /usr/src/lib/csu/amd64/crt1.c:50
> 50      {
> 
> > gdb `which lldb` lldb.core
> ...
> Reading symbols from /usr/bin/lldb...Reading symbols from /usr/lib/debug//usr/bin/lldb.debug...done.
> done.
> [New LWP 101610]
> [New LWP 100968]
> [New LWP 100126]
> [New LWP 101631]
> [New LWP 101637]
> [New LWP 101662]
> [New LWP 101672]
> [New LWP 100337]
> [New LWP 101593]
> Core was generated by `lldb ./test'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20, context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
> 60      ./md-unwind-support.h: No such file or directory.
> [Current thread is 1 (LWP 101610)]
> (gdb) f
> #0  x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20, context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
> 60      in ./md-unwind-support.h
> (gdb) bt
> #0  x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20, context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
> #1  uw_frame_state_for (context=context_at_entry=0x7fffddff6e20, fs=fs_at_entry=0x7fffddff6b70) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
> #2  0x0000000804f6cffb in _Unwind_ForcedUnwind_Phase2 (exc=exc_at_entry=0x806b23230, context=context_at_entry=0x7fffddff6e20) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
> #3  0x0000000804f6d334 in _Unwind_ForcedUnwind (exc=0x806b23230, stop=0x804631760 <thread_unwind_stop>, stop_argument=<optimized out>) at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
> #4  0x00000008046315c3 in _Unwind_ForcedUnwind (ex=<optimized out>, stop_func=0xe, stop_arg=0x806b23000) at /usr/src/lib/libthr/thread/thr_exit.c:106
> #5  thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172
> #6  _pthread_exit_mask (status=<optimized out>, mask=<optimized out>) at /usr/src/lib/libthr/thread/thr_exit.c:254
> #7  0x00000008046313eb in _pthread_exit (status=0x806b23000) at /usr/src/lib/libthr/thread/thr_exit.c:206
> #8  0x0000000804623c0d in thread_start (curthread=0x806b23000) at /usr/src/lib/libthr/thread/thr_create.c:289
> #9  0x00007fffdddf7000 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffddff7000

Your backtrace shows it crashed during thread exit inside of libthr, not in
lldb itself.  Also, it seems you are using libgcc_s from external gcc rather
than the base system libgcc_s which is built from
contrib/llvm/projects/libunwind.  If lldb dlopen'd some object that depends
on libgcc_s.so from ports gcc then that might explain this crash as it means
you are mixing two different unwind libraries.  What does 'info sharedlibrary'
from gdb show?

-- 
John Baldwin