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

[Pavel Labath via lldb-dev]

On 8 October 2015 at 17:08, Eugene Birukov  wrote:
> Yes, that's exactly what I see, thanks a lot!
You're wellcome.

>
> Does it explain why I see SIGILL reappear when I let process continue after
> mmap execution? I.e. do I need to look into this more?
No. That could still be a bug somewhere. Feel free to look into it..

pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25123] process detach kills the process (e.g. php)

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25123

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #1 from lab...@google.com ---
This seems to work for me on the master branch. There were some recent changes
in how detach works, which may have fixed this. Could you try building the
master branch and check if you still experience the problem there?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25147] New: remote lldb-XXXXXX.expr temporary files when we are done with them

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25147

Bug ID: 25147
   Summary: remote lldb-XX.expr temporary files when we are
done with them
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

lldb leaves a lldb-*.expr file behind (I think) after every expression
evaluation. These files should be removed when we are done with them. Leaving
those around makes a mess of the /tmp folder and has already stopped our
buildbot from functioning once due to lack of disk space when /tmp filled up.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

There was a bug in how the thread plans that were made for the InferiorCall* 
functions in InferiorCallPOSIX.cpp that would cause the thread plan for running 
the function to get discarded too early.  That was fixed in r250084, you might 
also try that out and see if it fixes your issue.

Jim

> On Oct 8, 2015, at 9:08 AM, Eugene Birukov  wrote:
> 
> Yes, that's exactly what I see, thanks a lot!
> 
> Does it explain why I see SIGILL reappear when I let process continue after 
> mmap execution? I.e. do I need to look into this more?
> 
> Thanks,
> Eugene
> 
> > From: lab...@google.com
> > Date: Thu, 8 Oct 2015 09:13:37 +0100
> > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> > InferiorCallMmap
> > To: eugen...@hotmail.com
> > CC: lldb-dev@lists.llvm.org; jing...@apple.com
> > 
> > Hi,
> > 
> > I believe the SIGILL problem you are referring to is the problem
> > described in bug . This
> > was fixed in r244875, but unfortunately, this was after 3.7 branch so
> > this patch did not make it there. I recommend to try the master
> > branch, I think this should work for you now (and do let me know if
> > the problem persists).
> > 
> > pl
> > 
> > On 8 October 2015 at 00:20, Jim Ingham via lldb-dev
> >  wrote:
> > >
> > >> 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 
> > >> investigation is on me, since I cannot share my program.
> > >>
> > >> But I am not looking at this SIG_ILL yet. Whatever the problem is with 
> > >> mmap - the client must not carry this signal past expression evaluation. 
> > >> I.e. I believe that we can construct any arbitrary function that causes 
> > >> signal, call it from evaluate expression, and then continue would fail. 
> > >> I suspect that this problem might be applicable to any POSIX platform.
> > >
> > > It doesn't happen on OS X, though when it comes to signal handling in the 
> > > debugger OS X is an odd fish...
> > >
> > >>
> > >> As it turned out, my initial analysis was incorrect. m_resume_signal is 
> > >> calculated from StopInfo::m_value (now I wonder why do we need two 
> > >> fields for that?).
> > >
> > > The signal that you stop with is not necessarily the one you are going to 
> > > resume with. For instance, if you use "process handle SIG_SOMESIG -p 0" 
> > > to tell lldb not to propagate the signal, then the resume signal will be 
> > > nothing, even though the stop signal is SIG_SOMESIG.
> > >
> > >> And after mmap call, m_stop_info on the thread is null. So, my current 
> > >> theory is that there is an event with SIG_ILL that is stuck in the 
> > >> broadcaster and is picked up and processed much later.
> > >
> > > When the expression evaluation completes, the StopInfo from the last 
> > > "natural" stop should be put back in place in the thread. After all, if 
> > > you hit a breakpoint, run an expression, then ask why that thread 
> > > stopped, you want to see "hit a breakpoint" not "ran a function call". 
> > > Sounds like that is failing somehow.
> > >
> > > Jim
> > >
> > >
> > >>
> > >> > Subject: Re: [lldb-dev] Thread resumes with stale signal after 
> > >> > executing InferiorCallMmap
> > >> > From: jing...@apple.com
> > >> > Date: Wed, 7 Oct 2015 15:08:18 -0700
> > >> > CC: lldb-dev@lists.llvm.org
> > >> > To: eugen...@hotmail.com
> > >> >
> > >> > Does it only happen for InferiorCallMmap, or does an expression 
> > >> > evaluation that crashes in general set a bad signal on resume? I don't 
> > >> > see this behavior in either case on OS X, so it may be something in 
> > >> > the Linux support. Be interesting to figure out why it behaves this 
> > >> > way on Linux, so whatever we do we're implementing it consistently.
> > >> >
> > >> > Jim
> > >> >
> > >> >
> > >> >
> > >> > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev 
> > >> > >  wrote:
> > >> > >
> > >> > > 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 second one.
> > >> > >
> > >> > > • EvaluateExpression() calls Process::CanJIT() which in turn 
> > >> > > executes mmap() on the inferior. This mmap gets SIG_ILL because 
> > >> > > execution starts at address which is 2 bytes before the very first 
> > >> > > mmap instruction. I am still looking why LLDB server decided to do 
> > >> > > that - I am pretty sure that the client asked to set the program 
> > >> > > counter to correct value.
> > >> > > • So, the thread execution terminates and the signal is recorded on 
> 

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

[Eugene Birukov via lldb-dev]

I tried to repro it using standard LLDB client on a simple program that I could 
share. Well, the problem does not exactly repro as in my case - i.e. the signal 
is not re-delivered to the thread. But LLDB does get confused state: the 
program continues but at the same time lldb shows its prompt as if the program 
were stopped. I.e. the recovery from signal during expression evaluation is 
buggy. Sorry, I am not sure that I will have time to look into it deeper - it 
is not a blocker for me at this time.

> From: lab...@google.com
> Date: Mon, 12 Oct 2015 13:25:45 +0100
> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> InferiorCallMmap
> To: eugen...@hotmail.com
> CC: lldb-dev@lists.llvm.org; jing...@apple.com
> 
> On 8 October 2015 at 17:08, Eugene Birukov  wrote:
> > Yes, that's exactly what I see, thanks a lot!
> You're wellcome.
> 
> >
> > Does it explain why I see SIGILL reappear when I let process continue after
> > mmap execution? I.e. do I need to look into this more?
> No. That could still be a bug somewhere. Feel free to look into it..
> 
> pl
  ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] FYI, there is an RFC for an LLVM Community Code of Conduct

[Chandler Carruth via lldb-dev]

Please see the llvm-dev thread here and direct all discussion there:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python 3 and dotest

[Zachary Turner via lldb-dev]

Moving this to the public list because it seems useful to see what other
members of the community have to say as well.

On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner  wrote:

> It's worth also pointing out that if we go the route of supporting both
> then everyone running the test suite will need to test their changes with
> both Python 2 and Python 3 anyway.  For testing LLDB on different OSes we
> don't really require this because not everyone has access to different
> hardware so we can't mandate that they test their patches on every
> supported hardware configuration.  But realistically speaking, everyone has
> access to Python 2.x and Python 3.x, so the burden should be on the person
> submitting patches to ensure that it runs on both.
>
>
> On Mon, Oct 12, 2015 at 3:24 PM Todd Fiala  wrote:
>
>> On Mon, Oct 12, 2015 at 3:14 PM, Zachary Turner 
>> wrote:
>>
>>> Is installing python 3 not as simple as just running a package manager
>>> and selecting python 3?  I didn't think anyone would need to be building
>>> their own, but I don't know how it works in the OSX world.
>>>
>>
>> I may fiddle with this on my off time just to see.  OS X has some pathing
>> mechanisms (like user-directory Library, plain Library, and system Library
>> directory, I think they may call them domains) that stack.  So if something
>> (like a python) installs a python framework in /Library, it can hide
>> /System/Library.  Same with $HOME/Library vs. /Library and /System/Library,
>> IIRC.  (Greg can correct me or I'll double check later).  So it is quite
>> possible that installing a new python just essentially hides the other one.
>>
>> I kinda need to see what happens though to know the real point of
>> conflict.
>>
>
Currently LLDB won't compile when using Python 3 headers.  I've fixed most
of the issues, but there are two remaining.  First is that FILE* APIs have
been removed in Python 3, and second is that some of the SWIG files use
functions like PyString_FromStringAndSize which is also removed in Python
3).  Once I fix those and get those committed, you should be able to test
on OSX and let me know what issues you run into.



>
>>
>>>
>>> I'm only really talking about requiring python 3 for running dotest,
>>> which is not something that many people do, so it doesn't seem like that
>>> big of a burden.
>>>
>>> The thing I'm concerned about it is that it's going to be a bigger
>>> burden for everyone, including Apple, if we *don't* do this.  I mean time
>>> will tell, obviously, but I don't expect this to be painless.  And it's
>>> goign to be the type of pain that doesn't go away over time, either, it's
>>> going to reoccur every time someone checks something in to the test suite.
>>> All that time is going to add up over the long run and be worse than taking
>>> the initial hit of installing python 3 on the internal build systems.
>>>
>>> There's also the issue that Todd was saying he could make some
>>> improvements to the test suite if it could use Python 3, but I'll defer to
>>> him for that since I don't know the details.
>>>
>>>
>> The async IO handling (via asyncore) would be easier to write in a
>> platform-neutral way with Python 3.5.  (Might be Python 3.3 but I seem to
>> recall they really went gung-ho on the Windows/POSIX parity side in 3.5).
>> That would benefit.  There are a few other minor places where we do things
>> to avoid incompatibility with Windows, or do something slightly more
>> awkward because we don't have a good answer on Windows.  (Depending on
>> subprocess.Popen.communicate() is one example - that could be replaced with
>> asyncore if we had Windows file handle support there).  Probably the bigger
>> benefit is almost all new work and newer ideas are getting implemented in
>> Python 3.x, where Python 2.x is just getting security fixes.  To the extent
>> that we care about that for the test suite, that's what we're missing out
>> on.
>>
>> -Todd
>>
>>
>>> On Mon, Oct 12, 2015 at 1:33 PM Greg Clayton  wrote:
>>>

 > On Oct 12, 2015, at 10:41 AM, Zachary Turner 
 wrote:
 >
 > Hi Greg,
 >
 > I talked with Todd a little bit about this while you were on
 vacation, but now that you're back I want to ask you as well.
 >
 > Is it possile to require Python 3 just for running the test suite?
 You can see from my previous patch that gets `ScriptInterpreterPython`
 ready for Python 3 that I did it in a way such that LLDB will support both
 Python 2 and Python 3, so I don't intend to change that.  But probably
 sometime this week I'm going to start poking at dotest.  There's a lot of
 code in there, and I expect it's goign to be a challenge to support both
 Python 2 and Python 3.  Not only just in terms of writing the code in a way
 that the version specific differences are cleanly expressed, but also in
 terms of being able to actually maintain the code so that nobody breaks
 anyone else when they make changes to the test runn