Possible bug in stack walking for win32/x64. about bdwgc

[corngood]

My patch (for an old version of mono adds this to GC_push_all_stacks:

      if (thread -> id == thread_id) {
#if defined(X86_64)
        CONTEXT context;
        RtlCaptureContext(&context);
        // push non-volatile registers only (excl. rsp)
        PUSH4(Rbx, Rbp, Rdi, Rsi), PUSH4(R12, R13, R14, R15);
#endif
        sp = (ptr_t) &dummy;

It would probably better to write an asm proc to do this, but this was my quick and dirty solution. I believe something similar should be done in the pthread implementation (probably with another separate asm proc for the linux/bsd ABI.) It looks like this problem theoretically exists on x86 as well, but the lack of registers probably makes it impossible to reproduce in a test.

[corngood]

After digging a bit more, I found GC_generic_push_regs, which is clearly where the registers are meant to be marked. The problem is that it's only adding them to the mark stack and then returning, which causes the stack to be wiped (either by debug code or overwritten by other calls) before it gets marked. It ends up having no effect.

[joncham]

So, I see GC_generic_push_regs cause registers to be pushed onto the thread stack; on Win32 this is done by calling setjmp with a stack allocated jmp_buf, causing the register contents to then be on the stack. It then calls the callback function of GC_push_current_stack. In the case of THREADS being defined it should then call GC_push_all_eager.

https://github.com/Unity-Technologies/mono/blob/unity-staging/libgc/mark_rts.c#L497

GC_push_all_eager should push/copy the potential pointer values from the thread stack onto the mark stack immediately.

[corngood]

I'm hitting the non eager push right above there (stack growing down.)

On Sep 9, 2014, at 12:35 AM, "Jonathan Chambers" [email protected] wrote:

So, I see GC_generic_push_regs cause registers to be pushed onto the thread stack; on Win32 this is done by calling setjmp with a stack allocated jmp_buf, causing the register contents to then be on the stack. It then calls the callback function of GC_push_current_stack. In the case of THREADS being defined it should then call GC_push_all_eager.

https://github.com/Unity-Technologies/mono/blob/unity-staging/libgc/mark_rts.c#L497

GC_push_all_eager should push/copy the potential pointer values from the thread stack onto the mark stack immediately.

—
Reply to this email directly or view it on GitHub.

[joncham]

Okay, so that at least explains the behavior. Upstream has GC_push_all_eager for both cases,

https://github.com/ivmai/bdwgc/blob/master/mark_rts.c#L664

Our version changed this for some reason. I'll track down why and revert the change. This issue can be closed as it doesn't apply to upstream IMO.

[corngood]

I'll revert Unity-Technologies/mono@0ded310 locally to fix this.

Thanks