www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12200] New: Strange crash while debugging in Win64

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200

           Summary: Strange crash while debugging in Win64
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: turkeyman gmail.com


--- Comment #0 from Manu <turkeyman gmail.com> 2014-02-18 21:14:51 PST ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200



--- Comment #1 from Manu <turkeyman gmail.com> 2014-02-18 21:22:19 PST ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200


Rainer Schuetze <r.sagitario gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario gmx.de


--- Comment #2 from Rainer Schuetze <r.sagitario gmx.de> 2014-02-18 23:53:43
PST ---
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]

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200



--- Comment #3 from Manu <turkeyman gmail.com> 2014-02-19 05:47:35 PST ---
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 :/

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 19 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200



--- Comment #4 from Rainer Schuetze <r.sagitario gmx.de> 2014-02-19 14:25:58
PST ---
(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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 19 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200



--- Comment #5 from Manu <turkeyman gmail.com> 2014-02-19 17:31:37 PST ---
Created an attachment (id=1331)
test project demonstrating the crash

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 19 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12200



--- Comment #6 from Manu <turkeyman gmail.com> 2014-02-19 17:33:22 PST ---
(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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 19 2014