The particular example of T.O.M.E. is good because (as I mentionned it
before) it is a game with simple functions, yet it is quite big, and well
programmed, enough to let us know what's going on. + it's open source
which helps debugging.
In rev49 if I run T.O.M.E, it gives a "core failed" message. Which is
actually because of a malloc failure (quite easy to trace but I'll upload
a lightly modified EBOOT later).
The way malloc works in the PSPSDK is this way:
The first time malloc is called, the SDK does:
1) a call to maxFreeMemory
2) a call to sceKernelPartitionAlloc(maxMemory)
then an internal data structure handles the following calls.
the "FAKEMEM" macro in HBL creates fake functions for maxFreeMem and
sceKernelPartitionAlloc, in order to overcome the problem that we have not
enough free ram (actually we do but the system doesn't seem to realize it).
We believed that unloading the "Labo" module would solve that problem,
which is not entirely true: PSPLINK now sees the memory as freed, but
Homebrews don't.
We need to investigate and fix this issue. as a workaround, the "FAKEMEM"
system is still a valid alternative, but needs to be improved to be more
robust and clean.
The weird thing: we have no problem calling sceKernelPartitionAlloc from
the HBL, so why is malloc failing in homebrews ? a problem with
maxFreeMem ?