LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 15258 - lldb fails to evaluate an expression that requires running multiple threads
Summary: lldb fails to evaluate an expression that requires running multiple threads
Status: RESOLVED WORKSFORME
Alias: None
Product: lldb
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P normal
Assignee: LLDB commit list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-13 16:03 PST by Daniel Malea
Modified: 2015-03-26 23:45 PDT (History)
4 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Malea 2013-02-13 16:03:07 PST 
In the testcase TestExprDoesntBlock.py, the inferior sometimes (but not always) receives a SIGSEGV during expression evaluation. The siginfo structure that LLDB gets from the kernel has an invalid si_code value (128 == SI_KERNEL).

According to siginfo docs, si_code == SI_KERNEL means that the signal was sent by the kernel -- but not because a protected or otherwise invalid address was accessed. Most likely this is happening because of some ptrace() mis-use somewhere.

While it would be trivial to handle SI_KERNEL and add an appropriate exit-description string to ProcessMessage.[h|cpp] we want to find out why SI_KERNEL is being sent to this test case, and why it is not happening always.

Skipping the test case until someone else has time to look at it further.
Comment 1 Matt Kopec 2013-08-09 14:12:00 PDT 
Addressed with r188075 though why we receive the signal spuriously is still unknown.
Comment 2 emaste 2013-09-08 13:40:14 PDT 
Should this test be reenabled on Linux now?

It fails on FreeBSD with my threads WIP, with
  File "/tank/emaste/src/llvm/tools/lldb/test/functionalities/expr-doesnt-deadlock/TestExprDoesntBlock.py", line 67, in expr_doesnt_deadlock
    self.assertTrue (var.GetValueAsSigned (0) == 567)
AssertionError: False is not True
Comment 3 Daniel Malea 2013-09-09 16:07:41 PDT 
The crash is no longer happening on Linux, as far as I can tell.

However, this test cannot be re-enabled because it fails intermittently on Linux at the same point as Ed reported.

It looks like the expression that requires unblocking all the threads is failing to evaluate sometimes. It doesn't appear to be an issue of the threads being starved because bumping the timeout up (from the default 0.5s to 5s) does not have any effect on the test.
Comment 4 emaste 2013-09-09 16:19:55 PDT 
It now appears that this test passes on FreeBSD if run in isolation, but fails regularly if the whole test suite is run
Comment 5 Todd Fiala 2014-02-27 18:47:12 PST 
Tested against top of tree lldb svn r202448.  Ran TestExprDoesntBlock.py 10 times in a row, succeeded on Ubuntu 12.04 LTS x86_64, lldb built with gcc 4.8.2 and July 2013 libedit.

Enabled with r202456.
Comment 6 Todd Fiala 2014-02-28 11:54:35 PST 
r202517 - changed TestExprDoesntBlock.py to expected failure on Linux.  I'm not sure how I got it running successfully before - I believe it must have been a bogus test run.  This now consistently fails for me on Linux.
Comment 7 Todd Fiala 2014-02-28 11:56:05 PST 
Given comment #6, I'm reopening this.
Comment 8 Vince Harron 2015-03-26 23:45:39 PDT 
tested with x86_64 ubuntu 14.04 gcc/clang-3.5