N.O.V.A. Mini causing crash in intro

[bhavin192]

Emulator crashes when press start menu appears

http://forums.ppsspp.org/showthread.php?tid=293&pid=45902#pid45902

Log file

http://forums.ppsspp.org/attachment.php?aid=6894

[unknownbrackets]

http://report.ppsspp.org/logs/game/NPEZ00222_1.02

I implemented sceKernelCancelMutex recently. Have you tried the latest build?

-[Unknown]

[bhavin192]

Downloading ...
Was using 205

[takeshineale128]

still crashing on v0.9.1-289 0n android!

[bhavin192]

Yes it is still crashing

[bhavin192]

Here is the log from 309

https://docs.google.com/file/d/0B3rTyJJIiCCZUVlKVXU0SUFYM0E/

[unknownbrackets]

Any change with this game?

-[Unknown]

[bhavin192]

Still crashing at same place

[bhavin192]

@unknownbrackets

tried with 1954 same result

[unknownbrackets]

Any improvement? If not, does anyone have a debugger they could get a stack trace with?

-[Unknown]

[bhavin192]

@unknownbrackets
No improvements yet
also still I have not set up the build env. For windows (Only Qt is set)
when I get some time will set windows build env.

[unknownbrackets]

Qt is fine too as long as it crashes there. I just want a stack trace.

-[Unknown]

[unknownbrackets]

Any change? There's video stuff nearby so maybe it was affected by recent changes in that area.

-[Unknown]

[bhavin192]

No changes. video is not causing it
also can't give stack trace because I am getting a error when compiling in qt creator for symbian which doesn't appear when qmake is directly used

[unknownbrackets]

So, I think the problem here may be that the game tries to free old (already freed) pointers in a way that works on the PSP, but not in PPSSPP. The reason is we currently have different allocation semantics.

If it affects this game (assuming I'm right), it can affect others...

The PSP maintains a freelist and uses 8-byte blocks for allocation. Here's how it basically looks:

struct VplBlock {
    VplBlock *next;
    u32 sizeDiv8;
};

struct VplHeader {
    void *start;
    void *startAgain;
    void *startPlusSeven;
    u32 totalSizeMinus8; // or offset of last block?
    u32 allocatedDiv8;
    VplBlock *nextFreeBlock;
    VplBlock bottomBlock;
};

The VplHeader is found at the start of the vpl (the first 0x20 bytes which are not allocatable.) Going from the bottom upward, it's easy enough to list all blocks using sizeDiv8. The nextFreeBlock is usually at the top and goes downward using a simple linked list of only free blocks. next on a block that has been allocated points to startPlusSeven - maybe it's +7 to cause an alignment fault? Note also that the "size" (totalSizeMinus8) is not divided by 8.

Currently, we always allocate from the top down. This means we more eagerly reuse blocks than a freelist algorithm would. This may fragment memory better (providing more contiguous free blocks), depending on usage, but is also slower.

So I guess we could try changing the allocation strategy.

I've also tried to implement SMALLEST, and found bugs in our current allocation prioritization (namely, the most common method, FIFO, was treated as SMALLEST.) But further looks at logs to this game revealed that it only allocates from one thread, so it probably doesn't matter.

-[Unknown]

[unknownbrackets]

Ugh. sceKernelTryAllocateVpl() seems to allocate differently than sceKernelAllocateVpl().

Oh well, I've gone ahead and implemented it (not try yet, or I have a bug if it does use the same algorithm...) I'm pretty sure it'll be faster for Pangya, probably. Let's hope it helps this game.

-[Unknown]