Error: Metadata bundle ID not in reverse DNS format (ex: com.panic.b360)

Recently I've started seeing a transient error <5% when I build my applications.

Specifically pdc will return the following:

error: Metadata bundle ID not in reverse DNS format (ex: com.panic.b360)

The command I'm using to build is: pdc src/main.lua "playdate-playpaint.pdx"
If I immediately re-run the build (with no changes) everything works as expected.

Here is my pdxinfo:

author=Peter Tripp
description=Play Paint

It was triggered when I changed my bundleID from net.notpeter.playpaint to the shorter net.playpaint. The issue is never triggered if I use the old three level domain and regularly with the two-level domain. If that is an invalid domain I'd expect it to be caught every time, but instead there's obviously something non-deterministic in the check and I thought y'all might like to know.

I created a small script and am able to consistently reproduce with both SDK 2.0.0 and 2.0.1:

set -e
pdc --version
while true
    echo -n "$COUNTER, "
    pdc src/main.lua "playdate-playpaint.pdx"

Let me know if there's any way I can help.

That's totally bizarre. I haven't had any luck reproducing it using your pdx and script posted above. And that error message shows up pretty early in the compilation process so there's not much happening before that could be messing things up. One thing that's a little unusual is you're pointing pdc at the main.lua file instead of the folder. Does it still happen if you do pdc src playdate-playpaint.pdx instead?

Here's the test I was running, just ftr: (1.2 KB)


Thanks @dave for taking the time to dig into this, I appreciate it.

I can confirm the issue does occur even when I point pdc at the directory (pdc src playdate-paint.pdx). Your minimal zip is sufficient to consistently reproduce the issue for me. I'm running MacOS 13.4.1 (a) on an MacBoo Pro 16-inch (2019 Intel). I don't see it under linux.

Aha, @dan found it, classic buffer overrun: We're expecting the bundleID to have two dots, and when it doesn't we read past the end. In that case, whether it passes the validateBundleID() function depends on what's in memory after that string. I'm surprised it doesn't fail more often!

We'll fix that overrun, and using a three-part bundleID will work around that now. I'm not sure yet whether we'll require three-part ids or allow two-parters--it's possible the server component requires three.

1 Like

Excellent find @dan and @dave. It’s amazing how easy it is do unsafe things in C! Thanks for tracking this down.

1 Like