made windows stack traces 10 times faster #638

Ingrater · 2013-10-14T09:27:23Z

This change makes the tracing part of stack tracing on windows about 10 times faster. This will especially impact throwing exceptions, which will be a lot faster now.

MartinNowak · 2013-10-14T10:11:07Z

src/core/sys/windows/stacktrace.d

+                    return result;
+                }
+            }
+        }



Why do we still need the old stack trace code then?

Because:

RtlCaptureStackBackTrace does not work when given a exception context

RtlCaptureStackBackTrace does not use the debug information to resolve stack frames (only works when all functions have frame pointers)

RtlCaptureStackBackTrace has a limit of 63 stack frames it can walk

So for these three cases the old code is still needed.

Would be nice to add this explanation as a comment in the code!

It's briefly mentioned in the sources, but I agree a more thorough explanation in the sources or in the commit message would be nicer.

Would be nice to add this explanation as a comment in the code!

So whats the preffered action now? Should a create a new pull request or can I commit into this one?

If you want to improve the comment please open a new pull request and reference this one.

MartinNowak · 2013-10-14T10:51:03Z

src/core/sys/windows/stacktrace.d

+                }
+                else
+                {
+                    auto result = new ulong[backtraceLength];


We really need to get rid of any GC allocations in this module, but that can remain a TODO.

I didn't know thats an issue. Since when is removing allocations from druntime a priority?
I actually have a non allocating version but rewrote it, because its harder to use and somewhat ugly.
https://github.com/Ingrater/druntime/blob/merge63/src/core/sys/windows/stacktrace.d

Since always, it complicates the initialization order and most GC allocations are not needed because internally druntime mostly needs allocations to track state, i.e. uses static references. It's a little different for use faced core functions. The particular issue in this module is that it's also used to throw Errors so the runtime is in an undefined state and a GC allocation could for example deadlock.

made windows stack traces 10 times faster

ghost · 2013-10-14T14:20:46Z

size_t[63] buffer; // On windows xp the sum of "frames to skip" and "frames to capture" can't be greater then 63

Can't we specialize this and allow a bigger buffer for >XP ?

Ingrater · 2013-10-14T15:41:00Z

Can't we specialize this and allow a bigger buffer for >XP ?

We most likely could somehow. How often do you have stack depths > 63?

ghost · 2013-10-14T16:28:33Z

We most likely could somehow. How often do you have stack depths > 63?

In some projects I'm forced to catch some exceptions when I'm in a C callback, and then re-throw them once I'm back in D main, here's an example stack-trace:

core.exception.AssertError@test_dragdrop(41): Assertion failure
----------------
0x004B33F7 in onAssertError
0x0040242A in void test_dragdrop.__unittestL11_1().__lambda1(scope dtk.event.DropEvent) at C:\dev\projects\dtk\tests\test_dragdrop.d(43)
0x0045F682 in void dtk.signals.EventHandler!(dtk.event.DropEvent).EventHandler.call(scope dtk.event.DropEvent) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\signals.d(100)
0x0045F4F0 in void dtk.signals.Signal!(dtk.event.DropEvent).Signal.emit(scope dtk.event.DropEvent) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\signals.d(479)
0x0047565A in dtk.dispatch.Dispatch.TkEventFlag dtk.dispatch.Dispatch._targetEvent(dtk.widgets.widget.Widget, scope dtk.event.Event) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\dispatch.d(905)
0x004753C2 in dtk.dispatch.Dispatch.TkEventFlag dtk.dispatch.Dispatch._dispatchEvent(dtk.widgets.widget.Widget, scope dtk.event.Event) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\dispatch.d(775)
0x00475370 in void dtk.dispatch.Dispatch._dispatchInternalEvent(dtk.widgets.widget.Widget, scope dtk.event.Event) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\dispatch.d(759)
0x00456320 in extern (Windows) int dtk.platform.win32.dragdrop.DropTarget.dispatchEvent(dtk.event.DropAction, uint, dtk.platform.win32.defs.POINT, uint*) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\platform\win32\dragdrop.d(700)
0x004561B1 in extern (Windows) int dtk.platform.win32.dragdrop.DropTarget.DragEnterImpl(dtk.platform.win32.defs.IDataObject, uint, dtk.platform.win32.defs.POINT, uint*) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\platform\win32\dragdrop.d(645)
0x00455DC9 in _D3dtk8platform5win328dragdrop10DropTarget183__T15ComThrowWrapperS133_D3dtk8platform5win328dragd72592015E34249E4754F716AB2609543 at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\utils.d(377)
0x75862666 in StgGetIFillLockBytesOnFile
0x74F7586C in NdrServerInitialize
0x74FF05F1 in NdrStubCall2
0x7586D936 in WdtpInterfacePointer_UserUnmarshal
0x7586D9C6 in WdtpInterfacePointer_UserUnmarshal
0x7586DF1F in WdtpInterfacePointer_UserUnmarshal
0x7578213C in CoRevokeInitializeSpy
0x75782031 in CoRevokeInitializeSpy
0x75782FEF in DcomChannelSetHResult
0x7586DE47 in WdtpInterfacePointer_UserUnmarshal
0x7586DCBB in WdtpInterfacePointer_UserUnmarshal
0x7586E34C in WdtpInterfacePointer_UserUnmarshal
0x75782DC7 in DcomChannelSetHResult
0x75782D86 in DcomChannelSetHResult
0x75C96238 in gapfnScSendMessage
0x75C968EA in gapfnScSendMessage
0x75C97D31 in LoadStringW
0x75C97DFA in DispatchMessageW
0x004673FB in void dtk.app.App.run() at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\app.d(150)
0x0047A197 in void dtk.signals.Signal!(dtk.event.DestroyEvent).Signal.opOpAssign!("~", void delegate()).opOpAssign(void delegate()) at C:\dev\projects\dtk\tests\build\\..\..\src\dtk\signals.d(331)
0x00402407 in void test_dragdrop.__unittestL11_1() at C:\dev\projects\dtk\tests\test_dragdrop.d(13)
0x004546EC in void test_dragdrop.__modtest()
0x004B3B75 in int core.runtime.runModuleUnitTests().__foreachbody2(ref object.ModuleInfo*)
0x004BB847 in int rt.minfo.moduleinfos_apply(scope int delegate(ref object.ModuleInfo*)).__foreachbody2(ref rt.sections_win32.SectionGroup)
0x004AB80F in _d_run_main
0x0045474C in main
0x004D6429 in mainCRTStartup
0x75043677 in BaseThreadInitThunk
0x77279D72 in RtlInitializeExceptionChain
0x77279D45 in RtlInitializeExceptionChain

It's still not over the 63 limit though.

Ingrater · 2013-10-14T16:43:07Z

In some projects I'm forced to catch some exceptions when I'm in a C callback, and then re-throw them once I'm back in D main, here's an example stack-trace:

Well its not like it will stop working if there are more then 63 stackframes. It will just be slower. If this is a issue for you I can dig for a way to detect Windows XP and add a condition to use a bigger buffer if running on > XP

ghost · 2013-10-14T20:52:08Z

It's not an issue, don't worry about it.

MartinNowak reviewed Oct 14, 2013
View reviewed changes

made windows stack traces 10 times faster

bda17ef

MartinNowak reviewed Oct 14, 2013
View reviewed changes

MartinNowak added a commit that referenced this pull request Oct 14, 2013

Merge pull request #638 from Ingrater/fastTrace

ba9a836

made windows stack traces 10 times faster

MartinNowak merged commit ba9a836 into dlang:master Oct 14, 2013

Ingrater deleted the fastTrace branch October 14, 2013 11:24

Ingrater restored the fastTrace branch October 14, 2013 20:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

made windows stack traces 10 times faster #638

made windows stack traces 10 times faster #638

Uh oh!

Ingrater commented Oct 14, 2013

Uh oh!

MartinNowak Oct 14, 2013

Uh oh!

Ingrater Oct 14, 2013

Uh oh!

WalterBright Oct 14, 2013

Uh oh!

MartinNowak Oct 14, 2013

Uh oh!

Ingrater Oct 14, 2013

Uh oh!

MartinNowak Oct 14, 2013

Uh oh!

MartinNowak Oct 14, 2013

Uh oh!

Ingrater Oct 14, 2013

Uh oh!

MartinNowak Oct 14, 2013

Uh oh!

ghost commented Oct 14, 2013

Uh oh!

Ingrater commented Oct 14, 2013

Uh oh!

ghost commented Oct 14, 2013

Uh oh!

Ingrater commented Oct 14, 2013

Uh oh!

ghost commented Oct 14, 2013

Uh oh!

Uh oh!

Uh oh!

made windows stack traces 10 times faster #638

made windows stack traces 10 times faster #638

Uh oh!

Conversation

Ingrater commented Oct 14, 2013

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented Oct 14, 2013

Uh oh!

Ingrater commented Oct 14, 2013

Uh oh!

ghost commented Oct 14, 2013

Uh oh!

Ingrater commented Oct 14, 2013

Uh oh!

ghost commented Oct 14, 2013

Uh oh!

Uh oh!