Make a Module unload itself.

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Make a Module unload itself.

Post by Torch »

I have a replacement vshmain.prx module that loads and starts vshmain_real.prx.

Now the problem is even after the XMB has started, it seems that memory is still occupied by the launcher module. It doesn't affect the Slim PSP. But on the Phat PSP it causes various problems.

Usually the module doesn't even start on a Phat, and just shows a black screen. If I reduce the memory usage by removing images etc from the module, then it starts successfully. But there are other side effects, like the Internet Browser doesn't work etc.

My module is built as a VSH mode PRX.

It has the basic functions

Code: Select all

PSP_MODULE_INFO("Password", 0x800, 1, 0);
PSP_MAIN_THREAD_ATTR(PSP_THREAD_ATTR_VSH);
PSP_HEAP_SIZE_KB(4096); //This is the minimum memory which the module will load with

int main_thread(...)
{
//main module code
...
...
//load and start vshmain_real.prx
sceKernelExitDeleteThread(0);
return 0;
}

int module_start(...)
{
//create and start main_thread
return 0;
}

int module_stop(...)
{
return 0;
}
How do I make the module fully unload itself after launching vshmain_real.prx

sceKernelExitDeleteThread(0) doesn't seem to be freeing all the memory. I've freed all the memory allocated by malloc() etc within the program code but its still causing problems on the Phat PSP.

I'm assuming that sceKernelExitDeleteThread(0) doesn't fully unload the module from memory and the module is still running.
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Post by moonlight »

sceKernelExitDeleteThread is not supossed to finish any module, just a thread. Use sceKernelSelfStopUnloadModule. Alternativelly you can load a kernel module to kill your module using sceKernelStopModule+sceKernelUnloadModule.

Note however that it will free the module image, but not the resources you may have used and not free. Modules are not processes, processes don't exist in the psp, so the whole memory is shared between all the modules, and memory block handlers don't have an owner, so you will have to free all you have used in the module_stop function (memory blocks, threads, fpl's, whatever).

If you are using sceKernelAllocPartitionMemory to allocate your blocks, there is no problem, you can use sceKernelFreePartitionMemory. But if you are using malloc, the libc may have reserved all the heap in the first malloc, and I don't know if there is some function in the libc to delete that heap; just don't use malloc :p
Insert_witty_name
Posts: 376
Joined: Wed May 10, 2006 11:31 pm

Post by Insert_witty_name »

If you are using malloc then __psp_free_heap() in your module_stop function will free the associated memory used by your module.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

I was just experimenting with SelfStopUnload and StopUnloadSelf. Is there any reason I should use one over the other???

I've embedded PNG images into the prx using bin2o and accessing them using extern unsigned char... Will these be freed when the module is unloaded?

Then I am again loading (decompressing??) these PNG images into Image struct in memory using someone's graphics.h functions so that I can work with them using the sceGu stuff.
This is the graphics.h http://www.psp-programming.com/tutorials/c/lesson04.zip

The PNG loading function in graphics.h is made using malloc. But it also has a freeImage function which is supposed to release the Image struct.
I'm freeing all the Image using this function before quit.
Insert_witty_name
Posts: 376
Joined: Wed May 10, 2006 11:31 pm

Post by Insert_witty_name »

In that case use __psp_free_heap() in module_stop.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

Insert_witty_name wrote:If you are using malloc then __psp_free_heap() in your module_stop function will free the associated memory used by your module.
It warns about implicit declaration of __psp_free_heap

It compiles if I give a prototype.
void __psp_free_heap(void);

Or have I not included some header or lib in the makefile?

@moonlight
Since I may not get a change to tell you otherwise, there's a small but very annoying bug in M33 Recovery menu.
Its in the feature to prevent PSP from going into standby when USB was activated. Its not fully working.
When flash0 USB is activated and PSP is left without pressing any button for 5 mins, it doesn't go into standby. But instead the USB stops working! The PC says drive is unavailable or something and filesystem might get corrupted if the drive is in use. When toggle flash0 usb is disabled after that, it immediately goes to standby.

You have to keep pressing buttons on the PSP now and then or usb will stop working in 5 mins, even if it doesn't go to standby.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

I completely forgot. This still doesn't do anything to help my plugin from NOT STARTING at all on a Phat.

If I remove all the bin2o images, and run the plugin using only the debug text it starts on a Phat.

With the bin2o images it only starts on a Slim. My plugin is around 450KB.

I was under the impression that the extra 32MB on the Slim was only accessible if you explicitly made it so in a program. My current situation leads me to believe that the firmware is freely allocating stuff in the entire 64MB on the Slim when booting to the XMB.

How much free memory do I have on a Phat just before loading vshmain.prx?
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Post by moonlight »

Well, it is a fact that the XMB uses the extra memory of slim, although I haven't yet looked at where or how they activate the memory. Use sceKernelTotalFreeMemSize to see all free memory, but anyways bin2o images should be unloaded by the module unload.
Maybe selfstopunload is not working properly, use the other option, loading a kernel module that just creates a small thread to search your module by name and then stop+unload it.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

I've checked sceKernelTotalFreeMemSize from my module both when I replace vshmain.prx and when I replace recovery.prx.
Here is my module: http://ifile.it/czjtn6r/lockdown.v1.5.zip

From vshmain.prx it has 22740KB free.
From recovery.prx it has 47656KB!! free.
Since recovery.prx is executed by systemctrl_02g, the extra 24MB is getting eaten up somewhere after that, and before vshmain.prx on the slim.

However thats just for information purposes, and not relevant.
What I want to know is if the Slim has only 22740KB free before vshmain.prx, then that Phat must have like 1-2MB ??? My heap size of 4096 must be too big, so it doesnt even load on Phat. I don't have a phat to test T_T.

The files in "debug" folder operate in text mode and are working on phat because the heap doesn't even get allocated since malloc() isn't called in this version.

After using selfstopunload, the side effects on phat by using text mode prx have gone. That means that selfstopunload is working and unloading the module. Even after repeated starting of a game and exit to xmb, it works properly.

So I think my problem with the Phat is there is only very small heap before vshmain.prx

P.S. Can you fix the sleep mode bug in M33 recovery?
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Post by moonlight »

Torch wrote:P.S. Can you fix the sleep mode bug in M33 recovery?
I'll take a look.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

It seems that module_stop() is NOT called at all when using sceKernelSelfStopUnloadModule or sceKernelStopUnloadSelfModule.

The execution after calling sceKernelSelfStopUnloadModule stops (because I cant get the return value, program stops), but I don't think module_stop() is being called at all.
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Post by moonlight »

make sure you have exported module_stop in the exports.exp file.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

moonlight wrote:make sure you have exported module_stop in the exports.exp file.
:O I don't even have an exports file, I'm such a noob T_T
I'll make one now.

P.S. What about the sleep mode bug in recovery? Were you able to reproduce it?
Post Reply