Reproducible Medley hang

[hjellinek]

Describe the bug
Running a simple Lisp function that does output to the Exec, Medley hangs with a spinning pizza cursor.

To Reproduce
Steps to reproduce the behavior:

1. Files loaded: some of my code under development.
2. Form to eval: (write-bitmap bm #'debug-output-fn #'pixel-to-monochrome-rgba)
3. What happened? There's a few lines of expected output in the Exec, then it stops and Medley hangs. ^D does nothing and I have to force-quit the ldesdl process.

Expected behavior
I expect to see several more lines of output in the Exec. I expect Medley not to hang.

Screenshots
I attached one screenshot showing the output write-bitmap produced leading up to the hang, though it's unlikely it will show you much. More interestingly, I got macOS to produce a problem report, also attached.

Context (please complete the following information):

• OS: macOS Ventura
• OS Version: (13.7.1 (22H221))
• Host arch: x86_64
• Maiko version: cea720feb218e25f9927b50e3a123581746a0e52 running SDL
• IL:MAKESYSDATE: 6-Nov-2024 10:52:14 (my own build)

Additional context
I can provide the lisp.virtualmem file.

crash.log.zip

[hjellinek]

More: I marked a couple of macros as "changed," then tried the test case again. ( didn't actually modify any code.) This time the result was slightly different in that a break window opened, then the system hung.

[hjellinek]

After fixing that error in my program it runs successfully to completion. The only unusual aspect of my code is that it calls multiple-value-bind and values in a loop, once each for every pixel in a 32*16 bitmap. Each values invocation returns 4 fixnums.

[rmkaplan]

multiple-values in a loop is a bad idea, a known long-standing bug (Issue #19). It doesn’t clean up the stack properly on each call.

…

On Nov 26, 2024, at 1:59 PM, Herb Jellinek ***@***.***> wrote: After fixing that error in my program it runs successfully to completion. The only unusual aspect of my code is that it calls multiple-value-bind and values in a loop, once each for every pixel in a 32*16 bitmap. Each values invocation returns 4 fixnums. — Reply to this email directly, view it on GitHub <#1888 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNKCKZL6WCQNAUWOAT2CTVK7AVCNFSM6AAAAABSRNGDO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBSGAYTSNRVG4>. You are receiving this because you are subscribed to this thread.

[hjellinek]

That's too bad, this code would be much less readable and maybe marginally less efficient if I need to cons up an object and return it.
Looking at it another way, this is a pretty simple test case. The key seems to be that an error occurred within the loop, so a test case might be:

loops no more than 512 times
call something that invokes (values 0 0 0 255) with a caller that binds 4 values
triggers an error at some point within the loop

I just created a test function that does that and makes it easy to reproduce the problem.

I'll close this issue and continue the discussion under issue #19.

[hjellinek]

GitHub should have closed it as "duplicate."

[hjellinek]

I'm reopening this because it seems not to be related to what's reported in issue #19.

From @nbriggs's comment on that issue:

Investigated the macOS crash report - it's a GC problem, possibly only indirectly related to the stack issue.
It was trying to DELREF a cons page (at the end of N_OP_Cons), and took a trap in the reference count handling code -- which is a large macro so doesn't show up nicely in the backtrace, just the source line number of where the macro is invoked, not the line within the macro.
It might help to rewrite the macro as a function (which we could inline when not debugging) - but to catch this, I think we're going to need to have it either fail when we've got a debugger attached, or if it has failed into uraid with a fault can attach a debugger (lldb on macOS) after the fact.

[nbriggs]

The cases where I've seen a crash like this before, though as far as I know not emanating from GC called from N_OP_Cons, have been because other code caused a smash. These were when @rmkaplan was working on the internal data structures of TEdit which involved various pointer bashing exercises. Is there any chance that something that you were working on might have done damage that then sent GC off the deep end?

[hjellinek]

The code I've been working doesn't do anything with, for example, raw pointers, nor does it try to outsmart the GC. It's tempting to say it only uses the documented Medley APIs, but the imagestream APIs I'm using aren't as documented as they might be. But my code is using only type-checked operations. And I wasn't using @rmkaplan's experimental TEdit branch.

[nbriggs]

@hjellinek do you have the ldesdl executable from the crash? If so, could you zip it up and attach it here. Thanks.

[hjellinek]

I just rebuilt it, but Time Machine says this is the previous (Nov 6) version.

ldesdl.zip