- This topic has 4 replies, 2 voices, and was last updated 1 year, 7 months ago by
.
-
Posts
-
Getting a repeated crash when including a header file from a component in an ESP IDF project. Every time the parser is invoked it locks up which is fairly often
Unhandled exception at 0x00007FFF05B82345 (CppEngineCore64.dll) in CppEngineHost64.exe: 0xC0000005: Access violation reading location 0x0000000000000024.
Found a similar issue with this post
A debug build would be appreciated, I can also send the project. I tried including the same header in another project and that alone was not enough to reproduce the issue.
Hi,
Normally VisualGDB should automatically create a dump file containing sufficient information for us to pinpoint the issue. If this doesn’t happen, please try attaching another VS instance to the CppEngineHost64.exe process (make sure you explicitly select the Native mode), wait for the crash to happen and then create a dump file via the Debug->Save Dump command.
You can attach the dump file here, or simply submit it to us via the support interface and we will try to find the root cause of the issue and release a hotfix.
The dump files were too large to attach here so I sent them to the support email. One has heap information one does not.
I didn’t dig too much into it but I believe the library would’ve been too much work to integrate into my version of ESP IDF. I went another route that’s working for me now so this specific issue isn’t hindering me at all.
Thanks, we have received and reviewed the dump file. The crash happens because Clang considers one of the headers it’s precompiling to contain a typo preventing the normal parsing, and it apparently triggers a “not implemented” condition when trying to produce the precompiled header data.
You can work around it by adding a non-preprocessor statement (e.g. ‘static int unused=0;’) at the beginning of the file to suppress the precompiled header generation. Then you can try moving the statement between the #include<> directives until you find the one that is triggering the issue. Having that include directive after the non-preprocessor statement will prevent Clang from trying to precompile that header file, working around the crash.
- You must be logged in to reply to this topic.