> On Feb 21, 2015, at 10:17 AM, Paul Smith <p...@mad-scientist.net> wrote: > > On Fri, 2015-02-20 at 12:53 -0800, Greg Clayton wrote: >> I found the race condition. > > Cool! I'll try the workaround and the latest version. > > > Question: would this impact only the Python interface? Or could it be > seen in the normal LLDB CLI interface as well?
Probably if you source a LLDB command file you could run into this. Typing by hand is probably going to be ok. > Also, could this result > in a hang, instead of a crash? Quite possibly. Any race condition that borks the heap can cause general mayhem. > > One of my scripts tries to use the LLDB -s scripting interface just to > list the image info, so I wrote a simple script: > > target create -c core.12345 > image list > exit > > However, when I run this from my script (using "lldb -s") it will > regularly hang (although it works OK interactively). I have to run it a > couple of times to get a good result. The race condition is definitely there for source command files. Since it may or may not bork the heap, I would suggest possibly adding a "script import time; time.usleep(250000)" before the image list unless you get the top of tree sources. > > > Is there another/better way to get the fully-qualified name of the > executable that was running, given nothing but the coredump? No, the dynamic loader will be able to figure it out and then you might need to lookup your binary on a build server using the UUID, path and triple. So there is no better way than just loading the core dumper and letting the dynamic loader figure it out for real. Of course you might be able to improve your core dump to include the main executable somewhere in notes, or sections, but I am guessing this probably isn't a viable option for most. Greg _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
