Bug 6236 – Subtle bug with Windows timer, hashes and imports

Status
RESOLVED
Resolution
WORKSFORME
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
Windows
Creation time
2011-07-01T16:01:00Z
Last change time
2012-02-17T23:33:54Z
Assigned to
nobody
Creator
andrej.mitrovich

Comments

Comment #0 by andrej.mitrovich — 2011-07-01T16:01:12Z
!!PLEASE BE CAREFUL!! I've tested this on my own system, and it just crashes the app. But I've also tested it in a VirtualBox on Win7 and it completely froze the system. This is the smallest test case I could make, you'll have to download it from: https://github.com/AndrejMitrovic/temporary/tree/master/hashbug Extract the hashbug folder, build the app with build.bat, and then keep resizing the window for a few seconds. In just a couple of seconds there's a crash with: --------------------------- hashbug.exe - Application Error --------------------------- The instruction at "0x00403b39" referenced memory at "0x0000000c". The memory could not be "read". --------------------------- First of all, it doesn't matter that there's no WinMain function here, WinMain is just a convention and the bug can be recreated with a WinMain function as well. If you comment out "import std.utf;" the bug disappears, even though std.utf is never used in the module. If you change the static hash in BugCallback with a globally shared one "__gshared int[int] hash;" outside the function then the bug seems to go away. If you replace the line "static int[1] arr = [1];" in BugCallback with "static int[1] arr = [0];", then the crash only happens when exiting. If you comment out "hash[arr[0]] = 0;" in BugCallback, the bug disappears. If you replace that line with "hash[0] = 0;", then the crash only happens when exiting. If you comment out the line "foo ~= 1;" in a completely different function "BugFunction" that runs in another thread, the bug disappears. That function keeps expanding an array, but it doesn't cause a stackoverflow or anything. DDBG shows this: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at __aaGetX (0x00403b39) thread(2728) aaGetX looks like a Hash function from Druntime. So my guess is the hash does something that doesn't work quite well with the Windows timer.
Comment #1 by andrej.mitrovich — 2012-02-17T23:33:54Z
I can't reproduce it anymore, even with the older 2.053. If/When I have a reduced test case I'll open a new report.