Re: [lldb-dev] Too many open files

2015-10-07 Thread Adrian McCarthy via lldb-dev
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

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-07 Thread Eugene Birukov via lldb-dev
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

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-07 Thread Jim Ingham via lldb-dev
> 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

[lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

2015-10-07 Thread Eugene Birukov via lldb-dev
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