[lldb-dev] Question (bug?) about thread tids when lldb loads a core dump.

Adrian McCarthy amccarth at google.com
Thu Jul 30 07:44:04 PDT 2015


I noticed that while studying the code in order to determine how to do the
same thing for Windows mini dumps.  Note that the loop index is treated as
the thread ID in ProcessElfCore::UpdateThreadList:

    for (lldb::tid_t tid = 0; tid < num_threads; ++tid)
    {
        const ThreadData &td = m_thread_data[tid];
        lldb::ThreadSP thread_sp(new ThreadElfCore (*this, tid, td));
        new_thread_list.AddThread (thread_sp);
    }

I wondered if this was intentional, to avoid confusion between the dead
threads and any live threads that might happen to be using a recycled
thread ID.

On Wed, Jul 29, 2015 at 6:41 PM, Mike McLaughlin <mikem at microsoft.com>
wrote:

>  When I load a core dump with lldb 3.6, the tids displayed in “thread
> list” and more importantly returned by lldb::SBThread::GetThreadID() (used
> in a lldb plugin I wrote) doesn’t match the tids from the live session the
> core was generated from.  gdb displays the correct tids on the same core
> dump (see below).  My plugin depends on the above api returning the tid
> during the live session.
>
>
>
> Can anybody help?
>
>
>
> lldb-3.6
>
> (lldb) target create --core /tmp/core-corerun-6-1000-1000-20870-1438119958
> /tmp/corerun
>
> Core file '/tmp/core-corerun-6-1000-1000-20870-1438119958' (x86_64) was
> loaded.
>
> Process 0 stopped
>
> * thread #1: tid = 0x0000, 0x00007f01fe64d267 libc.so.6`gsignal + 55, name
> = 'corerun', stop reason = signal SIGABRT
>
>     frame #0: 0x00007f01fe64d267 libc.so.6`gsignal + 55
>
> -> 0x7f01fe64d267: addb   %al, (%rax)
>
>    0x7f01fe64d269: addb   %al, (%rax)
>
>    0x7f01fe64d26b: addb   %al, (%rax)
>
>    0x7f01fe64d26d: addb   %al, (%rax)
>
>   thread #2: tid = 0x0001, 0x00007f01fe7138dd libc.so.6`__poll + 45, stop
> reason = signal SIGABRT
>
>     frame #0: 0x00007f01fe7138dd libc.so.6`__poll + 45
>
> -> 0x7f01fe7138dd: addb   %al, (%rax)
>
>    0x7f01fe7138df: addb   %al, (%rax)
>
>    0x7f01fe7138e1: addb   %al, (%rax)
>
>    0x7f01fe7138e3: addb   %al, (%rax)
>
>   thread #3: tid = 0x0002, 0x00007f01fd27dda0
> libpthread.so.0`__pthread_cond_wait + 192, stop reason = signal SIGABRT
>
>     frame #0: 0x00007f01fd27dda0 libpthread.so.0`__pthread_cond_wait + 192
>
> -> 0x7f01fd27dda0: addb   %al, (%rax)
>
>    0x7f01fd27dda2: addb   %al, (%rax)
>
>    0x7f01fd27dda4: addb   %al, (%rax)
>
>    0x7f01fd27dda6: addb   %al, (%rax)
>
>   thread #4: tid = 0x0003, 0x00007f01fd27e149
> libpthread.so.0`__pthread_cond_timedwait + 297, stop reason = signal SIGABRT
>
>     frame #0: 0x00007f01fd27e149 libpthread.so.0`__pthread_cond_timedwait
> + 297
>
> -> 0x7f01fd27e149: addb   %al, (%rax)
>
>    0x7f01fd27e14b: addb   %al, (%rax)
>
>    0x7f01fd27e14d: addb   %al, (%rax)
>
>    0x7f01fd27e14f: addb   %al, (%rax)
>
>   thread #5: tid = 0x0004, 0x00007f01fe70f28d libc.so.6`__open64 + 45,
> stop reason = signal SIGABRT
>
>     frame #0: 0x00007f01fe70f28d libc.so.6`__open64 + 45
>
> -> 0x7f01fe70f28d: addb   %al, (%rax)
>
>    0x7f01fe70f28f: addb   %al, (%rax)
>
>    0x7f01fe70f291: addb   %al, (%rax)
>
>    0x7f01fe70f293: addb   %al, (%rax)
>
>   thread #6: tid = 0x0005, 0x00007f01fe70f49d libc.so.6`__read + 45, stop
> reason = signal SIGABRT
>
>     frame #0: 0x00007f01fe70f49d libc.so.6`__read + 45
>
> -> 0x7f01fe70f49d: addb   %al, (%rax)
>
>    0x7f01fe70f49f: addb   %al, (%rax)
>
>    0x7f01fe70f4a1: addb   %al, (%rax)
>
>    0x7f01fe70f4a3: addb   %al, (%rax)
>
> (lldb) thread list
>
> Process 0 stopped
>
> * thread #1: tid = 0x0000, 0x00007f01fe64d267 libc.so.6`gsignal + 55,
> name = 'corerun', stop reason = signal SIGABRT
>
>   thread #2: tid = 0x0001, 0x00007f01fe7138dd libc.so.6`__poll + 45, stop
> reason = signal SIGABRT
>
>   thread #3: tid = 0x0002, 0x00007f01fd27dda0
> libpthread.so.0`__pthread_cond_wait + 192, stop reason = signal SIGABRT
>
>   thread #4: tid = 0x0003, 0x00007f01fd27e149
> libpthread.so.0`__pthread_cond_timedwait + 297, stop reason = signal SIGABRT
>
>   thread #5: tid = 0x0004, 0x00007f01fe70f28d libc.so.6`__open64 + 45,
> stop reason = signal SIGABRT
>
>   thread #6: tid = 0x0005, 0x00007f01fe70f49d libc.so.6`__read + 45, stop
> reason = signal SIGABRT
>
> ------------------------------------------
>
>
>
> gdb /tmp/corerun /tmp/core-corerun-6-1000-1000-20870-1438119958
>
> GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9
>
> Copyright (C) 2015 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-linux-gnu".
>
> 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 /tmp/corerun...done.
>
>
>
> warning: exec file is newer than core file.
>
> [New LWP 20870]
>
> [New LWP 20871]
>
> [New LWP 20874]
>
> [New LWP 20875]
>
> [New LWP 20873]
>
> [New LWP 20872]
>
>
>
> warning: .dynamic section for
> "/ssd/coreclr/bin/Product/Linux.x64.Debug/libcoreclr.so" is not at the
> expected address (wrong library or version mismatch?)
>
> [Thread debugging using libthread_db enabled]
>
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Core was generated by `./corerun HelloWorld.exe linux'.
>
> Program terminated with signal SIGABRT, Aborted.
>
> #0  0x00007f01fe64d267 in __GI_raise (sig=sig at entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:55
>
> 55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
> (gdb) info threads
>
>   Id   Target Id         Frame
>
>   6    Thread 0x7f01fc42a700 (LWP 20872) 0x00007f01fe70f49d in read () at
> ../sysdeps/unix/syscall-template.S:81
>
>   5    Thread 0x7f01fbc29700 (LWP 20873) 0x00007f01fe70f28d in open64 ()
> at ../sysdeps/unix/syscall-template.S:81
>
>   4    Thread 0x7f01faafb700 (LWP 20875) pthread_cond_timedwait@@GLIBC_2.3.2
> () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>
>   3    Thread 0x7f01fb428700 (LWP 20874) pthread_cond_wait@@GLIBC_2.3.2
> () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>
>   2    Thread 0x7f01fcc2b700 (LWP 20871) 0x00007f01fe7138dd in poll () at
> ../sysdeps/unix/syscall-template.S:81
>
> * 1    Thread 0x7f01ff61a740 (LWP 20870) 0x00007f01fe64d267 in __GI_raise
> (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
>
> (gdb)
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150730/36332bb7/attachment.html>


More information about the lldb-dev mailing list