Thanks Greg - I don't mean to imply that submitting the PR was the
extent of my involvement here. For now I just wanted to get the
testrun to stop dumping core and get the buildbot back to green to
keep on top of new failures, but hope that I (or one of the Linux
people) will have some time to look
I apologize for the breakage. If anyone can help out and try to figure out what
is happening on Linux or FreeBSD, please do help out. I don't have a linux box
and this test should work. The "sync" mode was completely broken prior to this
fix, so it would really help out LLDB in general if we can
On 21 October 2014 13:37, wrote:
>
> the correct thing to do for the nonce is skip the test on Linux and file a PR
> to get to the underlying cause.
I filed llvm.org/pr21325 for TestEvents.EventAPITestCase dumping core
on FreeBSD. I'd suggest just adding a comment that this happens on
Linux as
I don't know what is going on on the Linux side, but r220113 is a patch that
only changed the test case. It really shouldn't be possible to cause a core
dump by driving the SB API's. Plus, what the test is doing is something the SB
API's should support. So I think this change is not in itself
If I revert Greg Clayton's change r220113, then the core dump problem
vanishes.
I also found that running with r220113, but with the invocations of
SetAsync(True) removed, see below:
===
--- test/python_api/event/TestEvents.py (re
Sorry, I forgot to mention, the core dump emanates from the failed
assertion below:
UNSUPPORTED: LLDB (gcc-x86_64) ::
test_add_listener_to_broadcaster_with_dsym (TestEvents.EventAPITestCase)
(requires Darwin)
python:
/home/mg11/src/vendor/llvm/tools/lldb/source/Plugins/Process/POSIX/ProcessPOS
Hi all,
In a build on 64-bit linux from TOT, I'm experiencing the test case
"TestEvents" causing python to segfault.
I believe this to be a fairly recent regression. Anyone else seeing
this/or know what's responsible?
I'm starting to analyse this...
Matt
Member of the CSR plc group of com
