[cfe-dev] PCH generated in a different environmentcrashesapplication

[Whisperity via cfe-dev]

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.
- 

From: Geoff Levner
Sent: 2018. október 10., szerda 9:30
To: whisperity at gmail.com
Cc: cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] PCH generated in a different environmentcrashesapplication

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

On Tue, 9 Oct 2018 at 20:49, Whisperity <whisperity at gmail.com> wrote:
>
> 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.
>
>
>
> From: Geoff Levner via cfe-dev
> Sent: 2018. október 9., kedd 17:17
> To: cfe-dev at lists.llvm.org
> Subject: [cfe-dev] PCH generated in a different environment crashesapplication
>
>
>
> 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.
>
> _______________________________________________
>
> cfe-dev mailing list
>
> cfe-dev at lists.llvm.org
>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181010/baa502c6/attachment.html>