Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bhavin192 opened this issue Aug 30, 2013 · 15 comments

Comments

Projects
None yet
3 participants
@bhavin192
Copy link
Contributor

commented Aug 30, 2013

@unknownbrackets

This comment has been minimized.

Copy link
Collaborator

commented Aug 30, 2013

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

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

-[Unknown]

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2013

Downloading ...
Was using 205

@takeshineale128

This comment has been minimized.

Copy link

commented Aug 30, 2013

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

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2013

Yes it is still crashing

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Aug 30, 2013

@unknownbrackets

This comment has been minimized.

Copy link
Collaborator

commented Oct 17, 2013

Any change with this game?

-[Unknown]

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2013

Still crashing at same place

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2013

@unknownbrackets

tried with 1954 same result

@unknownbrackets

This comment has been minimized.

Copy link
Collaborator

commented Jan 5, 2014

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

-[Unknown]

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2014

@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

This comment has been minimized.

Copy link
Collaborator

commented Jan 6, 2014

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

-[Unknown]

@unknownbrackets

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2014

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

-[Unknown]

@bhavin192

This comment has been minimized.

Copy link
Contributor Author

commented Jan 31, 2014

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 1, 2014

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 2, 2014

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]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.