[lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock
Hi, I've got a problem with lldb deadlocking upon a call to lldb::SBDebugger::Terminate(). I am currently using svn revision 247535 of llvm and lldb, and I know that my code was working with svn revision 229496. In short, I am doing the following steps: lldb_debugger = lldb::SBDebugger::Create() lldb_debugger.SetAsync(true) lldb_target = lldb_debugger.CreateTarget() lldb_process = lldb_target.AttachToProcessWithID() ... (doing stuff with modules) lldb::SBDebugger::Terminate() The last call results in a deadlock. I enabled the DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING macros within Mutex.cpp and found out that a mutex is getting locked whose ID never came up in the log before. This mutex has no owner, so it should be lockable - but it isn't... A gdb backtrace with the last few debug messages can be found here: http://pastebin.com/Kv4EidHx Does anyone have an idea what is going on here? Am I missing something? Thanks in advance! Cheers, Stefan Kratochwil ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock
Hi, Thanks for the report. Since you are suspecting a deadlock, could you post a backtrace of all the threads (thread apply all backtrace). It would be best to move this discussion to a bug in llvm.org/bugs. > I am currently using svn revision 247535 of llvm and lldb, and I know that my > code was working with svn revision 229496 This sounds like a pretty big revision range. It would help if you could narrow it down a bit. pl On 28 September 2015 at 09:12, Stefan Kratochwil via lldb-dev wrote: > Hi, > > I've got a problem with lldb deadlocking upon a call to > lldb::SBDebugger::Terminate(). > > I am currently using svn revision 247535 of llvm and lldb, and I know that > my code was working with svn revision 229496. > > In short, I am doing the following steps: > > lldb_debugger = lldb::SBDebugger::Create() > lldb_debugger.SetAsync(true) > lldb_target = lldb_debugger.CreateTarget() > lldb_process = lldb_target.AttachToProcessWithID() > ... (doing stuff with modules) > lldb::SBDebugger::Terminate() > > The last call results in a deadlock. > > I enabled the DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING macros within > Mutex.cpp and found out that a mutex is getting locked whose ID never came > up in the log before. This mutex has no owner, so it should be lockable - > but it isn't... > > A gdb backtrace with the last few debug messages can be found here: > http://pastebin.com/Kv4EidHx > > > Does anyone have an idea what is going on here? Am I missing something? > > Thanks in advance! > > > Cheers, > Stefan Kratochwil > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] possible test runner speedup
Hi, Interesting results. We were discussing the same thing last week. I was somewhat skeptical to the ideal as I am afraid of increased flakyness -- LLDB has hardcoded timeout values in a lot of places, and with increased cpu contention, we might start to see this code failing because the other side was slower than expected. I have now tried running the test suite with a higher number of threads and it seems it working quite alright, so I think we can try that. I'll watch the buildbots for signs of increased flakyness. FWIW, it did not speed up the tests for me at all, but I guess that's expected, as it ran in 90 seconds even before that, and the limiting factor there probably is the longest test. As for the timeout, I have set the value to 4 minutes, based on the formula: 2 * (number of seconds when I first started noticing flaky tests in the slowest configuration). The slowest configuration here was running the test suite on a debug build of lldb and using debug ToT clang to compile the inferiors (believe it or not, this makes a big difference). So there is still some leeway here, but if you're gonna reduce the default, please make sure it is enough for the slowest test configuration also. For faster configurations you can always override the timeout manually. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] correct event sequence on process detach
Hello all, The following question came up while fixing up handling of process detach. when detaching from a running process, on some platforms LLDB needs to stop it first. Is this stop something that should be hidden from the public view or not? I.e. if the process state is Running, and I do a process.Detach(), what is the correct sequence of public state transitions one should observe: a) Running -> Detached ? b) (Running -> Stopped -> Detached) or (Running -> Detached), depending on whether the platform performs the maintenance stop? My feeling is it should be a), but I wanted to double check first. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24958] New: lldb::SBDebugger::Terminate() results in Deadlock
https://llvm.org/bugs/show_bug.cgi?id=24958 Bug ID: 24958 Summary: lldb::SBDebugger::Terminate() results in Deadlock Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: kratoch...@teco.edu CC: llvm-b...@lists.llvm.org Classification: Unclassified Created attachment 14945 --> https://llvm.org/bugs/attachment.cgi?id=14945&action=edit Complete debug log, backtrace is at the end. The questionable mutex is 0x77dc2fc0. While using the C++ API (Scripting Bridge) of lldb (svn revision 247535), the following (abbreviated) call sequence results in a Deadlock: lldb_debugger = lldb::SBDebugger::Create() lldb_debugger.SetAsync(true) lldb_target = lldb_debugger.CreateTarget() lldb_process = lldb_target.AttachToProcessWithID() ... (doing stuff with modules) lldb::SBDebugger::Terminate() I compiled Mutex.cpp with both debug macros DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING enabled - the latter results in my program receiving a SIGABRT instead of a deadlock, due to the mutex error checking code. I noticed that the call to lldb_private::Debugger::Terminate() ends up in lldb_private::Mutex::Lock(). Here a mutex is being locked which was already locked / unlocked a few times earlier (see attachment: the mutex has the ID 0x77dc2fc0). I know that my code worked with svn revision 229496 (tested it a few hours ago). The debug log is quite lengthy - sorry for that. At the bottom you'll find a complete gdb backtrace. I'll recompile lldb without the error checking macros to see if there is more than one thread running when the deadlock occurs. I'll be back in a minute... -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock
Hi Pavel, thanks for your quick reply. I filed a bug at https://llvm.org/bugs/show_bug.cgi?id=24958. I'll try to determine a more precise revision range for that issue. I am currently using svn (checking out lldb manually into llvm/tools). Do you have a recommended workflow for git in such a situation? git bisect with subtree / submodule? Cheers, Stefan On 09/28/2015 10:24 AM, Pavel Labath wrote: Hi, Thanks for the report. Since you are suspecting a deadlock, could you post a backtrace of all the threads (thread apply all backtrace). It would be best to move this discussion to a bug in llvm.org/bugs. I am currently using svn revision 247535 of llvm and lldb, and I know that my code was working with svn revision 229496 This sounds like a pretty big revision range. It would help if you could narrow it down a bit. pl On 28 September 2015 at 09:12, Stefan Kratochwil via lldb-dev wrote: Hi, I've got a problem with lldb deadlocking upon a call to lldb::SBDebugger::Terminate(). I am currently using svn revision 247535 of llvm and lldb, and I know that my code was working with svn revision 229496. In short, I am doing the following steps: lldb_debugger = lldb::SBDebugger::Create() lldb_debugger.SetAsync(true) lldb_target = lldb_debugger.CreateTarget() lldb_process = lldb_target.AttachToProcessWithID() ... (doing stuff with modules) lldb::SBDebugger::Terminate() The last call results in a deadlock. I enabled the DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING macros within Mutex.cpp and found out that a mutex is getting locked whose ID never came up in the log before. This mutex has no owner, so it should be lockable - but it isn't... A gdb backtrace with the last few debug messages can be found here: http://pastebin.com/Kv4EidHx Does anyone have an idea what is going on here? Am I missing something? Thanks in advance! Cheers, Stefan Kratochwil ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24959] New: Mismatch between binary and host architectures unless absolute path is given
https://llvm.org/bugs/show_bug.cgi?id=24959 Bug ID: 24959 Summary: Mismatch between binary and host architectures unless absolute path is given Product: lldb Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: evange...@foutrelis.com CC: llvm-b...@lists.llvm.org Classification: Unclassified The following behavior in LLDB 3.7.0 seems quite weird; unless I specify an absolute path, lldb will refuse to create a target for an executable that exists in $PATH. If I specify an absolute path then it works fine. (Perhaps related to bug 20400.) `llvm-config --host-target` prints "i686-pc-linux-gnu". Bellow is an lldb session that showcases the issue: (lldb) target create ls error: '/usr/bin/ls' doesn't contain any 'host' platform architectures: i686 (lldb) target create /usr/bin/ls Current executable set to '/usr/bin/ls' (i386). (lldb) target list Current targets: * target #0: /usr/bin/ls ( arch=i386-unknown-linux, platform=remote-linux ) -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLVM Social - Paris: October 15, 2015
The next LLVM social in Paris will happen on October 15th, 2015. Everyone interested in LLVM, Clang, lldb, Polly, ... is invited to join. Note that we have slightly changed the meetup format: from now on we will start with a presentation, which will be followed-up by the usual informal social. For this meetup Calixte Denizet will talk about Scilab's ( http://www.scilab.org) usage of LLVM. We are looking for volunteers to present at the next meetups; this does not have to be a formal presentation: this could as well be a tutorial, a BoF, a bugfix party, ... Be creative ! If interested, please talk to one of the organizers (Duncan, Sylvestre or myself). Event details, including free registration at http://www.meetup.com/LLVM-Clang-social Looking forward to meet you, -- Arnaud de Grandmaison, Duncan Sands, Sylvestre Ledru, Tobias Grosser ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] possible test runner speedup
On Mon, Sep 28, 2015 at 2:12 AM, Pavel Labath wrote: > Hi, > > Interesting results. We were discussing the same thing last week. I > was somewhat skeptical to the ideal as I am afraid of increased > flakyness -- LLDB has hardcoded timeout values in a lot of places, and > with increased cpu contention, we might start to see this code failing > because the other side was slower than expected. > Yeah, when I first did this a while back (just the parallel piece, not the speedup of it), I think it uncovered a ton of races/flakiness. Much of that has been addressed, but nothing like forcing more contention to work out more of them. > > I have now tried running the test suite with a higher number of > threads and it seems it working quite alright, so I think we can try > that. I'll watch the buildbots for signs of increased flakyness. FWIW, > it did not speed up the tests for me at all, but I guess that's > expected, as it ran in 90 seconds even before that, and the limiting > factor there probably is the longest test. > > Yeah, all those lengthy debugserver/lldb-server tests I wrote a while back tend to have a long tail, and I'm sure you folks have only extended them since then. I have some thoughts on improving the job scheduling in the future (finer grain) but not in the short term. > As for the timeout, I have set the value to 4 minutes, based on the > formula: 2 * (number of seconds when I first started noticing flaky > tests in the slowest configuration). The slowest configuration here > was running the test suite on a debug build of lldb and using debug > ToT clang to compile the inferiors (believe it or not, this makes a > big difference). So there is still some leeway here, but if you're > gonna reduce the default, please make sure it is enough for the > slowest test configuration also. For faster configurations you can > always override the timeout manually. > > pl > Okay. I'm not planning on touching the timeout values at this point, just noting that they may be worth messing with in the future. I'd like to add a very lightweight stats database (that's already too heavy a word, but conveys the idea) that can be arranged to persist across builds (that last part specifically for buildbots). With just a tiny bit of historical data when available, job scheduling to reduce total time of test run could be improved. And with some finer grain scheduling which I plan to look into mid-term via a mechanism to prevent a single test method hangup from knocking out the rest of the test methods in the same run, we could do even better yet. But I'll bring this up when I get closer to having some time to work on it. (And that's not yet!) -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24974] New: Debian Makefile lldb build is broken
https://llvm.org/bugs/show_bug.cgi?id=24974 Bug ID: 24974 Summary: Debian Makefile lldb build is broken Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified I've been looking into several issues with Sylvestre. So far I see these: 1. the build is not producing a versioned lldb driver or liblldb.so, but the non-versioned lldb driver is attempting to load the (not-present) liblldb-3.8.so. I manually created the link, which allows the lldb driver to load without crashing. Then I hit: 2. the python lldb module does not have the _lldb.so link in it. This causes all the tests that use the lldb module to fail. I manually created the link, which allows the Python lldb module to load. Then I hit: 3. A segfault the first time a test runs: # python /root/llvm-toolchain-snapshot-3.8~svn248678/tools/lldb/test/dotest.py --executable /root/llvm-toolchain-snapshot-3.8~svn248678/build-llvm/Release/bin/lldb -s lldb-test-traces -u CXXFLAGS -u CFLAGS -C gcc-4.9 --no-multiprocess -v ['/root/llvm-toolchain-snapshot-3.8~svn248678/tools/lldb/test/dotest.py', '--executable', '/root/llvm-toolchain-snapshot-3.8~svn248678/build-llvm/Release/bin/lldb', '-s', 'lldb-test-traces', '-u', 'CXXFLAGS', '-u', 'CFLAGS', '-C', 'gcc-4.9', '--no-multiprocess', '-v'] LLDB library dir: /root/llvm-toolchain-snapshot-3.8~svn248678/build-llvm/Release/bin LLDB import library dir: /root/llvm-toolchain-snapshot-3.8~svn248678/build-llvm/Release/bin lldb version 3.8.0 ( revision ) lldb.pre_flight: None lldb.post_flight: None Session logs for test failures/errors/unexpected successes will go into directory 'lldb-test-traces' Command invoked: /root/llvm-toolchain-snapshot-3.8~svn248678/tools/lldb/test/dotest.py --executable /root/llvm-toolchain-snapshot-3.8~svn248678/build-llvm/Release/bin/lldb -s lldb-test-traces -u CXXFLAGS -u CFLAGS -C gcc-4.9 --no-multiprocess -v compilers=['gcc-4.9'] Configuration: arch=x86_64 compiler=gcc-4.9 -- Collected 1386 tests 1: test_display_source_python (TestSourceManager.SourceManagerTestCase) Test display of source using the SBSourceManager API. ... Segmentation fault That brings me to now. I'll have a look at the seg fault. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24974] Debian Makefile lldb build is broken
https://llvm.org/bugs/show_bug.cgi?id=24974 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com --- Comment #1 from Todd Fiala --- I'll take this to figure out what the segfault issue is. I may need a Makefile maintainer to look at the steps that failed to occur (issues #1 and #2 previously mentioned). -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24976] New: Data from SBProcess::PutSTDIN appears in SBProcess::GetSTDOUT
https://llvm.org/bugs/show_bug.cgi?id=24976
Bug ID: 24976
Summary: Data from SBProcess::PutSTDIN appears in
SBProcess::GetSTDOUT
Product: lldb
Version: 3.6
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: beryku...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Created attachment 14953
--> https://llvm.org/bugs/attachment.cgi?id=14953&action=edit
Python script with PutSTDIN and GetSTDOUT test
When I use the function SBProcess::PutSTDIN to put data into process' STDIN,
the entered data then appears when I get the process' STDOUT.
I attached C++ test program which reads a string (x) and then outputs "stdout:
" and a python script that shows that the stdout contains both "stdout: "
and x. The sleep is there to wait for the program to output data.
// C++ program:
#include
using namespace std;
int main(int argc, char** argv)
{
string a;
cin >> a;
cout << "stdout: " << a << endl;
return 0;
}
After I run this program with input "test", it should output "stdout: test".
But when I put "test" to the process via PutSTDIN, the GetSTDOUT contains both
"test" and "stdout: test".
Am I doing something wrong?
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
