Adding a printing destructor to threading.Event seems to aggravate timing
problems, causing several tests to fail to make their inferiors and that
seemingly keeps us below the open file limit. That aside, the destructor
did fire many hundreds of times, so there's not a general problem stopping
Even on Linux call to InferiorCallMmap does not fail consistently. In many
cases it survives. I just happened to have 100% repro on this specific
breakpoint in my specific problem. I.e. the burden of investigation is on me,
since I cannot share my program.
But I am not looking at this SIG_ILL
> On Oct 7, 2015, at 4:06 PM, Eugene Birukov wrote:
>
> Even on Linux call to InferiorCallMmap does not fail consistently. In many
> cases it survives. I just happened to have 100% repro on this specific
> breakpoint in my specific problem. I.e. the burden of
Hi,
I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint and if
I call SBFrame::EvaluateExpression() there, when I let it go it terminates with
SIG_ILL on an innocent thread. I dug up into this, and there seems to be two
independent problems there, this mail is about the