[Mono-bugs] [Bug 519295] New: mono-debugger fails to initialize thread_db if libpthread.so lacks a .symtab

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=519295


           Summary: mono-debugger fails to initialize thread_db if
                    libpthread.so lacks a .symtab
    Classification: Mono
           Product: Mono: Debugger
           Version: 2.4.x
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: backend
        AssignedTo: martin at novell.com
        ReportedBy: flameeyes at gentoo.org
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11)
Gecko/2009063000 Gentoo Firefox/3.0.11

When the libpthread.so library is stripped of its .symtab, mdb will fail to
initialize thread_db, the td_ta_new() function calls into ps_pglobal_lookup()
to find "nptl_version" inside libpthread.so, which is a static (used, so always
emitted) symbol. This function in turn calls back into managed C# code that
uses the BFD library to look up the symbol.

This has two problems:

 - if glibc has been stripped, the user is reported a strange failure instead
of being told that the debugger couldn't start; it also seems to freeze rather
than simply exiting:

***** Mono.Debugger.Tests.TestAbort.Main
Failed to initialize thread_db on
/usr/bin/mono:--inside-mdb:/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/test/src/TestAbort.exe
Failed to initialize thread_db on
/usr/bin/mono:--inside-mdb:/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/test/src/TestAbort.exe:
Mono.Debugger.Backend.ProcessStart
(/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/build:/usr/bin/mono:--inside-mdb:/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/test/src/TestAbort.exe:False)
   at System.Environment.get_StackTrace() in
/var/tmp/portage/dev-lang/mono-2.4.2/work/mono-2.4.2/mcs/class/corlib/System/Environment.cs:line
202
   at
Mono.Debugger.Backend.ProcessServant.GetEngineByTID(Mono.Debugger.Backend.Inferior
inferior, Int64 tid) in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ProcessServant.cs:line
498
   at
Mono.Debugger.Backend.MonoThreadManager.HandleChildEvent(Mono.Debugger.Backend.SingleSteppingEngine
engine, Mono.Debugger.Backend.Inferior inferior,
Mono.Debugger.Backend.ChildEvent ByRef cevent, Boolean ByRef resume_target) in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/MonoThreadManager.cs:line
286
   at
Mono.Debugger.Backend.ThreadManager.HandleChildEvent(Mono.Debugger.Backend.SingleSteppingEngine
engine, Mono.Debugger.Backend.Inferior inferior,
Mono.Debugger.Backend.ChildEvent ByRef cevent, Boolean ByRef resume_target) in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ThreadManager.cs:line
210
   at
Mono.Debugger.Backend.SingleSteppingEngine.ProcessEvent(Mono.Debugger.Backend.ChildEvent
cevent) in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/SingleSteppingEngine.cs:line
216
   at Mono.Debugger.Backend.SingleSteppingEngine.ProcessEvent(Int32 status) in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/SingleSteppingEngine.cs:line
155
   at Mono.Debugger.Backend.ThreadManager.engine_thread_main() in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ThreadManager.cs:line
333
   at Mono.Debugger.Backend.ThreadManager.start_inferior() in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ThreadManager.cs:line
101
EXCEPTION: Mono.Debugger.InternalError: Internal error.
  at Mono.Debugger.Backend.ProcessServant.GetEngineByTID
(Mono.Debugger.Backend.Inferior inferior, Int64 tid) [0x0010b] in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ProcessServant.cs:498 
  at (wrapper remoting-invoke-with-check)
Mono.Debugger.Backend.ProcessServant:GetEngineByTID
(Mono.Debugger.Backend.Inferior,long)
  at Mono.Debugger.Backend.MonoThreadManager.HandleChildEvent
(Mono.Debugger.Backend.SingleSteppingEngine engine,
Mono.Debugger.Backend.Inferior inferior, Mono.Debugger.Backend.ChildEvent&
cevent, System.Boolean& resume_target) [0x0020e] in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/MonoThreadManager.cs:286 
  at Mono.Debugger.Backend.ThreadManager.HandleChildEvent
(Mono.Debugger.Backend.SingleSteppingEngine engine,
Mono.Debugger.Backend.Inferior inferior, Mono.Debugger.Backend.ChildEvent&
cevent, System.Boolean& resume_target) [0x00121] in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ThreadManager.cs:210 
  at (wrapper remoting-invoke-with-check)
Mono.Debugger.Backend.ThreadManager:HandleChildEvent
(Mono.Debugger.Backend.SingleSteppingEngine,Mono.Debugger.Backend.Inferior,Mono.Debugger.Backend.Inferior/ChildEvent&,bool&)
  at Mono.Debugger.Backend.SingleSteppingEngine.ProcessEvent
(Mono.Debugger.Backend.ChildEvent cevent) [0x0021e] in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/SingleSteppingEngine.cs:216 
  at Mono.Debugger.Backend.SingleSteppingEngine.ProcessEvent (Int32 status)
[0x0000c] in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/SingleSteppingEngine.cs:155 
  at (wrapper remoting-invoke-with-check)
Mono.Debugger.Backend.SingleSteppingEngine:ProcessEvent (int)
  at Mono.Debugger.Backend.ThreadManager.engine_thread_main () [0x000cd] in
/var/tmp/portage/dev-util/mono-debugger-2.4.2/work/mono-debugger-2.4.2/backend/ThreadManager.cs:333 

 - if the distribution has stripped libpthread.so (like in the case of Gentoo)
but the debug information file _is_ available with the .symtab, mdb will fail
to cope with it and will also crash.

The extension of the latter problem is that if, like in the case of Fedora at
least, libpthread.so is not stripped (and thus mdb will start) but the rest of
the system is stripped and has split debug information, then mdb still will
have no idea how to read the symbols for the unmanaged code.

A solution would be to read the debug link of the file, if there is one, and
check for sections in both before saying that it wouldn't be found (note: the
debug file has no .dynamic section so it cannot be loaded like the dynamic
objects are, right now!).

Reproducible: Always

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.