JS runtime error information from instrumented build

[linfan68]

Is there a way to get some information (error, line number) when JS runtime error happens when running in instrumented build?

[phoddie]

Some information? Yes.

An instrumented build is a release build, so not all debugging information is available. For example, the source code file names and line numbers are removed from the byte code. But, the function names are still available.

When an unhanded exception occurs, XS calls fxAbort in the host. The behavior from there is determined by the host. By default, we restart. This is safest behavior (Node strongly agrees). But, other behaviors are possible. For example, we can call a JavaScript function to display the stack and perhaps other information. To try that, you can modify this section of fxAbort in the ESP host to call a global abort function:

	#if defined(mxDebug) && !MODDEF_XS_TEST
		if ((char *)&the <= the->stackLimit)
			the->stackLimit = NULL;
		fxDebugger(the, (char *)__FILE__, __LINE__);
	#elif defined(mxInstrument) && !defined(mxDebug)
		if (XS_STACK_OVERFLOW_EXIT != status) {
			mxPush(mxException);
			txSlot *exception = the->stack;
			mxException = xsUndefined;
			mxTry(the) {
				mxOverflow(-8);
				mxPush(mxGlobal);
				fxCallID(the, fxFindName(the, "abort"));
				mxPushStringC((char *)msg);
				mxPushSlot(exception);
				fxRunCount(the, 2);
				mxPop();
			}
			mxCatch(the) {
			}
		}
	#endif

Notice that it does not call the JavaScript abort handler in the case of a stack overflow, as it would immediately fail. It does call it on memory failures. It may fail too, but depending on the runtime situation it might succeed too.

Here's a small test app:

globalThis.abort = function (msg, exception) {
	trace(msg, ":\n", exception.stack, "\n");
}

function foo() {
	throw new Error("forced error");
}

function boo() {
	foo();
}

function test() {
	boo();
}

trace("running\n");
test();

Here's the output:

...
I (95) heap_init: At 4008B90C len 000146F4 (81 KiB): IRAM
I (101) spi_flash: detected chip: generic
I (104) spi_flash: flash io: qio
I (1instruments key: Pixels drawn,Frames drawn,Network bytes read,Network bytes written,Network sockets,Timers,Files,Poco display list used,Piu command List used,SPI flash erases,Turns,System bytes free,CPU 0,CPU 1,Chunk used,Chunk available,Slot used,Slot available,Stack used,Stack available,Garbage collections,Keys used,Modules loaded,Parser used,Floating Point
running
XS abort: unhandled exception
unhandled exception:
Error: forced error
 at foo ()
 at boo ()
 at test ()
 at main ()

If this is useful, we can look into integrating it as an option into the hosts.

[phoddie]

FYI – I've been working on some refinements to this quick patch to fxAbort with the goal of integrating it into the SDK as a supported feature. The result should address some common requests. I hope to have more news on that in the coming days.

[linfan68]

I tested the code and it works! I think this is a necessary feature, and I don't like the default behavior.
I spent ~2 hours debugging a Mod code, and eventually found there is a null reference. But the host just silently restart without any error message.

[phoddie]

I tested the code and it works!

Great. Thank you.

I think this is a necessary feature...

Sure. There are two parts - the hook in the native runtime to call the JavaScript abort function and the JavaScript abort function. We can provide a flag to enable the native runtime support. Your project will need to provide the abort function.

I spent ~2 hours debugging a Mod code, and eventually found there is a null reference. But the host just silently restart without any error message.

That must be frustrating. I have a couple of questions:

• The host doesn't "silently restart". It has always displayed "XS abort: unhandled exception" in this case.
• There is a debugger. Why not use it when debugging?

[linfan68]

• The host doesn't "silently restart". It has always displayed "XS abort: unhandled exception" in this case.

Em... in my case, the error happened in a Mod, so the observation (if I remember correctly) was the Mod code just stops execution, but the "host" (not the Native host, the host JS code) still running. That's why I got confused back then. (Also I'm brand new on this framework)

• There is a debugger. Why not use it when debugging?

Yeah... I'm just new....

[phoddie]

in my case, the error happened in a Mod, so the observation (if I remember correctly) was the Mod code just stops execution, but the "host" (not the Native host, the host JS code) still running. That's why I got confused back then. (Also I'm brand new on this framework)

The mod and JS host both run in the same virtual machine (unless you are doing something with Workers). If there's an exception in the mod, it is still reported. If you have a way to reproduce the behavior you describe, that would be interesting. If not, no big deal.

[phoddie]

FYI - there's a new "abort hook" feature available. It takes the basic idea described above and include it in the Moddable SDK for ESP8266, ESP32, Pico, and the simulators. You can see an example here. Enable it in your project manifest:

	"defines": {
		"xs": {
			"abortHook": 1
		}
	}

[linfan68]

@phoddie A follow up question here:
What does it take if I really want filename + line number information from instrumented build?
I imagine some additional address information into the ROM + offline source map post processing?

[phoddie]

What does it take if I really want filename + line number information from instrumented build?

I assume you are asking about showing the filename and line number in the Error stack, is that correct? I agree that it would be useful.

I imagine some additional address information into the ROM + offline source map post processing?

That's how C code debugging works. It isn't how we do it in XS. Instead, the byte code contains the file path and line number information. The engine tracks that as the code executes.

The problem with addresses and link maps is that it doesn't always work for JavaScript. For example, mods are not part of the firmware image and live at an arbitrary address (they are memory mapped). And mods can also run from RAM. Also, code that is generated by eval doesn't have a constant address, since it lives in RAM (and can move as the heap is compacted). XS is able to debug all of these situations with its approach.

I think to get the filename and line information in an instrumented build would require a couple things:

1. Compile the JavaScript with debug information (-d passed to xsc). That's easy.
2. Split the debug implementation in XS so that the file & line information is tracked in instrumented builds and included in Error stacks, but the xsbug protocol support is not included, or at least not used. That's a bit tricky. (I tried quickly but didn't get it right)