Re: [lldb-dev] Prefered way to identify target device in tests?
> On Feb 11, 2016, at 12:15 PM, Ted Woodward via lldb-dev
> wrote:
>
> I’m working on getting the tests running with Hexagon, and have a question
> about identifying the target architecture.
>
> Hexagon LLVM doesn’t use a couple architectures like “x86_64” or “i386”,
> instead we have many architectures, like “v4”, “v5”, “v55”, “v56”, v60”, so
> using self.getArchitecture() can be problematic. I’ve got a list of Hexagon
> architectures in a global supported_hexagon_versions in lldbtest.py. When I
> need to check for Hexagon, should I do something like “self.getArchitecture
> in supported_hexagon_versions”, or something like this:
>
> self.runCmd("target list")
> if "arch=hexagon-*-*," in self.res.GetOutput():
>
> ?
>
> Ted
The architecture should be available from the test infrastructure. We have many
tests that have @expectedFile(archs=re.compile("^mips")). So each test knows
its architecture and this should be available in as a member variable of the
TestBase object that everyone inherits from. Search for "mips" in all tests. I
know some watchpoint tests are different on MIPS because they only have 1
hardware watchpoint available, so they had to work around some issues in those
tests. See how they did things and mimic that.
Greg
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Making a new symbol provider
> On Feb 11, 2016, at 6:56 PM, Zachary Turner wrote:
>
>
>
> On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton wrote:
>
> > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev
> > wrote:
> >
> > Hi,
> >
> > I want to make a new symbol provider to teach LLDB to understand microsoft
> > PDB files. I've been looking over the various symbol APIs, and I have a
> > few questions.
> >
> > 1. Under what circumstances do I need a custom SymbolVendor? The way pdb
> > works is that generally there is 1 file that contains all the debug info
> > needed for a single binary (so or executable). Given a list of paths, we
> > can then determine if there is a matching PDB in one of those paths. Is it
> > better to do this in the CalculateAbilities() function of the symbol file
> > plugin (by just returning 0 if we don't find a match) or do we need to do
> > something more complicated?
>
> I would suggest make a SymbolVendorPDB that only enables itself if you are
> able to find the PDB files for your COFF file. So look at your COFF file, and
> I presume somewhere in there there is a pointer to one or more PDB files
> inside that file? CalculateAbililties is the correct place to see if a COFF
> file has pointers to PDB files and making sure those files exist before you
> say that you can provide any abilities.
> Currently we use the operating system to query the PDBs. This could change
> in the future, but for now that's how we're doing it. The operating system
> does all the work of finding, matching, and loading the PDB for us, and it
> does it all in one call. So if we put this in the symbol vendor, there's no
> way to say "is there a PDB" without also saying "actually load all the data
> from the PDB" at the same time. So I'm not sure if there's a solution to
> this in there, because obviously I dont' want to load it twice.
Interesting. If you are on windows and you have a COFF file, you might just
want to make a SymbolVendorCOFF. Does PDB info always and only get created for
COFF files?
>
> One question I had about SymbolVendor, is that I looked at
> SymbolVendorELF.cpp and it seems to boil down to this notion of "symbol file
> representations". All the logic in SymbolVendorELF exists just to add some
> object file representations. What is this supposed to represent? I've got
> an exe or something, what other "representation" is there other than the exe
> itself?
In SymbolVendoerMacOSX, we have the executable and then the DWARF debug info in
a stand alone dSYM bundle. So MacOSX you have a.out as the main ObjectFile
(a.out) for a Module, but the symbols are in a different ObjectFile
(a.out.dSYM). For ELF I believe there is information in the ELF file that
_might_ point to a separate debug info file, but it also might just contain the
DWARF in the executable. So for ELF you have 1 file (exec ELF that contains
DWARF) or two files (exe ELF with no DWARF + debug info ELF with DWARF).
A symbol vendor's only job is to take an executable and and then use it plus
any other files (its job is to locate these extra debug files) to make a single
coherent view of the symbols for a lldb_private::Module. So the
SymbolVendor::FindTypes(...) might look into the executable file and one or
more other files to get the information. The information must be retrieved from
one or more SymbolFile instances. A SymbolFile uses one ObjectFile to do its
job. So there is a one to one mapping between SymbolFile and ObjectFile
instances. The SymbolFile can use the same ObjectFile as the main executable if
the data is in there. The SymbolVendor is the one that figures this out.
So some mappings might help show. The addresses before the object names are the
address of the class in the LLDB address space. For a simple a.out ELF file
that contains DWARF we would have:
0x1000: Module ("/tmp/a.out")
m_obj_file = 0x2000
0x2000: ObjectFile ("/tmp/a.out")
0x3000: SymbolVendorELF
m_sym_file = 0x4000
0x4000: SymbolFile
m_obj_file = 0x2000
For a a.out ELF file that contains an external debug file "/var/debug/a.out"
0x1000: Module ("/tmp/a.out")
m_obj_file = 0x2000
0x2000: ObjectFile ("/tmp/a.out")
0x2200: ObjectFile ("/var/debug/a.out")
0x3000: SymbolVendorELF
m_sym_file = 0x4000
0x4000: SymbolFile
m_obj_file = 0x2200
Same goes for MacOSX where we have "a.out" and "a.out.dSYM" except the
SymbolVendorMacOSX is used since it knows how to locate the dSYM files.
If there are multiple ObjectFile objects that represent the debug info, they
must share the same section list. So ObjectFiles and SymbolFiles work to make a
single section list within lldb_private::Module that is used for all objects
used to represent the symbol and debug info. That way the ObjectFile at 0x2000
and 0x2200 above both use the same section for ".text", ".data", etc. If one
ObjectFile has sections (like .debug_info for DWARF) where the other ObjectFile
doesn't
Re: [lldb-dev] Why is storing SBTarget in a private field causing random crash?
This is a clear bug in LLDB. If you have a repro case, please file a bug and
attach the instructions on how to make this happen. Our API must be able to
handle things like this.
SBTarget has a shared pointer to a lldb_private::Target. If you have a
reference to a target, it should keep that target alive and it shouldn't crash
later when it is actually freed.
So please file a bug and we'll get it fixed. For a work around for now, yes,
setting all SB references to None should help you work around the issue.
Greg
> On Feb 7, 2016, at 10:41 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> I have been spending long time troubleshooting a race condition in our lldb
> python test. I finally narrowed down to one code change that caused the race:
> basically, whenever I store SBTarget in DebuggerTestCase's self.target field
> lldb will randomly crash during destruction(see below).
>
> In the code, if I modify the two "self.target" to local variable "target" the
> random crash will disappear.
>
> I am not a python expert. Why is holding SBTarget will cause the test to
> random crash? Do I have to set every SBXXX fields to None before calling
> SBDebugger.Destroy()?
>
>
> ==Crash Stack==
> Crashed Thread:0 Dispatch queue: com.apple.main-thread
>
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0010
>
> VM Regions Near 0x10:
> -->
> __TEXT 00010d145000-00010d146000 [4K] r-x/rwx
> SM=COW
> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 com.apple.LLDB.framework 0x0001101c037d
> lldb_private::Listener::BroadcasterWillDestruct(lldb_private::Broadcaster*) +
> 95
> 1 com.apple.LLDB.framework 0x0001101a0da2
> lldb_private::Broadcaster::Clear() + 50
> 2 com.apple.LLDB.framework 0x0001101a0ced
> lldb_private::Broadcaster::~Broadcaster() + 75
> 3 com.apple.LLDB.framework 0x0001103d6879
> lldb_private::Target::~Target() + 741
> 4 com.apple.LLDB.framework 0x0001103d6c20
> lldb_private::Target::~Target() + 14
> 5 libc++.1.dylib0x7fff896448a6
> std::__1::__shared_weak_count::__release_shared() + 44
> 6 com.apple.LLDB.framework 0x00010e560664
> _wrap_delete_SBTarget(_object*, _object*) + 123
> 7 org.python.python 0x00010d15a50a PyObject_Call + 99
>
>
> ==Code==
> from find_lldb import lldb
> from simplest_event_thread import LLDBListenerThread
> import unittest
> import threading
>
> running_signal = threading.Event()
> stopped_signal = threading.Event()
>
> def launch_debugging(debugger, stop_at_entry):
> error = lldb.SBError()
> listener = lldb.SBListener('Chrome Dev Tools Listener')
> target = debugger.GetSelectedTarget()
> process = target.Launch (listener,
> None, # argv
> None, # envp
> None, # stdin_path
> None, # stdout_path
> None, # stderr_path
> None, # working directory
> 0, # launch flags
> stop_at_entry, # Stop at entry
> error) # error
> print 'Launch result: %s' % str(error)
>
> event_thread = LLDBListenerThread(debugger, running_signal,
> stopped_signal)
> event_thread.start()
>
> running_signal.set()
> return event_thread
>
> class DebuggerTestCase:
>
> def wait_for_process_stop(self):
> running_signal.wait()
> running_signal.clear()
> stopped_signal.wait()
> stopped_signal.clear()
>
> def test_breakpoint_at_line(self):
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path =
> '~/Personal/compiler/CompilerConstruction/code/compiler'
> self.target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
>
> event_thread = launch_debugging(debugger, stop_at_entry=True)
>
> process = debugger.GetSelectedTarget().process
> self.wait_for_process_stop() # wait for entry breakpoint.
> self.target.BreakpointCreateByName('main')
> process.Continue()
> self.wait_for_process_stop() # wait for main breakpoint.
>
> event_thread.should_quit = True
> event_thread.join()
> lldb.SBDebugger.Destroy(debugger)
>
> if __name__ == '__main__':
> test = DebuggerTestCase()
> for i in range(20):
> test.test_breakpoint_at_line()
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/lis
Re: [lldb-dev] Race condition crashes during launching LLDB
If you are going to set async to true, then you must consume the events by
waiting for events. See the following example:
svn cat
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
So you can rewrite your wait_for_process_stop to use the debugger to fetch the
events and do things correctly:
def wait_for_process_stop(debugger):
event_timeout_in_seconds = 10
listener = debugger.GetListener()
event = lldb.SBEvent()
stopped = False
while not stopped:
if listener.WaitForEvent (event_timeout_in_seconds, event):
if lldb.SBProcess.EventIsProcessEvent(event):
state = lldb.SBProcess.GetStateFromEvent (event)
if state == lldb.eStateStopped:
// Watch for something that stopped and restarted automatically
if SBProcess::GetRestartedFromEvent(event) == False:
stopped = True
The other option is to do it to set Async to False and then your target.Launch
won't return until the process is stopped. Also if you do "process.Continue()"
it won't return until the process is stopped. But you lose your ability to stop
the process if things go wrong...
Greg
> On Feb 4, 2016, at 9:09 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> After adding some logging I figured out that the race condition is caused by
> process.Continue() did not guarantee process has been really resumed yet in
> async mode, so the second wait_for_process_stop() is skipped immediately to
> kill listener thread and destroying debugger. I know I have a race condition
> bug here because of polling for process state, but why is lldb crashing when
> listener thread has exited and SBDebugger.Destroy() is called? What is the
> situation that SBDebugger.Destroy() can be called safely?
>
> ==do_test==
> Launch result: success
> Listening Thread ID: 4660334592
> WaitForEvent...
> Target event: ModulesLoaded
> WaitForEvent...
> Process event: StateChanged, Stopped
> Stop reason: 5
> WaitForEvent...
> Breakpoint event: [Added] SBBreakpoint: id = 1, name = 'main', locations = 1
> WaitForEvent...
> [main] killing listener thread
> Process event: StateChanged, Running
> Stop reason: 0
> Exiting listener thread
> [main] destroy debugger
> Segmentation fault: 11
>
> On Thu, Feb 4, 2016 at 8:22 PM, Jeffrey Tan wrote:
> Sorry, I have actually tried to exit the event listening thread before
> debugger destroy, but still go the crash randomly(1 out of 5 runs). Here is
> the code:
>
>
> ==Main Thread==
> def wait_for_process_stop(process):
> while not process.is_stopped:
> time.sleep(0.1)
>
> def launch_debugging(debugger, stop_at_entry):
> error = lldb.SBError()
> listener = lldb.SBListener('Chrome Dev Tools Listener')
> target = debugger.GetSelectedTarget()
> process = target.Launch (listener,
> None, # argv
> None, # envp
> None, # stdin_path
> None, # stdout_path
> None, # stderr_path
> None, # working directory
> 0, # launch flags
> stop_at_entry, # Stop at entry
> error) # error
> print 'Launch result: %s' % str(error)
> listener_thread = LLDBListenerThread(debugger)
> listener_thread.start()
> return listener_thread
>
> def do_test():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path = '~/Personal/compiler/CompilerConstruction/code/compiler'
> target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
>
> listener_thread = launch_debugging(debugger, stop_at_entry=True)
> process = debugger.GetSelectedTarget().process
>
> wait_for_process_stop(process) # wait for entry breakpoint.
> target.BreakpointCreateByName('main')
> process.Continue()
> wait_for_process_stop(process) # wait for main breakpoint.
>
> listener_thread.should_quit = True
> listener_thread.join()
>
> lldb.SBDebugger.Destroy(debugger)
>
> def main():
> do_test()
> do_test()
>
> ==Listening Thread==
> class LLDBListenerThread(Thread):
> should_quit = False
>
> def __init__(self, debugger):
> Thread.__init__(self)
> process = debugger.GetSelectedTarget().process
> self.listener = debugger.GetListener()
> self._add_listener_to_process(process)
> self._add_listener_to_target(process.target)
>
>def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = lldb.SBTarget.eBroadcastBitBreakpointChanged |
> lldb.SBTarget.eBroadcastBitWatchpointChanged |
> lldb.SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
>
> def _add_
Re: [lldb-dev] Race condition crashes during launching LLDB
The main problem you are running into is in async mode when you say "launch" or
"continue", those calls will return immediately and you must consume the events
to make sure it is safe to do things. If your process is stopped, then until
your actually resume your process with process.Continue() or any
thread.StepXXX() calls, your process will stay stopped. But when you ask to
make it run, you must consume events to know what the process is actually
doing...
> On Feb 12, 2016, at 10:02 AM, Greg Clayton via lldb-dev
> wrote:
>
> If you are going to set async to true, then you must consume the events by
> waiting for events. See the following example:
>
> svn cat
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
>
> So you can rewrite your wait_for_process_stop to use the debugger to fetch
> the events and do things correctly:
>
> def wait_for_process_stop(debugger):
> event_timeout_in_seconds = 10
> listener = debugger.GetListener()
> event = lldb.SBEvent()
> stopped = False
> while not stopped:
>if listener.WaitForEvent (event_timeout_in_seconds, event):
> if lldb.SBProcess.EventIsProcessEvent(event):
>state = lldb.SBProcess.GetStateFromEvent (event)
>if state == lldb.eStateStopped:
> // Watch for something that stopped and restarted automatically
> if SBProcess::GetRestartedFromEvent(event) == False:
>stopped = True
>
>
> The other option is to do it to set Async to False and then your
> target.Launch won't return until the process is stopped. Also if you do
> "process.Continue()" it won't return until the process is stopped. But you
> lose your ability to stop the process if things go wrong...
>
> Greg
>
>> On Feb 4, 2016, at 9:09 PM, Jeffrey Tan via lldb-dev
>> wrote:
>>
>> After adding some logging I figured out that the race condition is caused by
>> process.Continue() did not guarantee process has been really resumed yet in
>> async mode, so the second wait_for_process_stop() is skipped immediately to
>> kill listener thread and destroying debugger. I know I have a race condition
>> bug here because of polling for process state, but why is lldb crashing when
>> listener thread has exited and SBDebugger.Destroy() is called? What is the
>> situation that SBDebugger.Destroy() can be called safely?
>>
>> ==do_test==
>> Launch result: success
>> Listening Thread ID: 4660334592
>> WaitForEvent...
>> Target event: ModulesLoaded
>> WaitForEvent...
>> Process event: StateChanged, Stopped
>> Stop reason: 5
>> WaitForEvent...
>> Breakpoint event: [Added] SBBreakpoint: id = 1, name = 'main', locations = 1
>> WaitForEvent...
>> [main] killing listener thread
>> Process event: StateChanged, Running
>> Stop reason: 0
>> Exiting listener thread
>> [main] destroy debugger
>> Segmentation fault: 11
>>
>> On Thu, Feb 4, 2016 at 8:22 PM, Jeffrey Tan wrote:
>> Sorry, I have actually tried to exit the event listening thread before
>> debugger destroy, but still go the crash randomly(1 out of 5 runs). Here is
>> the code:
>>
>>
>> ==Main Thread==
>> def wait_for_process_stop(process):
>>while not process.is_stopped:
>>time.sleep(0.1)
>>
>> def launch_debugging(debugger, stop_at_entry):
>>error = lldb.SBError()
>>listener = lldb.SBListener('Chrome Dev Tools Listener')
>>target = debugger.GetSelectedTarget()
>>process = target.Launch (listener,
>>None, # argv
>>None, # envp
>>None, # stdin_path
>>None, # stdout_path
>>None, # stderr_path
>>None, # working directory
>>0, # launch flags
>>stop_at_entry, # Stop at entry
>>error) # error
>>print 'Launch result: %s' % str(error)
>>listener_thread = LLDBListenerThread(debugger)
>>listener_thread.start()
>>return listener_thread
>>
>> def do_test():
>>debugger = lldb.SBDebugger.Create()
>>debugger.SetAsync(True)
>>executable_path = '~/Personal/compiler/CompilerConstruction/code/compiler'
>>target = debugger.CreateTargetWithFileAndArch(executable_path,
>> lldb.LLDB_ARCH_DEFAULT)
>>
>>listener_thread = launch_debugging(debugger, stop_at_entry=True)
>>process = debugger.GetSelectedTarget().process
>>
>>wait_for_process_stop(process) # wait for entry breakpoint.
>>target.BreakpointCreateByName('main')
>>process.Continue()
>>wait_for_process_stop(process) # wait for main breakpoint.
>>
>>listener_thread.should_quit = True
>>listener_thread.join()
>>
>>lldb.SBDebugger.Destroy(debugger)
>>
>> def main():
>>do_test()
>>do_test()
>>
>> ==Listening Thread==
>> class LLDBListenerThread(Thread):
>>should_quit = False
>>
>>def __init__(self, debugger):
>> T
Re: [lldb-dev] Making a new symbol provider
On Fri, Feb 12, 2016 at 9:41 AM Greg Clayton wrote: > > > On Feb 11, 2016, at 6:56 PM, Zachary Turner wrote: > > > > > > > > On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton wrote: > > > > > On Feb 11, 2016, at 3:41 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > Hi, > > > > > > I want to make a new symbol provider to teach LLDB to understand > microsoft PDB files. I've been looking over the various symbol APIs, and I > have a few questions. > > > > > > 1. Under what circumstances do I need a custom SymbolVendor? The way > pdb works is that generally there is 1 file that contains all the debug > info needed for a single binary (so or executable). Given a list of paths, > we can then determine if there is a matching PDB in one of those paths. Is > it better to do this in the CalculateAbilities() function of the symbol > file plugin (by just returning 0 if we don't find a match) or do we need to > do something more complicated? > > > > I would suggest make a SymbolVendorPDB that only enables itself if you > are able to find the PDB files for your COFF file. So look at your COFF > file, and I presume somewhere in there there is a pointer to one or more > PDB files inside that file? CalculateAbililties is the correct place to see > if a COFF file has pointers to PDB files and making sure those files exist > before you say that you can provide any abilities. > > Currently we use the operating system to query the PDBs. This could > change in the future, but for now that's how we're doing it. The operating > system does all the work of finding, matching, and loading the PDB for us, > and it does it all in one call. So if we put this in the symbol vendor, > there's no way to say "is there a PDB" without also saying "actually load > all the data from the PDB" at the same time. So I'm not sure if there's a > solution to this in there, because obviously I dont' want to load it twice. > > Interesting. If you are on windows and you have a COFF file, you might > just want to make a SymbolVendorCOFF. Does PDB info always and only get > created for COFF files? > Yes. What's the disadvantage to just using the default SymbolVendor implementation, and just having the SymbolFilePDB plugin, when it's created, attempt to locate the PDB and just return 0 abilities if it can't find a match? > > > > One question I had about SymbolVendor, is that I looked at > SymbolVendorELF.cpp and it seems to boil down to this notion of "symbol > file representations". All the logic in SymbolVendorELF exists just to add > some object file representations. What is this supposed to represent? > I've got an exe or something, what other "representation" is there other > than the exe itself? > > In SymbolVendoerMacOSX, we have the executable and then the DWARF debug > info in a stand alone dSYM bundle. So MacOSX you have a.out as the main > ObjectFile (a.out) for a Module, but the symbols are in a different > ObjectFile (a.out.dSYM). For ELF I believe there is information in the ELF > file that _might_ point to a separate debug info file, but it also might > just contain the DWARF in the executable. So for ELF you have 1 file (exec > ELF that contains DWARF) or two files (exe ELF with no DWARF + debug info > ELF with DWARF). > Why does AddSymbolFileRepresentation take an ObjectFile though? A PDB is not an object file, so if we went and looked for a matching PDB, downloaded it from our build server, and wanted to use it, we couldn't exactly call AddSymbolFileRepresentation(pdb) because we wouldn't have an ObjectFile, we'd have a PDB. Maybe we'd need an overload of this function that just takes a SymbolFile* directly so that the vendor could add the SymbolFile it finds. > > A symbol vendor's only job is to take an executable and and then use it > plus any other files (its job is to locate these extra debug files) to make > a single coherent view of the symbols for a lldb_private::Module. So the > SymbolVendor::FindTypes(...) might look into the executable file and one or > more other files to get the information. The information must be retrieved > from one or more SymbolFile instances. A SymbolFile uses one ObjectFile to > do its job. So there is a one to one mapping between SymbolFile and > ObjectFile instances. The SymbolFile can use the same ObjectFile as the > main executable if the data is in there. The SymbolVendor is the one that > figures this out. > So in this case, there are no extra files. One object file (COFF) is all you need to locate the 1 PDB file. So we should be able to assume a 1-to-1 mapping between modules and SymbolFile instances. > So think of SymbolVendor as the class that knows how to locate the symbol > file for a given executable (possibly even fetch the symbols from your > build system!!!) We will definitely need something like this later, so I could see this being useful down the road. For now it seems like we can get by with just having a SymbolFilePDB class and using
Re: [lldb-dev] Why is storing SBTarget in a private field causing random crash?
The broadcasters and listeners depend mutually on one another. The listener
keeps a list of the broadcasters it is listening to, and the broadcaster a list
of the listeners it is broadcasting to. When the broadcaster goes down it
removes the listeners from its list and ditto for the listeners and their
broadcaster list. And these lists are protected by mutexes, so they should keep
each other out of trouble. But it looks like there's some way that we can get
a listener destroyed but not removed from the broadcaster's list by the point
where the broadcaster goes to remove it. I've seen reports of this but not
reproducible ones. If you have a case that reproduces easily, I would love to
take a look at it.
Jim
> On Feb 12, 2016, at 9:50 AM, Greg Clayton via lldb-dev
> wrote:
>
> This is a clear bug in LLDB. If you have a repro case, please file a bug and
> attach the instructions on how to make this happen. Our API must be able to
> handle things like this.
>
> SBTarget has a shared pointer to a lldb_private::Target. If you have a
> reference to a target, it should keep that target alive and it shouldn't
> crash later when it is actually freed.
>
> So please file a bug and we'll get it fixed. For a work around for now, yes,
> setting all SB references to None should help you work around the issue.
>
> Greg
>
>> On Feb 7, 2016, at 10:41 PM, Jeffrey Tan via lldb-dev
>> wrote:
>>
>> Hi,
>>
>> I have been spending long time troubleshooting a race condition in our lldb
>> python test. I finally narrowed down to one code change that caused the
>> race: basically, whenever I store SBTarget in DebuggerTestCase's self.target
>> field lldb will randomly crash during destruction(see below).
>>
>> In the code, if I modify the two "self.target" to local variable "target"
>> the random crash will disappear.
>>
>> I am not a python expert. Why is holding SBTarget will cause the test to
>> random crash? Do I have to set every SBXXX fields to None before calling
>> SBDebugger.Destroy()?
>>
>>
>> ==Crash Stack==
>> Crashed Thread:0 Dispatch queue: com.apple.main-thread
>>
>> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
>> Exception Codes: KERN_INVALID_ADDRESS at 0x0010
>>
>> VM Regions Near 0x10:
>> -->
>>__TEXT 00010d145000-00010d146000 [4K] r-x/rwx
>> SM=COW
>> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>>
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0 com.apple.LLDB.framework 0x0001101c037d
>> lldb_private::Listener::BroadcasterWillDestruct(lldb_private::Broadcaster*)
>> + 95
>> 1 com.apple.LLDB.framework 0x0001101a0da2
>> lldb_private::Broadcaster::Clear() + 50
>> 2 com.apple.LLDB.framework 0x0001101a0ced
>> lldb_private::Broadcaster::~Broadcaster() + 75
>> 3 com.apple.LLDB.framework 0x0001103d6879
>> lldb_private::Target::~Target() + 741
>> 4 com.apple.LLDB.framework 0x0001103d6c20
>> lldb_private::Target::~Target() + 14
>> 5 libc++.1.dylib 0x7fff896448a6
>> std::__1::__shared_weak_count::__release_shared() + 44
>> 6 com.apple.LLDB.framework 0x00010e560664
>> _wrap_delete_SBTarget(_object*, _object*) + 123
>> 7 org.python.python0x00010d15a50a PyObject_Call + 99
>>
>>
>> ==Code==
>> from find_lldb import lldb
>> from simplest_event_thread import LLDBListenerThread
>> import unittest
>> import threading
>>
>> running_signal = threading.Event()
>> stopped_signal = threading.Event()
>>
>> def launch_debugging(debugger, stop_at_entry):
>>error = lldb.SBError()
>>listener = lldb.SBListener('Chrome Dev Tools Listener')
>>target = debugger.GetSelectedTarget()
>>process = target.Launch (listener,
>>None, # argv
>>None, # envp
>>None, # stdin_path
>>None, # stdout_path
>>None, # stderr_path
>>None, # working directory
>>0, # launch flags
>>stop_at_entry, # Stop at entry
>>error) # error
>>print 'Launch result: %s' % str(error)
>>
>>event_thread = LLDBListenerThread(debugger, running_signal,
>> stopped_signal)
>>event_thread.start()
>>
>>running_signal.set()
>>return event_thread
>>
>> class DebuggerTestCase:
>>
>>def wait_for_process_stop(self):
>>running_signal.wait()
>>running_signal.clear()
>>stopped_signal.wait()
>>stopped_signal.clear()
>>
>>def test_breakpoint_at_line(self):
>>debugger = lldb.SBDebugger.Create()
>>debugger.SetAsync(True)
>>executable_path =
>> '~/Personal/compil
Re: [lldb-dev] Making a new symbol provider
On Thu, Feb 11, 2016 at 5:35 PM Greg Clayton wrote: > > > 5. ParseCompileUnitLineTable. On the LineTable class you can add "line > sequences" or individual entries. What's the difference here? Is there > any disadvantage to adding every single line entry in the line table using > the InsertLineEntry instead of building a line sequence and inserting the > sequence? > > The rule follows DWARF line tables: line sequences must be an array of > line entries whose addresses are always increasing. You can add every line > in sequence as long as the line entries are in increasing address order. We > are going to sort the line entries into an array that is sorted for quick > lookups. > Just to make sure I understand, semantically here, there is nothing special about a line sequence, it's just an optimization to let LineTable know you're giving it sorted values? So any lines you add via a LineSequence, could also be added individually with insertLine, but it would be slower? And aside from that everything else would still work as expected? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
