<div dir="ltr">I've been prototyping a standalone tool that uses libTooling's executor (specifically the AllTUs executor) to run over a compile_commands.json. <div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Is this a known issue? or is this the intended design of the executors? </div><div><br></div><div>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.</div><div><br></div><div>Thoughts or suggestions on how to best proceed with this are appreciated.</div><div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Paul Kirth</div></div></div></div>