Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lldb fails to evaluate an expression that requires running multiple threads #15630

Closed
llvmbot opened this issue Feb 14, 2013 · 8 comments
Closed

lldb fails to evaluate an expression that requires running multiple threads #15630

llvmbot opened this issue Feb 14, 2013 · 8 comments
Labels
bugzilla Issues migrated from bugzilla lldb worksforme Resolved as "works for me"

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 14, 2013

Bugzilla Link 15258
Resolution WORKSFORME
Resolved on Mar 26, 2015 23:45
Version unspecified
OS Linux
Reporter LLVM Bugzilla Contributor
CC @emaste

Extended Description

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.
@llvmbot
Copy link
Collaborator Author

llvmbot commented Aug 9, 2013

Addressed with r188075 though why we receive the signal spuriously is still unknown.

@emaste
Copy link
Member

emaste commented Sep 8, 2013

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

@llvmbot
Copy link
Collaborator Author

llvmbot commented Sep 9, 2013

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.

@emaste
Copy link
Member

emaste commented Sep 9, 2013

It now appears that this test passes on FreeBSD if run in isolation, but fails regularly if the whole test suite is run

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 28, 2014

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.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 28, 2014

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.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 28, 2014

Given comment #​6, I'm reopening this.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 27, 2015

tested with x86_64 ubuntu 14.04 gcc/clang-3.5

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 4, 2021
@Quuxplusone Quuxplusone added the worksforme Resolved as "works for me" label Jan 20, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla lldb worksforme Resolved as "works for me"
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Quuxplusone @emaste @llvmbot