[llvm-bugs] [Bug 26322] New: Core load hangs

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26322

            Bug ID: 26322
           Summary: Core load hangs
           Product: lldb
           Version: 3.8
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: eugenebi at hotmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

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)
                 {

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160126/2a275da1/attachment.html>