[cfe-dev] PCH generated in a differentenvironmentcrashesapplication

[Geoff Levner via cfe-dev]

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
On Wed, 10 Oct 2018 at 11:06, Whisperity <whisperity at gmail.com> wrote:
>
> Sorry, the previous message was accidentally sent, I’m still getting used to touchscreens :(
>
>
>
> 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.
>
>
>
> From: Whisperity
> Sent: 2018. október 10., szerda 11:03
> To: Geoff Levner
> Cc: cfe-dev at lists.llvm.org
> Subject: RE: [cfe-dev] PCH generated in a differentenvironmentcrashesapplication
>
>
>
> 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
>
> >
>
> >
>
>
>
>