Maybe it's one of those non-standard free() functions that crashes if you give it a null pointer. A developer I once worked with said that he had gotten into the habit of "if(p) free(p);" because he'd work with such a system before.

(In case anyone is wondering: I can't think of a single commonly-used standard C library that doesn't accept null pointers to free(), i.e. the nullcheck is in the free() itself. Embedded systems, however, may vary widely in how closely they follow the standard.)

I downloaded some thing that purports to be the "Nintendo 64 SDK" and it says that its implementation of malloc cannot be accessed safely by multiple threads (there's an alternative function that does guarantee this). I think this might be it? (FYI: the free function does check for NULL.)

I've never worked with the official OS routines, but I think standard malloc() and free() just weren't provided, in favor of a custom arena-based system. Ref: http://n64devkit.square7.ch/pro-man/pro10/10-05.htm

My only thought about malloc() is that it was susceptible to fragmentation and applications needed to manage their own pools of similar sized blocks. But definitely an odd comment without further allocation.

As I recall their allocator was a fairly basic implementation - I don't think it had small allocation support, or any debug/stacktrace/tagging functionality.

You could drop in your own allocate/free for everything in-game and ignore their implementation (you had pretty much complete control over what went where in the memory so long as things to be copied to the RSP/RDP were aligned correctly and the display buffers were on some specific boundary).

Allocating from pools per system was very common (eg particle effects got a 16kb memory pool for vertices and the code had to gracefully handle hitting that limit). Another common practice was to store a high-water marker at the start of a level load and just roll back to that marker when you changed level.