|Title||Access violation in gcbench on Windows|
|Assigned user||Gareth Rees|
|Description||See . On platform W3I6MV:|
$ w3i6mv/hot/gcbench.exe -x 1763120249 -a 65536 amc
The MPS detected a problem!
lockw3.c:78: MPS ASSERTION FAILED: lock->claims == 0
|Analysis||When running inside vsjitdebugger, I don’t hit the above assertion, but instead I get an access violation in dylan_scan1 (inside ArenaAccess). Examination of the arena shows that insideShield is false even though ArenaAccess is on the stack and so we should have just call ShieldEnter.|
The bug is still reproducible with /O1 but not with /Od.
The bug doesn't depend on setting the -a option. It is reproducible with:
$ w3i6mv/hot/gcbench.exe -x 1763120249 amc
On platform w3i3mv it can be reproduced with seed 1552443801.
Going back through the history, it seems that gcbench has always been broken on Windows, ever since we ported it in change 185354.
More analysis in       .
Summary: with the /Og /Oy /Ob2 compiler flags, Microsoft Visual C/C++ compiles the function mkvector so that it "encrypts" the only pointer to an object, meaning that it is not recognized by the MPS's scanner, causing the object to die. (The "encryption" involves taking two pointers p and q and replacing q with q-p.) So this is not a bug in the MPS, but a limitation in what conservative garbage collection can do when faced with a sufficiently clever compiler.
|Created by||Gareth Rees|
|Created on||2014-07-01 11:16:04|
|Last modified by||Gareth Rees|
|Last modified on||2016-09-13 10:44:36|
|History||2014-07-01 GDR Created.|