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

Allocate memory better by @unknownbrackets #8043

Merged
merged 7 commits into from Oct 14, 2015

Conversation

sum2012
Copy link
Collaborator

@sum2012 sum2012 commented Oct 9, 2015

This pick in @unknownbrackets module branch add 1 crash fix
please note that this pull request also remove the cheat address hack for Gods Eater Burst
Fix #5638

unknownbrackets and others added 5 commits October 9, 2015 20:08
This allows other, small allocates to fit in these spaces, which happens
in some games (like Gods Eater Burst.)
It's wrong now.  Although the memory is still not being allocated exactly
the same, it's much closer.
@unknownbrackets
Copy link
Collaborator

We should merge this after 1.1.1 imho. Also might want to double check save states (I can later), been a while since I looked at this branch.

Thanks @sum2012 and @hrydgard for fixing my dumb typo. Can't believe I missed it...

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Oct 9, 2015

Yes, let's wait until after 1.1.1 (which I will probably release this weekend, the ARM64 bug that I have now fixed is pretty bad).

@sum2012
Copy link
Collaborator Author

sum2012 commented Oct 9, 2015

Not sure why VS2012 don't raise crash :)

@unknownbrackets
Copy link
Collaborator

FWIW I made some small tweaks on my branch:
hrydgard:master...unknownbrackets:modules

I think that to be accurate, we might want to identify the loaded sceAtrac module, and return the context pointers from there. They seem to live in user memory allocated with the module prx (e.g. in its data segment or whatever.)

Also, I think they are in fixed places, e.g. id=3 will always be in the same place, even if I deallocate the atrac ID and then reallocate it. It's possible something might accidentally depend on this...

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented Oct 12, 2015

@unknownbrackets done

@@ -1697,27 +1699,19 @@ static u32 sceKernelLoadModule(const char *name, u32 flags, u32 optionAddr)
if (!module) {
if (magic == 0x46535000) {
ERROR_LOG(LOADER, "Game tried to load an SFO as a module. Go figure? Magic = %08x", magic);
return -1;
// TODO: What's actually going on here?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is Tekken 6 and Soul Calibur being silly and loading all files in a directory as modules, including the SFO file that happens to sit around there, IIRC.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right but I don't believe that the error response on real firmware is -1. If it is it's probably at least for a larger class of error than just these magic bytes.

IIRC, I specifically tested an SFO and got a different response, but that different response breaks Tekken 6 or Soul Calibur or whatever it was.

-[Unknown]

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, right, I remember that..

@hrydgard
Copy link
Owner

OK, time to merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Grand Theft Auto Vice City Stories Crashed after intro video (Chinese patched version)
3 participants