Log In  



Not sure if it was already reported, but I have a really simple code that PICO-8 seems to not like at all.

I was doing some test with SSPR, and every time I try to run the cart, PICO-8 just crash.

I'm probably doing something really wrong, but that should not crash PICO-8 :D

Here is the code:

 
function _update()
end

function pset256(x, y, c)
 local sx = (c*2) % 128
 local sy = flr((c*2) / 128)
 sspr(x*2, y*2, sx, sy, 2, 2)
end

c = 0
function _draw()
 cls()
 for x=1, 64 do
  for y=1, 64 do
   pset256(x, y, c)
   c = c + 1
   c = c % 256
  end
 end
 print(time(), 1, 1, 0)
 print(time(), 0, 0, 11)
end

Interestingly, it seems to "work"with the current web version (at least it does not crash and print the time)

Cart #werujasoka-1 | 2020-10-25 | Code ▽ | Embed ▽ | No License

Also just tried with the windows version it also crash.

Here is, what I think is the relevant info from the crash log generated by Mac OS X:

 
Process:               pico8 [6244]
Path:                  /Applications/PICO-8.app/Contents/MacOS/pico8
Identifier:            com.lexaloffle.pico8
Version:               0.2.1b (0.2.1b)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           pico8 [6244]
User ID:               501

Date/Time:             2020-10-25 03:54:47.808 +0000
OS Version:            Mac OS X 10.15.6 (19G2021)
Report Version:        12
Anonymous UUID:        0257CBF1-C529-2D33-F11C-AFF8E441566F

Time Awake Since Boot: 12000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000080
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [6244]

VM Regions Near 0x80:
--> 
    __TEXT                 0000000104da2000-0000000104ecf000 [ 1204K] r-x/r-x SM=COW  /Applications/PICO-8.app/Contents/MacOS/pico8

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.lexaloffle.pico8          	0x0000000104e0c50b pico8_blit + 603
1   com.lexaloffle.pico8          	0x0000000104e06ef0 p8_sspr + 608
2   com.lexaloffle.pico8          	0x0000000104dc55ea luaD_precall + 426
3   com.lexaloffle.pico8          	0x0000000104dc7093 luaV_execute + 4403
4   com.lexaloffle.pico8          	0x0000000104dc847f resume + 175
5   com.lexaloffle.pico8          	0x0000000104db2376 luaD_rawrunprotected + 86
6   com.lexaloffle.pico8          	0x0000000104dc81f3 lua_resume + 83
7   com.lexaloffle.pico8          	0x0000000104dedc5f run_slice_section + 559
8   com.lexaloffle.pico8          	0x0000000104dedf01 run_slice + 97
9   com.lexaloffle.pico8          	0x0000000104dad6f3 codo_main_update + 2019
10  com.lexaloffle.pico8          	0x0000000104e3a2f7 codo_main + 183
11  com.lexaloffle.pico8          	0x0000000104da3174 start + 52

Please tell me if you need/want more info, but I'm pretty sure you can reproduce that issue.

Edit: It seems to be related with the number of SSPR call. If I lower the value for the loops it does not crash

Edit2: yup if I force a flip() in the middle, it does not seems to crash (though it slow down the thing by a huge factor, so it may not hit the issue)

Not sure how you handle the drawing commands, but if you have a queue for each frame, I may just push too many commands ?

Edit3: No I should not do PICO-8 stuff when I should sleep. My parameter order are wrong, so it must try to read at an invalid memory area. Seems your memory access are not protected
I'm not sure if it is the sprite SX/SY that cause the issue or the sprite size (SH/SW) or a mix of both. Too tired right now to run a more extensive test on that

Can't say exactly for sure what is the combination, but if I fix SH and let SW change with the math in my code, it will crash

I copy/pasted that and I instantly crashed my .app ;\

@zep

I traced it and this single line is the absolute minimal repro case (on 64-bit windows):

 
sspr(128, 126, 124, 3, 2, 2)

Nice find, @Godzil.

Thanks for limiting it to a single instruction :)
I didn't went that far (didn't had time yesterday to look at it more)

Ans nice find? Well if I were not too tired/stupid on that night, and putting parameters in the wrong order I would have probably never found it :D

More of a lucky find ;)
2

Excellent -- thanks @Godzil, @Felice

This is fixed for 0.2.2. There was a completely missing case mistake in some ancient clipping code!
2

The first condition at the start of the clipping function I've used since 2001.

🎵 One of these thing is not like the others. 🎵

 
	if ((*sx > source->width) || (*sy >= source->height) ||
		(*dx >= dest->cr) || (*dy >= dest->cb))
	{
		*h = 0;
		return;
	}


Thanks zep!

Interesting :D So that mean it was also misbehaving with other commands?

Should I try to fuzz more function parameters? :D



[Please log in to post a comment]