[Lldb-commits] [PATCH] D18646: Fix DWO breakage in r264909

Thu Mar 31 11:51:53 PDT 2016

This assert isn't checking for the correctness of the debug info (what is a
program input). It is checking that we passed the DIERef to the correct
SymbolFileDWARFDwo instance what is the contract of the API and should be
checked by an assert. This assert will only fire if we have a bug in LLDB
regarding the usage of SymbolFileDWARFDwo what have to be fixed.

I think most people here just want to get rid of all assert in their
production builds what is perfectly reasonable but it can be done by
disabling asserts what is the only right way considering clang and llvm
contain a lot of them.

On Thu, Mar 31, 2016 at 7:24 PM Jim Ingham via lldb-commits <
lldb-commits at lists.llvm.org> wrote:

> Moving lldb out of process is a worthy effort, but it is only a partial
> solution.  We do a lot of things on the users behalf, and if one of these
> crashes without really giving the user insight into how to avoid the crash,
> while it's great that we didn't also lose some editing changes they had in
> another project open in the IDE at the same time, they still can't debug
> their app...  They might be able to dance around the crash next time
> around, till they can't...  In general, you should only full on assert if
> you absolutely can't recover.  And if you absolutely can't recover, it's
> worth the time to think about whether you could recover if you architected
> the code a little differently.
>
> But in the case of debug information, you should always be able to fall
> back to "no debug info for this CU" if you get in a really bad way.
>
> Jim
>
> > On Mar 31, 2016, at 11:15 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > I think it depends on how bad the thing that happens is.  If you are out
> of memory, sure you can assert.  If a syscall fails that is supposed to
> never fail, you can assert.  But if one piece of debug info appears
> corrupt, I don't think it's worth bringing down the whole process, which
> could be an entire IDE.  (FWIW yes I agree that having LLDB out of process
> would be an even better solution to this, but that's quite a large
> undertaking).  You could be debugging other processes using other debug
> info which is not corrupt, but you terminate all those sessions because one
> piece of unrelated debug info in an unrelated process is bad.  Doesn't seem
> right to me.
> >
> > debug info is program input, and you would never assert on program
> input, you have to be able to handle unreasonable values gracefully.
> >
> > On Thu, Mar 31, 2016 at 11:06 AM Jim Ingham via lldb-commits <
> lldb-commits at lists.llvm.org> wrote:
> > jingham added a subscriber: jingham.
> > jingham added a comment.
> >
> > I don't agree that asserts are good in released code unless you have no
> way of backing out of the situation you find yourself in.  After all, you
> are saying to some unlucky user out there that they can't use the debugger
> on their app and in general there's nothing they can do about it.  Greg's
> suggestion is for this low-level API to say "I couldn't find this DIE" and
> then if that's something higher layers can work around - by saying "Yeah I
> couldn't find that type" then you've allowed the user to continue their
> debug session instead of stopping them cold.
> >
> > Not asserting prematurely is particularly important for handling debug
> information; since we don't control the compiler we need to handle as much
> junk information as gracefully as possible.
> >
> > Also, asserts, especially for debug information, don't tend to be very
> helpful in the field.  You get a crash trace which really doesn't tell you
> the important stuff - what debug file was this, what DIE was bad, etc...
> And given the nature of life, this error is going to occur for a user who
> can't give you their project to repro the bug and can't reduce it to a
> smaller test case.  Logs are pretty much all you have to go on.  So an
> un-annotated assert like this is not a good idea.
> >
> > So orthogonal to the assert issue, if you find something not copacetic
> in the debug information, you should log out as much local information as
> you can regardless of what you are going to do with the error.
> >
> > Jim
> >
> >
> > Repository:
> >   rL LLVM
> >
> > http://reviews.llvm.org/D18646
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160331/bdb9b9fc/attachment.html>