Alloy debugging with xsbug?

Watchapp/Face Developers Corner
1

As a JS dev, I have never really tried serious watchface development for Pebble until now with the introduction of the Alloy JS framework. Being able to write modern JS is great (please bring the same conveniences to pkjs!), but I am constantly running into memory issues that I have no idea how to debug (often the logs will just say fxMapArchive failed or fxAbort memory full. I have been relying on LLM agents a bit too much for my taste to try to figure out how to optimize things, but I’ve been digging into the Moddable docs and have found some decent information (Moddable | Documentation | XS | Using XS Preload to Optimize Applications). One thing I think would help a lot in understanding slot, chunk, and stack usage (my mdbl.c file was altered to customize these settings) is using Moddable’s xsbug tool for step debugging. I can see it buried within the pebble SDK folders, but I don’t know how to use it with the Pebble CLI & QEMU. Is it possible to use, and if so, how?

1 Like
2

I second this!

I’m running into constant “fxAbort memory full” errors in the emulator with a watchface I’m building and I’m having a heck of a time trying to troubleshoot it!

The watchface is moderately complex (uses location, networking, clay settings, etc.) but it’s not SO complicated that I would expect it to ACTUALLY exhaust the available memory. The errors seem to mostly say it can’t allocate some silly, small amount of memory (like less than 20 bytes).

Any sort of advanced debugging would be helpful to figure out what’s going on. I feel like it’s an actual bug/issue in either Moddable or PebbleOS (or the integration between them) but the only info in the log is a reference to the error handler, not to what actually triggered it :wink:

2 Likes
3

The comments in my mdbl.c file might help a little, you can apparently control the size of the virtual memory allocations, I just don’t have much experience doing this. Without a debugger I’m basically using trial and error (and frankly some GitHub Copilot, so be warned) to try to optimize the JS and memory allocations. I’d prefer to dispense with the guessing in favor of step debugging.

1 Like
5

Well, xsbug is not yet supported but is planned: fxMapArchive failed - Pebble watchface build with Alloy · Moddable-OpenSource/moddable · Discussion #1602 · GitHub

For now, we need to rely on instrumentation added via ModdableCreationRecord flags:

ModdableCreationRecord creation = {
		.recordSize = sizeof(ModdableCreationRecord),
		.slot  = MY_SLOT_SIZE,
		.chunk = MY_CHUNK_SIZE,
		.stack = MY_STACK_SIZE,
#ifdef ALLOY_INSTRUMENTATION
		.flags = kModdableCreationFlagLogInstrumentation,
#endif
	};

The ifdef is looking for an env var that I define in an npm script for convenience, like this:

"build": "pebble build",
"build:dev": "ALLOY_INSTRUMENTATION=1 npm run build",

From the GitHub discussion linked above:

[…]instrumentation logs (optional, but you had them enabled in your mdbl.c) do show the memory use in the slot and chunk heaps, peak stack, and free application memory. These are updated once a second. They are a good high-level view of memory use in the JavaScript runtime. The logs aren’t much fun to read in the console – xsbug provides a visualization of those.

2 Likes
8

cr0ybot - you are my “hero of the week” :smiley: . I ‘stole’ your mdbl.c for my own watchface where I was running into constant memory errors and … it just worked. Errors gone.

I tweaked from there; I was able to go quite a bit lower on the memory allocation before the errors returned.

I dug around in the Pebble Moddable sources and it looks like it should automatically increase the allocations as needed, but for whatever reason it’s not working right after it hits some limit or condition in my watchface that I couldn’t figure out. But hard-coding using your method seems to solve the problem for now.

The version of the watchface I’m working on is for private use, but I kept your comment (with attribution and a link to the original location) so if/when I fork it into a public version you’ll get the appropriate credit. Thank you so much!

2 Likes
9

I’m glad it was helpful! Unfortunately the things I was trying to do were seemingly too much for Alloy so I switched to C, but I would like to try again for something simpler.

Also since the project was completely rewritten, the link above no longer works. Here’s a permalink to the last version of the mdbl.c file if anyone else is looking for it.

2 Likes