-
Notifications
You must be signed in to change notification settings - Fork 16.1k
[lldb] [Process/FreeBSDKernel] Select paniced thread automatically #178069
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
|
@llvm/pr-subscribers-lldb Author: Minsoo Choo (mchoo7) ChangesExample: Full diff: https://github.com/llvm/llvm-project/pull/178069.diff 2 Files Affected:
diff --git a/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.cpp b/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.cpp
index d209e5b5384f3..ced8fa6f28c84 100644
--- a/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.cpp
+++ b/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.cpp
@@ -118,7 +118,12 @@ bool ProcessFreeBSDKernel::CanDebug(lldb::TargetSP target_sp,
return true;
}
-void ProcessFreeBSDKernel::RefreshStateAfterStop() {}
+void ProcessFreeBSDKernel::RefreshStateAfterStop() {
+ if (m_crashed_thread_id != LLDB_INVALID_THREAD_ID) {
+ GetThreadList().SetSelectedThreadByID(m_crashed_thread_id);
+ m_crashed_thread_id = LLDB_INVALID_THREAD_ID;
+ }
+}
bool ProcessFreeBSDKernel::DoUpdateThreadList(ThreadList &old_thread_list,
ThreadList &new_thread_list) {
@@ -232,6 +237,7 @@ bool ProcessFreeBSDKernel::DoUpdateThreadList(ThreadList &old_thread_list,
// NB: dumppcb can be LLDB_INVALID_ADDRESS if reading it failed
pcb_addr = dumppcb;
thread_desc += " (crashed)";
+ m_crashed_thread_id = tid;
} else if (oncpu != -1) {
// if we managed to read stoppcbs and pcb_size, use them to find
// the correct PCB
diff --git a/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.h b/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.h
index 06c9d062441e5..c36e31839db19 100644
--- a/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.h
+++ b/lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.h
@@ -49,6 +49,8 @@ class ProcessFreeBSDKernel : public lldb_private::PostMortemProcess {
lldb_private::ThreadList &new_thread_list) override;
lldb::addr_t FindSymbol(const char* name);
+private:
+ lldb::tid_t m_crashed_thread_id = LLDB_INVALID_THREAD_ID;
};
#endif // LLDB_SOURCE_PLUGINS_PROCESS_FREEBSDKERNEL_PROCESSFREEBSDKERNEL_H
|
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
|
Looks fine to me. I checked other plugins and they do not do this, but I see why it's useful. I wonder if the other formats should do this, or don't need to for some reason, but no need to look into that yourself. Is there a test case in tree for this kernel plugin? If there is, please update that, if not, you don't need to add one. Even if this somehow has problems, the impact is limited. Source changes look fine to me, let's give some time to the FreeBSD specialists to respond. |
|
Please update the PR description to show before and after. You can edit the lldb output to remove unimportant bits, that's fine. I assume lldb previously selected thread 0, or whatever was the running thread at the time of the dump? |
We have test cases for FreeBSDKernel but I've never used it. It'll take some time for me to understand how it works. A FreeBSD developer will review this on Saturday, so we have time. |
It's selecting thread 1 by default. Just realized that I need to test this on other threads as well since kernel panic occurs on thread 1. |
|
My first approach was nonsense. Updating to correct approach with correct before/after. |
70b0e8d to
329a0ef
Compare
🐧 Linux x64 Test Results
✅ The build succeeded and all tests passed. |
Probably obvious already, but ignore this failure. Your changes are unrelated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating the PR description, very clear now what this changes. Code is fine just an optional style comment on that.
Please look into the test cases that exist for this. I know some of them require a FreeBSD core parsing library to be installed, so watch out for that. If you have trouble getting them to work, I can look at least the corefile based ones (getting a FreeBSD system is extra steps for me).
It's likely they're not being run in many (if any) places.
At a glance, the core based tests check that expected threads exist but not which one is selected.
lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.cpp
Outdated
Show resolved
Hide resolved
e7b99b6 to
53c9844
Compare
lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.h
Outdated
Show resolved
Hide resolved
This will pass the test case since the test core dump was created by |
|
For testing, see #178714 |
Yeah I didn't realise there were all those scripts to minify the dump.
That sounds good to me. I suppose the existing tests might break in the meantime, but I think the only folks running them would be over in FreeBSD itself. So I trust you to deal with that if it happens. |
DavidSpickett
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with the braces fixed.
In theory we could wait for @emaste to comment but this seems like a clear usability improvement to me so I'm approving it myself. We've discussed the existing tests and worst case, if someone's CI fails, these patches will be easy to revert.
(plus we are just past the llvm release branching, so there's no danger of being included in a release right now)
lldb/source/Plugins/Process/FreeBSDKernel/ProcessFreeBSDKernel.cpp
Outdated
Show resolved
Hide resolved
Signed-off-by: Minsoo Choo <[email protected]>
aokblast
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
|
@mchoo7 Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR. Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues. How to do this, and the rest of the post-merge process, is covered in detail here. If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! |
|
I just merge it right now. @emaste Please revert it if you have any issue on it. |
Kernel panic is a special case, and there is no signal or exception for that so we need to rely on special workaround called
dumptid. FreeBSDKernel plugin is supposed to find this thread and set it manually throughSetStopInfo()inCalculateStopInfo()like Mach core plugin does.Before (We had to find and select crashed thread list otherwise thread 1 was selected by default):
After: