fxMapArchive failed - Pebble watchface build with Alloy

[cr0ybot]

I keep running into a particular runtime error as I build a custom Pebble watchface with Alloy:

[07:58:07] xsPlatform.c:209> Error: fxMapArchive failed
 at ArchivePebbleResource ()
 at default ()
[07:58:07] xsPlatform.c:217> fxAbort unhandled exception: fxMapArchive failed

I'm a JavaScript developer with only a little experience programming for embedded systems, so this message isn't really telling me anything about what the issue is. I tracked down the code that is throwing this error:

dd56869#diff-781af7f5cc76aa834c24eba4ffa939b2a43ddb33999e73267d2e7653f15f8a01R78-R81

The commit message from @phoddie says "throw exception if fxMapArchive fails; can much use smaller buffer (at least for now...)". I'm assuming I'm running up against the "smaller buffer" but I don't know what that means in practical JavaScript terms or how to properly write code with this in mind. Does anyone have any guidance?

[phoddie]

Thank you for the report.

I haven't seen an error in fxMapArchive like you report. There are only a handful of reasons why fxMapArchive would fail:

1. Insufficient memory. That's a real possibility on an embedded device like Pebble. For that to happen, your JavaScript and/or its resources would need to be pretty substantial.
2. Corrupt data. If the archive (which contains the byte code generated from your JavaScript source code), was somehow corrupted, that can trigger an error.
3. Something we've never seen before. ;)

If you are able to share a sample project that triggers the problem, we could try to sort out what's going on. If sharing your source is a concern, we can probably make do with just the resource data generated, though it would be more complicated here. Let me know and I can explain how to extract that from your build results.

[cr0ybot]

@phoddie Thanks very much for taking a look. I'm afraid you've found the part of this where I was trying to use an LLM agent to understand the problem. I very well know the risks of this but did it anyways, and I'm not surprised it was wrong.

I'm going to try to clean out much of that, though I do get a more direct fxAbort memory full error when I remove the slot, chunk, and stack options from mdbl.c when I do npm run build-run:gabbro. That's using QEMU on Mac OS 14.3, I don't have a physical Pebble Round 2 to test on. When I dialed the chunk and stack sizes down I actually got a fxAbort JavaScript stack overflow, which I'm not sure is a good or bad sign yet.

[phoddie]

Thanks for the background. I thought I might have stumbled on the idle speculation of an LLM, but didn't want to assume.

If dialing down the stack size gives a stack overflow error, that's a pretty clear indication that you need more stack than I thought. I probably didn't exercise the watchface enough to find the limit.

[cr0ybot]

I am digging more into the Moddable docs and found this one about preloading and other optimizations helpful: https://www.moddable.com/documentation/xs/preload

I should probably have specified as well that I am using the pebble-tools CLI (pebble build + pebble install --emulator emery --logs) so that might account for some discrepancies.

I'm currently trying to figure out if I can make use of xsbug with the pebble SDK, that would probably help with understanding the memory footprint of the project quite a bit.

[phoddie]

Preload is a very powerful technique. Unfortunately, it is not available in mods. Alloy apps are mods.

I should probably have specified as well that I am using the pebble-tools CLI (pebble build + pebble install --emulator emery --logs) so that might account for some discrepancies.

Good to know. That is more-or-less what I'm doing as well, though I'm building the latest Pebble OS sources.

I'm currently trying to figure out if I can make use of xsbug with the pebble SDK, that would probably help with understanding the memory footprint of the project quite a bit.

xsbug is not yet supported. It is on the agenda for the near future though. Having a real debugger will make development much easier in many ways.

That said, the 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. But, you can probably get an LLM to help you visualize or otherwise analyze those until xsbug is available.

Apologies for the bumps in the road. Your feedback is very helpful in helping us improve Alloy for everyone.