Hypercard 1.2.5 crash the Heap when loading a stack

[Godzil]

I'm not 100% sure as Hypercard 1.2.5 don't claim to be 32-bit clean, so it may be linked with #12, but when it try to load a stack it generate a HEAP_DEATH assert in mmansubr.cpp:866:

    /* Search from start to the end. */
    for(b = start;
        b != ZONE_BK_LIM(current_zone);
        b = BLOCK_NEXT(b))
    {
        if(PSIZE(b) < MIN_BLOCK_SIZE)
        {
            HEAP_DEATH(); // <<<< HERE
        }

        /* Is it free and big enough? */
        if(USE(b) == FREE)
        {
            ROMlib_coalesce(b);
            if(PSIZE(b) >= (uint32_t)size)
            {
                *newblk = b;
                return noErr;
            }
        }
    }

I've added some trace to check what is happening, and it seems that the current block of the heap which is looked for report a "PSIZE" of 0, which obviously is lower than the 12 bytes of the "MIN_BLOCK_SIZE".

I'm not really sure what's happening there, I would more suspect a bug in executor more than being an issue with the 24-bit vs 23-bit mode.

I don't understand enough how the internal debugger work to try to diagnose the heap (not even sure if we can)

Linux: Debian testing - 64 bit - kernel 4.19.28-2
Build from heads/master-0-gbd19a127

[autc04]

Hmmm, some sort of heap corruption. This might be caused by a non-32-bit-clean app (that tries to lock a handle by setting a bit in the master pointer instead of calling HLock), or it might be something completely different. The built-in debugger probably won't be a lot of help anyway, might have to resort to adding lots of extra heap check assertions to executor to track that down. There are a few old mechanisms for that, I haven't quite understood them and "made them my own" yet.

The twentyfourbits branch is nearing completion; basically, it works, but I broke 32-bit support,. so I can't merge it yet. Might be worth checking out that branch and trying Hypercard 1.2.5 there.

[autc04]

.... aaand I forget to mention here that the branch has been merged in the meantime.
24-bit support is currently a build-time option, so you can either build a 24-bit executor (see README) or a 32-bit executor.

[Godzil]

Will give it a try, thanks!

[Godzil]

So that's interesting. I've build a 24bit build from the latest head, and the error is the exact same:

I wonder what happen for the heap to be corrupted. (I don't have access to my own copy of HyperCard 1.2.5 so I used the pre installed one from Macintosh Garden)

I will try running it on a 32bit clean mac at a later point, but I'm pretty sure Hypercard 1.x was working fine on all of my macs (including PPCs)

[autc04]

Okay, so that means the problem is unlikely to be related to 24/32-bit addressing...

I've now installed HyperCard 1.2.5 myself, and interestingly, I get different symptoms. It simply complains that it cannot open the Home stack (error -40).

Running the same HyperCard under Basilisk II (with System 7.5.3), it opens the home stack and then freezes. I'll have to double-check that copy of HyperCard on a real Mac.

Does the crash in Executor happen for you before HyperCard opens its main window/displays the first card, or afterwards?

[Godzil]

I've just done a couple of check, launching it directly, or double clicking on a stack behave the same.

So no it does not try to load the Home stack, or at least, it does not show the window.
I'm running it under Mac OS X 10.15, but the original report was running on a Linux system.

I'm launching Hypercard from the embeded executor browser, I'm not sure if there is any other way to start an app.

Also, just in case, here the cmake configuration as seen from ccmake:

And it is build against the current HEAD from git:

commit bbff213463f0c7e6e2bf5f0e567704b331c8a3a5