[llvm-bugs] [Bug 24600] New: TestHelloWorld can't get a valid callstack after attaching

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Aug 27 11:41:31 PDT 2015


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

            Bug ID: 24600
           Summary: TestHelloWorld can't get a valid callstack after
                    attaching
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: zturner at google.com
                CC: llvm-bugs at lists.llvm.org
            Blocks: 21766
    Classification: Unclassified

The log file shows this:

looking at: Stack traces for SBProcess: pid = 832, state = stopped, threads =
2, executable = test_with_dwarf_and_attach_to_process_with_id_api
Stack trace for thread id=0x47c name=None queue=None stop reason=none
  frame #0: 0xffffffffffffffff ntdll.dll`DbgBreakPoint + 1

Stack trace for thread id=0xc68 name=None queue=None stop reason=none
  frame #0: 0x00000077908c2c None`None + -18446744071703589843



Expecting sub string: main.c:30
Not matched

FAIL

It is expecting to see the second thread stopped in main, but it is stopped
somewhere else.  The address looks reasonable, so it is most likely that the
main thread hasn't yet gotten through process initialization yet and it is
still in loader initialization or CRT initialization.

Another possibility is that we just have a bug relating to multiple threads and
the address is totally bogus.


We should fix the test suite to not rely on racy behavior like this by
implementing a cross-platform is_debugger_present() function that all test
inferiors can use so we can synchronize debugger behavior with test suite
behavior, but to fix this completely we will always need to provide a way to
skip the initial breakpoint so that we only hit the user-created breakpoint and
not the loader breakpoint, guaranteeing that the code is in main.

-- 
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/20150827/674015a8/attachment.html>


More information about the llvm-bugs mailing list