PCH generated in a different environment crashes application

We have an application that uses Clang and an Orc-based JIT to compile
and run C++ code on the fly. To speed up compilation, the application
generates a .h file that includes all the required header files, then
precompiles it to a PCH file. So if the code changes afterward, but
the includes don't, the PCH file can be reused.

That works fine when I work on my own. But if another user on another
machine generates the PCH file, the application crashes, both for me
and for the other user, as soon as the compiled function is invoked. I
haven't been able to determine yet what difference in the other user's
environment might cause the problem.

Does anybody on this list have any idea why a PCH file generated by
another user with exactly the same command line might cause a crash?

I don't know if it's relevant, but the application is compiled with
clang/llvm 7.0.0. It uses a GeneratePCHAction to generate the PCH
file, and it uses a VerifyPCHAction if the PCH file already exists.
The VerifyPCHAction succeeds, in this case, but the compiled function
still crashes.

I don’t think PCHs were ever meant to be “transferable” between machines. Something rings a bell that even moving a PCH generated by one compiler to another (version of the) compiler is also unsupported. If the environment changes (to which it is not only compiler invocation should be considered but also “many other things”) then the PCH is by virtue outdated and must be remade…

A stack trace and a debug build would be good to look at to see exactly what goes sideways.

Do you mean that you get a PCH from another user and use it in your compilation to do some things on it? I think unless the other user’s environment is bit-by-bit the same it will be tricky to hunt down…

Does it work if the other user does everything from scratch on their own machine?

It might be that the PCH misses something after having been loaded, or the resulting AST is bogus somewhere in the middle of it, and you run into a hole. Is this crash a simple SIGSEGV or something more detailed? Perhaps an assertion message, which is emitted to the output?

; W.

VerifyPCHAction specifies AllowConfigurationMismatch = true, so it doesn’t provide a full check that the PCH is actually usable. Do you also set AllowConfigurationMismatch or DisablieValidation to true when creating the ASTReader to load the PCH file? (How are you loading it? If via code, what are you calling and what arguments are you passing, and if via the clang driver, what flags are you using?)

Hi Richard,

I don't create an ASTReader, I just use the clang driver with the
following arguments:

   dg2
   -x
   c++
   <PCH file name>
   -fsyntax-only
   -fno-caret-diagnostics
   -resource-dir
   <clang resource dir>
   -std=c++11
   -O3
   -Wall
   -Wextra
   -Wpedantic
   -fPIC

(The first argument is the name of our application, I assume it makes
no difference.) Is there an argument corresponding to
AllowConfigurationMismatch?

Thanks,
Geoff

Hi W,

I just try to use the PCH generated by the other user to compile the
source code, using -include.

It does indeed work correctly if the other user starts from scratch,
meaning: delete the PCH file and previously generated bitcode files. I
should explain that the JIT contains other modules whose bitcode was
saved and then reloaded using parseBitCodeFile(). So apparently the
problem arises when mixing modules compiled from bitcode generated by
one user, with a module compiled using a PCH file generated by another
user. Although I don't see why... Perhaps there is a difference
between standard include files on the two machines, but there
shouldn't be, because both have the same version of gcc installed.

I did use a debug build. What happens when the application crashes is
that a segmentation fault is triggered as soon as the compiled
function is invoked. No assert or messages or any other useful
information, and the call stack is obliterated...

Thanks,
Geoff

By all means, suspicious. I’m still kinda leaning on the cane which screams moving PCH between “environments” botches them.

Here is what you could do if you have a few hours to tinker this:

  • First of all, make sure that Clang and your own tool is compiled from scratch, in Debug (or RelWithDebInfo, although I like Debug more). It will take some space on the disk but it is worth it.

Sorry, the previous message was accidentally sent, I’m still getting used to touchscreens :frowning:

  • So after compiling clang and your tool in Debug, start the usual workfrom from within a debugger.
  • The easiest way to do this is ’gdb --args my-fancy-tool –their-arguments bla bla bla’.
  • In gdb you hit ’r’ to run the process. It will hopefully run into the segfault, but you now will have a stack trace.

Another question just to hold all angles: does the crash also happen if you don’t use your tool just try a normal compilation with Clang, but using „mixed” PCHs from two separate users?

; Whisperity.

Yes, llvm/clang is compiled from scratch; release or debug makes no difference.

I did inspect with gdb. As soon as I step into the function compiled
by the JIT (with -g), a segmentation fault is triggered and the call
stack is obliterated.

I will try testing outside the application, that's a good idea. But it
may take some time...

Thanks again,
Geoff

Well I made my own subclass of VerifyPCHAction that sets
AllowConfigurationMismatch to false, but it makes no difference.