[cfe-dev] [libTooling] Is a CodeGenAction safe to use with a libTooling Executor?

[Paul Kirth via cfe-dev]

I've been prototyping a standalone tool that uses libTooling's executor
(specifically the AllTUs executor) to run over a compile_commands.json.

My diagnostics come from the LLVM backend, so using a CodeGenAction seems
like it should be the right choice, however I'm running into a number of
memory corruption bugs that don't seem to be present either in my code or
in other clang tools. I suspect this is due to my use of the LLVM backend
with the executor's thread pool.

Running under TSAN shows a number of races occurring after the executor
starts, some occur within libTooling, some inside LLVM passes. These races
span a number of  data types, most commonly strings, vectors, and streams.
I'm fairly confident that the memory corruption stems from these data races.

Other frontend actions don't seem to suffer this issue, and I don't see
anything in the executor documentation restricting it from being used with
a CodeGenAction.

Is this a known issue? or is this the intended design of the executors?

Ideally I would like to be able to take advantage of any concurrency
available, but right now that seems like it won't be possible without some
significant changes to either libTooling or the LLVM backend.

Thoughts or suggestions on how to best proceed with this are appreciated.

-- 
Paul Kirth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190905/555d412c/attachment.html>