[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

Mon Sep 11 16:32:07 PDT 2017

> On Sep 11, 2017, at 4:05 PM, Leonard Mosescu via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> 
> Process already has "Error Process::WillResume()" for this very reason. Just have the Windows mini dump core file plug-in override it. The code in Process::Resume already checks this:
> Status Process::PrivateResume() {
>   Status error(WillResume());
>   // Tell the process it is about to resume before the thread list
>   if (error.Success()) {
>       ...
>     }
>   }
>   return error;
> }
> Problem solved no???
> 
> It would be great, but that also happens too late (by the time PrivateResume() is called the state has been already changed)
> 
> lldb command interruption requires two parts, one is the rollback, and the other is to have someone listening for interruption.  To give an instance that works in lldb today, if you run the "expr" command, while we are in the process of compiling there's no way to interrupt "expr" because clang doesn't listen for interrupts.  But once the expression is running, we're back in the lldb event loop and so we can handle interruption.  And of course if you interrupt an expression while running it knows how to clean up after itself.  That wasn't done for interruption primarily, rather "expr" already had to know that to be able to clean up from expressions that crashed or raised signals while running.
> 
> I don't think we need a general "interrupt me anywhere you want" mechanism to support command interruption however.  Most of the time-consuming work in lldb comes in self-contained chunks (reading in symbols from shared libraries, reading in the debug info index tables, etc) or happens while lldb is actually waiting for something to happen (that part already is interruptible at a low level).  We try to do work as lazily as possible, so if the chunk boundaries and the lazy work boundaries line up you won't really need to roll-back at all.   The model where you check for interrupts after each chunk of work is done will I think be responsive enough for user's needs, and also greatly simplify the work to handle interruption.  This is a little more manual, since you have to insert appropriate "yields", but I think will be good enough for our purposes and much easier to make stable.
>  
> @Jim: I think we're thinking along the same lines, something intended for the poor soul who's does something like "target modules dump symtab", rather than the ability to interrupt at any arbitrary point (which as you point out it's not really feasible).

Exactly.  The ^C in the driver is currently wired up to SBDebugger::DispatchInputInterrupt().  All that does at present is see if any targets under the debugger have running processes, and interrupt them.  That could be extended to do more general interrupting.  But I haven't taken any time to think of a good strategy for implementing that.

Jim

>  
> 
> On Mon, Sep 11, 2017 at 3:43 PM, Greg Clayton via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
>> On Sep 11, 2017, at 3:37 PM, Zachary Turner <zturner at google.com> wrote:
>> 
>> On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <lldb-commits at lists.llvm.org> wrote:
>> I know there are two points of view here so I will give my two cents:
>> 
>> If it comes down to something as easy as "always check for NULL before doing something", or something that is similar and very easy, I would say just code around it. Don't "assert(...)" or "llvm_unreachable(...)". Things that fall into this category: switch statements with defaults that might catch things, checking var/ivar for NULL, seeing if a collection is empty, bounds checking things.
>> 
>> One example here is LLDB has its own object file readers for mach-o and ELF. Mach-o has load commands in the file header and each load command has a "cmd" uint32_t whose value is an enum. It is followed by a uint32_t "length" of this data. The LLVM version of the mach-o file parser, a while back before changes were made, wanted to assert or llvm_unreachable for any load command that it didn't recognize. This kind of thing can't happen in a debugger.
>> 
>> Right, but that's user input.  On the other hand, suppose LLDB manually constructs some IR that it passes to the interpreter.  Since LLDB is in full control of the IR it generates, it can safely assert that the interpreter was successful at interpreting it.
> 
> Like when you run an expression, it generated some relocation that the JIT doesn't handle and it crashes??? We ran into this a few times. So I don't agree that anything in the expression stack is not subject to these rules. It is something we should fix and we should not crash. So while unexpected things are harder to handle, I still say we should recover if at all possible and we ran into the relocations stuff not being handles many times over the years. We don't control user input that is in the expression.
> 
> If you are a shared library, you shouldn't crash if you can help it. If you are an executable, do what you want and feel free to crash yourself. We took LLDB out of process in Xcode so we could load unsigned code from Swift nightly builds, and another benefit was it didn't crash Xcode when things went wrong in LLDB. 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits