JsDiagGetStackTrace returns empty array when stack is not empty

[fatcerberus]

I'm having a bizarre issue where JsDiagGetStackTrace() returns an empty trace even when there's something on the stack. This only seems to happen on Linux and what's very strange is that it appears to depend on optimization settings; I can't reproduce it in an unoptimized build at all (this being strange because ChakraCore itself is a fully optimized shared-library build in all cases, so the optimization settings of the host shouldn't matter).

To verify there was indeed something on the stack, I gave my debugger the following code:

function doStuff()
{
    print("Checkpoint 1");
    debugger;
    print("Checkpoint 2");
}
doStuff();

Running this code, execution pauses at the debugger statement but the backtrace is completely empty--and remains empty even as I step through the remainder of the code.

To rule out that this isn't a bug in one of my abstractions, I added some instrumentation at the point I actually retrieve the stack:

	if (JsDiagGetStackTrace(&backtrace) != JsNoError)
		return false;
	JsPropertyIdRef propId;
	JsValueRef propValue;
	int length;
	JsCreatePropertyId("length", 6, &propId);
	JsGetProperty(backtrace, propId, &propValue);
	JsGetValueType(propValue, &type);
	JsNumberToInt(propValue, &length);
	printf("%d: %d\n", type, length);

The output was 2: 0 (2 being JsNumber); so it seems that I've indeed been handed back a zero-length array. If I recompile the host with -g instead of an optimization flag, this same code prints 2: 2 upon hitting the debugger statement. It's very, very strange.

[fatcerberus]

I note that this seems unlikely to be an optimizer bug, as the issue is equally reproducible with both gcc and clang. The reproduction above was on Ubuntu 16.04; I've received reports of it happening on Arch Linux as well.

[MSLaguana]

Adding the result of our discussion on gitter: This might be due to -fomit-frame-pointer in the host code leading to stacks that we can't traverse properly. I would have expected that we would get at least one frame since gdb was able to see at least one JS frame, but it might use a different stack walking approach to us.

[fatcerberus]

Here's the root of the problem:

• x64: https://github.com/Microsoft/ChakraCore/blob/dcecda54309f23f673aa0cc149eb65f0b2b8d72c/lib/Runtime/Language/amd64/StackFrame.cpp#L103
• x86: https://github.com/Microsoft/ChakraCore/blob/dcecda54309f23f673aa0cc149eb65f0b2b8d72c/lib/Runtime/Language/i386/StackFrame.cpp#L32

tl;dr

Always compile the host with -fno-omit-frame-pointer if you need ChakraCore to be able to see the callstack at runtime.

Having spent some time looking into this, what I've found out is that:

• Traditionally on x86 and x64, BP is the register used to store the address where the current stack frame begins (EBP on i386, RBP on x64). As this register is nonvolatile (saved in the prologue, restored in the epilogue), a stack trace can be generated simply by following the chain of pushed BP values up the stack, in the style of a linked list. This is exactly what ChakraCore does when it needs to do a JavaScript stack walk.
• Compiling with -fomit-frame-pointer, which is the default in GCC and Clang for all optimization levels other than 0, allows the compiler to not only avoid saving BP in every function, but also frees it up for use as a general-purpose volatile register. So not only can that register no longer be relied upon to refer to the stack frame address--or even to be an address at all--it's no longer possible to follow BP up the stack as it might not even be saved.
• When JsDiagGetStackTrace is called, ChakraCore begins walking the stack from that point, and promptly runs into a wall because BP was not saved for the function that made the call in the first place; without that, it's now impossible to find the return address and the walk fails. It never sees the JavaScript calls simply because they are not visible to the stack walking mechanism.
• I initially thought all calls to _AddressOfReturnAddress() might be unsafe as this Windows intrinsic is aliased to __builtin_frame_pointer(0) on xplat, but it turns out to be fine since the compiler is smart enough to leave BP alone for any function using the builtin. This still doesn't help us walk the callstack, however, since the register is not saved for other functions.
• Despite all this, GDB appears to be able to produce a backtrace even under these difficult circumstances. It would be helpful to know what they're doing so that perhaps we could adopt that behavior. For now though, it seems that including -fno-omit-frame-pointer when building the host is the only option if you need realtime stack traces.

[fatcerberus]

Slight correction to the above: BP is saved for all calls regardless of FPO (and this must happen otherwise FPO would be an all-or-nothing optimization), however the saved BP values are not guaranteed to point to stack frames nor is the register itself. So the problem remains.

[fatcerberus]

@dilijev I see you closed this as Answered - but is this actually a bug? I don’t think this is by-design especially since it’s perfectly fine to use FPO optimization on Windows.

[dilijev]

@fatcerberus I may have misunderstood the discussion here. I'll open it back up as a bug and let the folks working on debugging APIs decide.