Running a prx from ms0: vs host0: in psplink

[Onii]

I'm seeing something odd in my first psp application. I've built a lumines clone. Originally I built it on SDL for the pc, and just recompiled it for the PSP, but it ran poorly so I gutted SDL out of it and ported it to the pspsdk. The port is mostly done. Anyway, the point is it's running and worked great through the debugging I have been doing through psplink and GDB. Or so I thought. When testing and debugging I have been running the prx from my hd using a host0: mounted dir, and it's been running fine, however when I move the prx to ms0: and try to execute it directly in psplink, I get the exception below:

Code: Select all

ms0:/PSP/GAME/LUMINES3/> Exception - Syscall
Thread ID - 0x04194477
Th Name   - user_main
Module ID - 0x04197239
Mod Name  - "Lumines3"
EPC       - 0x088A4300
Cause     - 0x90000020
BadVAddr  - 0x00CAD000
Status    - 0x20088613
zr:0x00000000 at:0x2008FF00 v0:0x089C0000 v1:0x00000000
a0:0xC3000000 a1:0xC3000003 a2:0x488BEAAC a3:0x00000001
t0:0x088BEAA8 t1:0x00000002 t2:0x00000000 t3:0xBD400000
t4:0x09FBFD28 t5:0x00001E04 t6:0x08835D10 t7:0x20088600
s0:0x089C3870 s1:0x09FBFDB8 s2:0x00000001 s3:0x09FBFED0
s4:0x00000024 s5:0x00000013 s6:0xDEADBEEF s7:0xDEADBEEF
t8:0x880A0000 t9:0x00000000 k0:0x09FBFF00 k1:0x00000000
gp:0x088C31E0 sp:0x09FBFD20 fp:0x09FBFD28 ra:0x08835AF8
0x088A4300: 0x03E00008 '....' - jr         $ra

In psplink I did calc $epc-$mod and came up with a localized memory address and found that in the dump I got out of prxtool. Here's what it shows:

Code: Select all

; ======================================================
; Subroutine sceGe_user_E0D68148 - Address 0x000A0000 
; Imported from sceGe_user
sceGe_user_E0D68148:		; Refs: 0x00082FE4 0x000836FC 
	0x000A0000: 0x03E00008 '....' - jr         $ra
	0x000A0004: 0x00000000 '....' - nop        

the code at $ra:

Code: Select all

	0x00031898: 0xAFC20000 '....' - sw         $v0, 0($fp)
	0x0003189C: 0x8FC3000C '....' - lw         $v1, 12($fp)
	0x000318A0: 0x8FC2001C '....' - lw         $v0, 28($fp)
	0x000318A4: 0x00621821 '!.b.' - addu       $v1, $v1, $v0
	0x000318A8: 0x8FC20008 '....' - lw         $v0, 8($fp)
	0x000318AC: 0x0062102A '*.b.' - slt        $v0, $v1, $v0
	0x000318B0: 0x14400007 '..@.' - bnez       $v0, loc_000318D0
	0x000318B4: 0x00000000 '....' - nop        
	0x000318B8: 0x8FC30008 '....' - lw         $v1, 8($fp)
	0x000318BC: 0x8FC2000C '....' - lw         $v0, 12($fp)
	0x000318C0: 0x00621023 '#.b.' - subu       $v0, $v1, $v0
	0x000318C4: 0xAFC20020 ' ...' - sw         $v0, 32($fp)
	0x000318C8: 0x0800C636 '6...' - j          loc_000318D8
	0x000318CC: 0x00000000 '....' - nop        

A little more research and I found that sceGe_user_E0D68148 maps to sceGeListUpdateStallAddr which the docs say is called by sceGuGetMemory which I use in my blit call.

Now that I have the (probably excessive) background out of the way, my question is; What's the difference between running the prx from ms0: vs. from my drive (via host0:)?

I've tried researching / debugging this myself for the last few days, but haven't had much success, so I thought it was time to post. If you need any more info just let me know, I'll try to get right back to you on it. I didn't post any code or my makefile since it all compiles and runs fine when launched from host0:.

[Insert_witty_name]

Have you copied all needed resources over too?

[Onii]

All the game specific resources such as the textures are on ms0: too.

Are there other base sdk resources that I need to put over on the MS?

I'm going to try putting the entire build dir over on ms0: and see if that helps. Then if that works I'll start pulling out files out to see what ones I need.

I'll post back with my results in a few minutes.

[Onii]

Unfortunately, no dice.

I copied over the entire build dir (headers, source, *.o and all, even though I know it's complete overkill, i just wanted to make the two dirs EXACTLY the same) and I get the same results.

Unless there are some other libraries that I need to copy over that are somehow visible to psplink from my HD and not visible from the MS I'm stuck.

I'm going to keep hammering on it and see what else I can find, while keeping an eye on this thread.

[Onii]

A little further information on this:

I debugged it down to (at least) the following block of code that is exhibiting strange behavior when the prx is loaded from the memory stick. Further complicating the issue, it only happens on the 10th call to this code (this block is from my png loading code). The first 9 runs work fine. Which make me think heap / stack corruption or something.

Code: Select all

    pixels = (u32 *) memalign(16, sizeof(u32) * width * height);

    if(!pixels){
        return false;
    }

    rowPointers = (png_bytepp) malloc(sizeof(png_bytep) * height);

    if(!rowPointers){
        free(pixels);
        pixels = NULL;
        return false;
    }

    // Fill with the pointers at width * bytes per pixel.
    for&#40;png_uint_32 i = 0; i < height; i++&#41;&#123;
        rowPointers&#91;i&#93; =  &#40;&#40;png_bytep&#41;pixels&#41; + &#40;&#40;width * i&#41; * sizeof&#40;u32&#41;&#41;;
    &#125;

    png_read_image&#40;pngPtr, rowPointers&#41;;

    free&#40;rowPointers&#41;;

Specifically, the for loop here is not working as intended: all elements of rowPointers contain a pointer to the beginning of the pixels memory.

I've also tried the loop as :

Code: Select all

    for&#40;png_uint_32 i = 0; i < height; i++&#41;&#123;
        rowPointers&#91;i&#93; =  &#40;png_bytep&#41;&#40;pixels + &#40;width * i&#41;&#41;;
    &#125;

Again, as crazy as it sounds both of these methods (to do the same thing) work perfectly if I run my prx from host0:, but when loaded from ms0: they cause my loaded texture pointer to be null and the texture dimensions to be 0x0. Which is what I'm assuming cause the exception that I first posted about. I'm not really well versed in MIPS asm (in fact it's been about a dozen years since I did any intel asm for that matter), but I traced it through with gdb, and it looked like some weird things were happening. I'm going to run thought it again tonight. I cant imagine that something that low level would be the cause though.

Is it possible I'm inheriting some heap weirdness from the psplink host thread? Not that I think something like that would cause the situation I describe above. This is also only the first thing I've tracked down, there may be others.

I'm willing to try anything at this point. Do the gurus out there have any suggestions?

[Insert_witty_name]

Further complicating the issue, it only happens on the 10th call to this code (this block is from my png loading code). The first 9 runs work fine. Which make me think heap / stack corruption or something.

Sound like you're not closing your file when you've opened it.

Check through and make sure you are, especially in error catching blocks.

[Onii]

That was exactly it! There was a bug with the code that set the conditions for the files to be closed. It seems you can only have something like 10~12 files open from ms0:. Apparently you can have more open from host2:

I can't believe a made such an amateurish mistake as not closing the files properly.

Thanks IWN.