[cfe-dev] llvm::CrashRecoveryContext (in libclang)

[John Sully via cfe-dev]

A multiprocess model is workable for major operations like reparsing but
too much overhead for some of the smaller query type operations that
libclang provides.

In an ideal world clang would never crash and clean up all of its resources
so this wouldn't be necessary. My experience shows its about 99% there if
you don't use the precompiled options.

I have a set of patches that will enable this as an option.  I think
libclang should take them, and support this mode.


On Thursday, October 1, 2015, Vedant Kumar <vsk at apple.com> wrote:

>
>
> > On Sep 27, 2015, at 8:13 PM, John Sully via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >
> > I'm writing a client application that uses libclang and uses it to parse
> documents on multiple threads.  I've been debugging a memory corruption bug
> and traced it to the CrashRecoveryContext destructor deleting other
> thread's Parser objects out from under it.
> >
> > Looking at the CrashRecoveryContext code it appears no effort is made to
> make this thread safe, specifically it heavily relies on static members
> which is how pointers are making their way across threads.
> >
> > There are two questions here:
> > 1) Is libclang intended to be thread safe?  (I.e. would a patch be
> accepted to fix this or is this behavior by design)
>
> I'd be very happy to see patches geared towards making libclang more
> thread safe. There seem to be important use cases for this.
>
>
> > 2) Generally "recovering" from unknown crashes is considered to be bad
> practice, is there a recommended way to prevent use of the crash recovery
> mechanism?
>
> The clang driver uses process isolation. E.g, a monitor process can wait
> on the compile process and emit diagnostics if it crashes. Does that work
> for your project?
>
> vedant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151001/14e70ce7/attachment.html>