Add work around a bug in lldb on a core dump #1327
Conversation
…p where the system ids (TIDs) are wrong.
First find the managed thread os id is:
(lldb) sos Threads
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
1 1 3787 00000000006547F8 20220 Preemptive 00007FFFCC0145D0:00007FFFCC015FD0 00000000006357F8 0 Ukn
6 2 3790 0000000000678FB8 21220 Preemptive 0000000000000000:0000000000000000 00000000006357F8 0 Ukn (Finalizer)
(lldb) thread list
Process 0 stopped
* thread #1: tid = 0x0000, 0x00007f01fe64d267 libc.so.6`__GI_raise(sig=6) + 55 at raise.c:55, name = 'corerun', stop reason = signal SIGABRT
thread #2: tid = 0x0001, 0x00007f01fe7138dd libc.so.6, 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, stop reason = signal SIGABRT
thread dotnet#6: tid = 0x0005, 0x00007f01fe70f49d libc.so.6, stop reason = signal SIGABRT
Then use the new command "setsostid" to set the current thread using the "OSID" from above:
(lldb) setsostid 3790 6
Set sos thread os id to 0x3790 which maps to lldb thread index 6
Now ClrStack should dump that managed thread:
(lldb) sos ClrStack
To undo the affect of this command:
(lldb) setsostid
Added setclrpath command that allows the path that sos/dac/dbi are loaded from to be changes instead of using
the coreclr path. This may be needed if loading a core dump and the debugger binaries are in a different directory
that what the dump has for coreclr's path.
|
@adityamandaleeka and @sergiy-k could you review? |
| @@ -14019,4 +14019,4 @@ Help(PDEBUG_CLIENT Client, PCSTR Args) | |||
| return S_OK; | |||
| } | |||
|
|
|||
| #endif // !FEATURE_PAL | |||
| #endif // FEATURE_PAL | |||
There was a problem hiding this comment.
Not necessarily something to address in this PR, but it looks like there's some hairy #ifdef nesting going on in this file. It took me a while to find the matching #ifndef FEATURE_PAL (I think it's the one at line 12660).
The other issue with it is that there is some inconsistency with what the comments next to the endif's say when they're closing an #ifndef. If there's #ifndef FOO, sometimes the endif is #endif // FOO and elsewhere it's #endif // !FOO. This makes those comments almost useless since you end up having to scroll up to figure out what's going on anyway.
Again, this doesn't need to be fixed in this PR, but I think it would be good to standardize that and also detangle some of the nesting in this file.
There was a problem hiding this comment.
Yes, it is a big mess. I’ll try to clean this up in the future.
From: Aditya Mandaleeka [mailto:notifications@github.com]
Sent: Monday, August 3, 2015 12:15 PM
To: dotnet/coreclr coreclr@noreply.github.com
Cc: Mike McLaughlin mikem@microsoft.com
Subject: Re: [coreclr] Add work around a bug in lldb on a core dump (#1327)
In src/ToolBox/SOS/Strike/strike.cpphttps://github.com//pull/1327#discussion_r36120010:
@@ -14019,4 +14019,4 @@ Help(PDEBUG_CLIENT Client, PCSTR Args)
return S_OK;}
-#endif // !FEATURE_PAL
+#endif // FEATURE_PAL
Not necessarily something to address in this PR, but it looks like there's some hairy #ifdef nesting going on in this file. It took me a while to find the matching #ifndef FEATURE_PAL (I think it's the one at line 12660).
The other issue with it is that there is some inconsistency with what the comments next to the endif's say when they're closing an #ifndef. If there's #ifndef FOO, sometimes the endif is #endif // FOO and elsewhere it's #endif // !FOO. This makes those comments almost useless since you end up having to scroll up to figure out what's going on anyway.
Again, this doesn't need to be fixed in this PR, but I think it would be good to standardize that and also detangle some of the nesting in this file.
—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1327/files#r36120010.
|
@dotnet-bot test this please |
1 similar comment
|
@dotnet-bot test this please |
Add work around a bug in lldb on a core dump
The lldb bug is that the system ids (TIDs) are wrong. They are the same as the thread indexes.
First find the managed thread os id is:
(lldb) sos Threads
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
1 1 3787 00000000006547F8 20220 Preemptive 00007FFFCC0145D0:00007FFFCC015FD0 00000000006357F8 0 Ukn
6 2 3790 0000000000678FB8 21220 Preemptive 0000000000000000:0000000000000000 00000000006357F8 0 Ukn (Finalizer)
(lldb) thread list
Process 0 stopped
__GI_raise(sig=6) + 55 at raise.c:55, name = 'corerun', stop reason = signal SIGABRT thread #2: tid = 0x0001, 0x00007f01fe7138dd libc.so.6, stop reason = signal SIGABRT thread #3: tid = 0x0002, 0x00007f01fd27dda0 libpthread.so.0__pthread_cond_wait + 192, stop reason = signal SIGABRTthread Changes to Miscellaneous test project and runtest #4: tid = 0x0003, 0x00007f01fd27e149 libpthread.so.0`__pthread_cond_timedwait + 297, stop reason = signal SIGABRT
thread Fix build breaks in GC sample project #5: tid = 0x0004, 0x00007f01fe70f28d libc.so.6, stop reason = signal SIGABRT
thread Add build status badge #6: tid = 0x0005, 0x00007f01fe70f49d libc.so.6, stop reason = signal SIGABRT
Then use the new command "setsostid" to set the current thread using the "OSID" from above:
(lldb) setsostid 3790 6
Set sos thread os id to 0x3790 which maps to lldb thread index 6
Now ClrStack should dump that managed thread:
(lldb) sos ClrStack
To undo the effect of this command:
(lldb) setsostid
Also added "setclrpath" command that allows the path that sos/dac/dbi are loaded from to be changes instead of using the coreclr path. This may be needed if loading a core dump and the debugger binaries are in a different directory that what the dump has for coreclr's path.