Single File Examples "file" crashes both simulator and physical device

SDK Bug Reports
1

Playdate SDK 1.12.3 on Windows 10 (fully updated)___

I'm compiling and running the Single File Examples - file example.

As soon as I try to run it in the simulator it crashes:
playdate_crash

The file that the example tries to create is created:

image
image1060×690 35.6 KB

The app only crashes when it tries to read the file.

If I open the source code and remove or uncomment these lines:

repeat
    l = file:readline()
    print(l)
    if l then
        print(l:match("(%d+)", 1) + l:match("(%d+)", 2))
    end
    print()
until l == nil

the app no longer crashes (but it doesn't produce the expected output - naturally)

If I then add back in just the l = file:readline() line it crashes again.

On the actual console it looks like this (single images as animation was too large to upload):

pd_crash_img0
pd_crash_img0633×601 119 KB

pd_crash_img26
pd_crash_img26633×601 129 KB

pd_crash_img33
pd_crash_img33633×601 110 KB

pd_crash_img49
pd_crash_img49633×601 116 KB

pd_crash_img110
pd_crash_img110633×601 121 KB

pd_crash_img199
pd_crash_img199633×601 116 KB

pd_crash_img213
pd_crash_img213633×601 116 KB

Also on the device the file is created correctly:

image
image890×853 32.8 KB

2

Is it going into an infinite loop?

Can you print something after the loop?

3

No. It just hard crashes. The simulator I have to start manually again. And the device just reboots to the menu where I can choose to start any game.

1 Like
4

It you can't print something after the loop then it's never exiting the loop. ie. It's going into an infinite loop.

Are you sure readline returns nil when there are no more lines? Maybe this behaviour has changed since the code was written?

5

Counter point: If it goes into an infinite loop as you say, why does the app crash? My experiences with infinite loops are unresponsive apps. This is not the case here. I am pretty sure readline never returns anything because it crashes...

Even if I try with just this in main.lua:

file = playdate.file.open("test.txt", playdate.file.kFileWrite)
file:write("1 2\r3 4\n5 6\r\n7 8")
file:close()

file = playdate.file.open("test.txt", playdate.file.kFileRead)

l = file:readline()
print(l)

playdate.stop()

function playdate.update()
end

it crashes.

Now there is no loop that can run indefinitely.

1 Like
6

Good idea!

What line/s can you remove for that one to not crash?

Can you try different line endings in the source text file? eg. Mac or Linux style line endings.

I'm not near my computer or I'd try this myself!

ps: Playdate watchdog will crash when it goes into an infinite loop. Also when the game takes too long to do an update it will fail in a different way.

7

I can remove l = file:readline()

The console will then print 'nil' as expected.

8

I'm using VS Code on Windows so the only line endings I can choose without jumping through a lot of hoops are CRLF and LF. But neither solves the crashing.

Furthermore I've now gone and downloaded all the previous SDKs (1.9.0 to 1.12.2) and compiled using each SDKs compiler and then running the program in the matching simulator. All crashes without exception.

--- pause while I mess around with the example ---

HA! I found it... but it's really silly.

In the example file file.lua (the one provided by the SDK at PlaydateSDK\Examples\Single File Examples) contains this line:
file:write("1 2\r3 4\n5 6\r\n7 8")

If I take the \r and replace it with \n or \r\n it works!

What led me down this path was the fact that all the games on my Playdate writes files and (presumably) also reads them. First I thought it was because I had a space in my project name, but quickly ruled it out. Then I noticed that the three newlines in the call to write were different...

But why is it specifically the Mac flavored line break that fails. Panic is a Mac house... But it's the one that the Playdate chokes on - both simulator AND physical device. That is weird.

1 Like
9

thanks for tracking this down! I'm not sure what's going on here yet since I don't have a Windows machine to test it on, but I'm sure Will can sort it out. When we read a \r and then the next character isn't \n, we push it back to the stream with ungetc() then end the line. That works on macOS and it looks like the function should behave the same on the two platforms, so I'm not sure what the problem could be. Maybe I'm looking at the wrong thing.. :thinking:

10

The crash on the device and the Simulator are unrelated (well, related in so far as they're both caused by the \r character :slight_smile:) . The Simulator crash is already fixed for the next release while we're looking at the device crash.

1 Like