- This topic has 39 replies, 2 voices, and was last updated 6 years, 8 months ago by
.
-
Posts
-
Also before the Intellisense engine crashed, all the popup suggestions were bogus, it looked like a raw dump of every symbol it knew (some namespace aliases we have set up, like “A”, “AA”, “AB”, “AC”, etc.)
Hi,
Sorry, all we can see from the minidump is that the memory gets corrupt to a point when execution jumps to random addresses, hence it is not possible to pinpoint the problem from the dump alone.
In order for us to pinpoint it, we would need to have a project on our side that causes the crash. Another alternative would be to try identifying the exact sequence of steps that leads to the crash so that we could check the differences between v5.2 and v5.3 related to that steps.
E.g. does the crash happen if you don’t use the “Find all references” and “Go to definition” commands? If yes, what would happen if you remove ALL source files except the one that causes the crash from the project and remove the CodeDB folder? Does the crash still happen?
Here’s what I can tell you as of right now:
- I don’t often use “go to definition” or “find all references”. It repro’s without using either of those.
- I haven’t tried making a solution with just those files yet.
- Before preview 5, I saw the crash about one second after opening the problematic file. In preview 5, I didn’t see it after the opening file, but after triggering an AutoComplete with “.” or “->”, all the suggestions would be nonsense (things like #defines, namespace aliases, and enum’s would just randomly appear). Then a few seconds after that, it would crash.
- I just downloaded preview 6 (build 1724) which was just released a few hours ago. Crash still occurs *but* typing “this->” doesn’t trigger it any more, I have to trigger off of function scoped variables. I will upload another mini dump just in case it helps.
Hi,
The Clang engine is actually unchanged since Preview 3, so if you are experiencing different behavior, most likely it’s caused by the intermittent nature of the bug. What we usually do internally when investigating intermittent issues is try repeating the same operation 10 times and, how many times this leads to a certain outcome and then compare this number between different setups. We understand this is annoying, however as this bug looks to be specific to your codebase, we cannot offer much other help unless we could reproduce it on our side.
We would advise narrowing down the scope:
- Reduce the solution to just 1 source file (e.g. make a backup of the .vxcproj file and manually remove other <ClCompile> statements from it). Don’t forget to delete the CodeDB folder.
- If the problem still persists, this is very good as it’s most likely not caused by race conditions in the multi-threaded parser and could be isolated. In that case please try reprocessing the file by enabling “Generate preprocessor output” in the file properties and then replacing the original .cpp file with the preprocessed file (it will have all the #include<> statements expanded). Can the problem be still reproduced on a preprocessed file?
I reduced my project to just one ClCompile entry containing the problematic file: crashed. Also replaced this file with a preprocessed version of itself (using the -E argument to clang++) — still crashed. In both cases, WinDbg reliably reports:
ID: [0n261] Type: [STACK_BUFFER_OVERRUN] Class: Addendum Scope: BUCKET_ID Name: Add Data: Omit PID: [Unspecified] TID: [0x3e70] Frame: [0] : CppEngineCore64!DumpSharedPCHIndex BUGCHECK_STR: APPLICATION_FAULT_STACK_BUFFER_OVERRUN_NOSOS_FTH_ACTIVE_BOGUSADDRESS_XMULTI_MISSING_GSFRAME DEFAULT_BUCKET_ID: STACK_BUFFER_OVERRUN_NOSOS_FTH_ACTIVE_BOGUSADDRESS_XMULTI_MISSING_GSFRAME ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
Is any of this meaningful?
Meant to add: in all cases I deleted CodeDB, the .db file, etc.
Hi,
We might have been able to pinpoint and fix this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.6.1733.msi
Hello,
Thank you so much for posting this. I am continuing my testing but so far everything looks good. No crashes yet. Fingers crossed!
- You must be logged in to reply to this topic.