PCH generated in a different environment crashes application

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

PCH generated in a different environment crashes application

via cfe-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a different environment crashesapplication

via cfe-dev

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: [hidden email]
Sent: 2018. október 9., kedd 17:17
To: [hidden email]
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

[hidden email]

http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a different environment crashes application

via cfe-dev
In reply to this post by via cfe-dev
On Tue, 9 Oct 2018 at 08:17, Geoff Levner via cfe-dev <[hidden email]> wrote:
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.

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?)

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a different environment crashes application

via cfe-dev
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
On Tue, 9 Oct 2018 at 20:56, Richard Smith <[hidden email]> wrote:

>
> On Tue, 9 Oct 2018 at 08:17, Geoff Levner via cfe-dev <[hidden email]> wrote:
>>
>> 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.
>
>
> 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?)
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a different environment crashesapplication

via cfe-dev
In reply to this post by via cfe-dev
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 <[hidden email]> 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: [hidden email]
> 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
>
> [hidden email]
>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a different environmentcrashesapplication

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: [hidden email]
Sent: 2018. október 10., szerda 9:30
To: [hidden email]
Cc: [hidden email]
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 <[hidden email]> 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: [hidden email]

> 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

> 

> [hidden email]

> 

> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

> 

> 

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a differentenvironmentcrashesapplication

via cfe-dev

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: [hidden email]
Sent: 2018. október 10., szerda 11:03
To: [hidden email]
Cc: [hidden email]
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: [hidden email]
Sent: 2018. október 10., szerda 9:30
To: [hidden email]
Cc: [hidden email]
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 <[hidden email]> 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: [hidden email]

> 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

> 

> [hidden email]

> 

> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

> 

> 

 

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a differentenvironmentcrashesapplication

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 <[hidden email]> 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: [hidden email]
> 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: [hidden email]
> Cc: [hidden email]
> 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 <[hidden email]> 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: [hidden email]
>
> > 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
>
> >
>
> > [hidden email]
>
> >
>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> >
>
> >
>
>
>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PCH generated in a different environment crashes application

via cfe-dev
In reply to this post by via cfe-dev
Well I made my own subclass of VerifyPCHAction that sets
AllowConfigurationMismatch to false, but it makes no difference.
On Wed, 10 Oct 2018 at 08:59, Geoff Levner <[hidden email]> wrote:

>
> 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
> On Tue, 9 Oct 2018 at 20:56, Richard Smith <[hidden email]> wrote:
> >
> > On Tue, 9 Oct 2018 at 08:17, Geoff Levner via cfe-dev <[hidden email]> wrote:
> >>
> >> 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.
> >
> >
> > 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?)
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev