LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 26322 - Core load hangs
Summary: Core load hangs
Status: RESOLVED FIXED
Alias: None
Product: lldb
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: 3.8
Hardware: PC Linux
: P normal
Assignee: Howard Hellyer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-26 14:25 PST by Eugene Birukov
Modified: 2017-07-19 02:46 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Birukov 2016-01-26 14:25:59 PST
There are two problems with core load on Linux:

1. The thread ID are lost and there is FIXME in the code
2. If core dump is obtained from live process (i.e. gdb attach, gcore, detach) then there is no thread that has any reason to stop. LLDB hangs forever on such a core.

Here is the proposed fix for both:

diff --git a/include/lldb/Target/Process.h b/include/lldb/Target/Process.h
index 6bb7a3d..915ca15 100644
--- a/include/lldb/Target/Process.h
+++ b/include/lldb/Target/Process.h
@@ -3401,6 +3401,7 @@ protected:
     std::map<lldb::addr_t,lldb::addr_t> m_resolved_indirect_addresses;
     bool m_destroy_in_process;
     bool m_can_interpret_function_calls; // Some targets, e.g the OSX kernel, don't support the ability to modify the stack.
+    bool m_load_core; // True if we are looking at a core dump, not at a running program
     WarningsCollection          m_warnings_issued;  // A set of object pointers which have already had warnings printed
 
     enum {
diff --git a/source/Plugins/Process/elf-core/ProcessElfCore.cpp b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index 5b5d98a..fa057f1 100644
--- a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -559,11 +559,10 @@ ProcessElfCore::ParseThreadContextsFromNoteSegment(const elf::ELFProgramHeader *
                     have_prstatus = true;
                     prstatus.Parse(note_data, arch);
                     thread_data->signo = prstatus.pr_cursig;
+                    thread_data->tid = prstatus.pr_pid;
                     header_size = ELFLinuxPrStatus::GetSize(arch);
                     len = note_data.GetByteSize() - header_size;
                     thread_data->gpregset = DataExtractor(note_data, header_size, len);
-                    // FIXME: Obtain actual tid on Linux
-                    thread_data->tid = m_thread_data.size();
                     break;
                 case NT_FPREGSET:
                     thread_data->fpregset = note_data;
diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
index e4fe419..489b307 100644
--- a/source/Target/Process.cpp
+++ b/source/Target/Process.cpp
@@ -767,6 +767,7 @@ Process::Process(lldb::TargetSP target_sp, Listener &listener, const UnixSignals
     m_last_broadcast_state (eStateInvalid),
     m_destroy_in_process (false),
     m_can_interpret_function_calls(false),
+    m_load_core(false),
     m_warnings_issued (),
     m_can_jit(eCanJITDontKnow)
{
@@ -3088,6 +3089,7 @@ Process::LoadCore ()
         // We successfully loaded a core file, now pretend we stopped so we can
         // show all of the threads in the core file and explore the crashed
         // state.
+        m_load_core = true;
         SetPrivateState (eStateStopped);
 
         // Wait indefinitely for a stopped event since we just posted one above...
@@ -3975,6 +3977,11 @@ Process::ShouldBroadcastEvent (Event *event_ptr)
 
                 if (!was_restarted)
                     should_resume = m_thread_list.ShouldStop (event_ptr) == false;
+
+                 // ShouldStop() above has some side effects besides calculating return value,
+                 // so we better not skip it. But if we are loading core we should not resume.
+                 if (m_load_core)
+                     should_resume = false;
 
                 if (was_restarted || should_resume || m_resume_requested)
                 {
Comment 1 Howard Hellyer 2016-11-15 04:35:27 PST
This looks like a problem reading the signals for each thread from the core file.
See the discussion under:
http://lists.llvm.org/pipermail/lldb-dev/2016-November/011578.html

I'll try to submit a patch shortly.
Comment 2 Howard Hellyer 2016-11-24 04:53:17 PST
Fix landed under:
https://reviews.llvm.org/D26676
Comment 3 labath 2016-11-25 05:05:07 PST
Marking the bug as closed.
Comment 4 Ankit Kothana 2017-07-17 06:32:41 PDT
I am still facing this issue with a core dump taken up on a live process. lldb version used is 3.9.

ubuntu@ankit:~$ lldb-3.9 -f /usr/bin/node -c core.27395

(lldb) target create "/usr/bin/node" --core "core.27395"

Killed

OS details:

Linux <IP-Address> 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2 15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

node version : 6.10.1

npm version : 3.10.10
Comment 5 Ankit Kothana 2017-07-18 23:30:54 PDT
Any update on this??
Comment 6 labath 2017-07-19 01:48:11 PDT
(In reply to Ankit Kothana from comment #5)
> Any update on this??

This problem is already fixed in lldb 4.0. There will not be another 3.9 release, so there is nothing we can do about older versions. I'd suggest updating to lldb 4.0, or speaking to your distro if they would be willing to backport the fix.
Comment 7 Ankit Kothana 2017-07-19 02:46:23 PDT
(In reply to labath from comment #6)
> (In reply to Ankit Kothana from comment #5)
> > Any update on this??
> 
> This problem is already fixed in lldb 4.0. There will not be another 3.9
> release, so there is nothing we can do about older versions. I'd suggest
> updating to lldb 4.0, or speaking to your distro if they would be willing to
> backport the fix.

Thanks for the update.