Bug 12200 – Strange crash while debugging in Win64

This code: void main() { Test(); } static void Test() { int[16] step; int depth; step[depth] = 8; ptrdiff_t[9] holds = -1; char s = '['; switch(s) { case '[': // set breakpoint on ++depth ++depth; step[depth] = 24; break; default: break; } } Steps: Compile with DMD-Win64 2.064. Launch in debugger (I'm using VS2010 + VisualD). Notice that program completes successfully. Place a breakpoint on the line '++depth;' Launch in debugger again. Program will pause at the ++depth line. Press F10 (step). Crashes with an access violation. If I remove the line: ptrdiff_t[9] holds = -1; The crash stops happening, even when the breakpoint is present. This is quite strange. Somehow the presence of a breakpoint causes the executing code to crash, and only in the presence of another variable on the stack, which isn't even referenced.

Interestingly, the disassembly's very different in the actual context where I'm experiencing this, but it still happens. The disasm: case '[': ++depth; step[depth] = 24; break; 000007F6D341C19F db ffh 000007F6D341C1A0 test dword ptr [rax+48FFFFFDh],eax 000007F6D341C1A6 movsxd edx,dword ptr [depth] 000007F6D341C1AC cmp rdx,10h 000007F6D341C1B0 mov qword ptr [rbp-368h],rdx 000007F6D341C1B7 jb db@song@Song@LoadDWI@ReadNotes+1DBh (7F6D341C1CBh) 000007F6D341C1B9 mov ecx,429h 000007F6D341C1BE sub rsp,20h 000007F6D341C1C2 call _D2db4song7__arrayZ (7F6D34208E0h) 000007F6D341C1C7 add rsp,20h 000007F6D341C1CB mov rbx,qword ptr [rbp-368h] 000007F6D341C1D2 lea rsi,[step] 000007F6D341C1D9 mov dword ptr [rsi+rbx*4],18h 000007F6D341C1E0 jmp 000007F6D341CA91 Does that test (second instruction) look strange? rax is obviously a pointer, and it's being dereferenced and compared to eax (lower half of itself)? That's the instruction that causes the access violation in my in-context case.

I suspect that the breakpoint is not set at the very beginning of the instruction (or you have another breakpoint there, please check the list of breakpoints). Could you please enable "Show Code bytes" to see where the spurious "db ff" comes from? For me, it looks like this: ++depth; 00007FF6D1B610DF FF 45 A0 inc dword ptr [depth] step[depth] = 24; 00007FF6D1B610E2 48 63 75 A0 movsxd rsi,dword ptr [depth]

Mine looks identical to yours: ++depth; 000007F7FEF0A64F FF 45 A0 inc dword ptr [depth] step[depth] = 24; 000007F7FEF0A652 48 63 75 A0 movsxd rsi,dword ptr [depth] You are experiencing the crash too? Sorry, maybe I was confusing; that large disassembly of mine above was from my code in context (not the reduced code I pasted here with the bug). My reduced code is identical to yours. My original code in the original context looked completely different, although that ff looks sus. What's strange though, is unless the breakpoint is ON that ++depth line, it doesn't crash. Set the breakpoint earlier, like on the switch(), and you'll be able to step straight over it without problem. Although even more weird, if you do break earlier and still have the breakpoint on the ++depth line (even thought it wasn't the breakpoint that halted execution), it will crash. Basically, it freaks out if there is a breakpoint on that line, and works fine in any other case. It doesn't seem to be related to single stepping, cus you can step over no problem as long as the breakpoint's not exactly there :/

(In reply to comment #3) > You are experiencing the crash too? No. Is it possible to reproduce it with the full function alone or does it need other stuff, too? I suspect that the breakpoint is actually set at 000007F6D341C1A0 in your original example changing the instruction ithout stopping there. This could be a bad line number information. Try to delete the pdb file before rebuilding. I remember experiencing problems with stale debug information due to incremental linking. Maybe we need to supply /INCREMENTAL:NO to the linker command line.

Created attachment 1331 test project demonstrating the crash

(In reply to comment #4) > (In reply to comment #3) > > You are experiencing the crash too? > > No. Is it possible to reproduce it with the full function alone or does it need > other stuff, too? Happens in my minimal case (attached). > I suspect that the breakpoint is actually set at 000007F6D341C1A0 in your > original example changing the instruction ithout stopping there. This could be > a bad line number information. This sounds like a good theory. Not sure how to prove/test this. VS doesn't show the byte breakpoints are set. > Try to delete the pdb file before rebuilding. I remember experiencing problems > with stale debug information due to incremental linking. Maybe we need to > supply /INCREMENTAL:NO to the linker command line. No effect.