[Scummvm-devel] Fwd: PS2: stack overlfow
sunmax at libero.it
sunmax at libero.it
Sun Mar 8 20:14:21 CET 2009
Thanks for stepping in on this issue!
> I'm sort of in the same boat on the Wii side.
Glad (or should I say sad?) to see that somebody else
share my pain ;-)
> One example: COMI on the Gamecube (same port as Wii), which has
> 24mb of ram, ran into the memory limit issue on 0.13.0.
I feel richer now, cause I have 32mb on PS2 ;-)
> All engined enabled per default from the configure script
That's was my first culprit.
Cause I was building bunch of them in the Makefile.ps2, now
since I am investigating this issue in COMI (and the previous
one in MADE) I just have a single engine at at time compiled in.
This means that ELF I am uploading to PS2 is ~5 MB.
Which brought me to think that it's not an out of memory
issue, or heap/stack overlap, but a memory corruption,
like when you go beyond the last element into an array,
or pass some bogus structure pointer to a procedure.
I might be wrong, but I'd like to hear your opinion as
an embedded ScummVM porter.
> There's the usual memory area, and the stack is located at the
> "end" of the memory, that's defined in the linker script.
Ditto on PS2. I even modded the linker script, once I reduced
the ELf size to 5 MB, to extend the heap to a 8X size, but did
not help :-(
So my only guess left is that something is writing to an addr
in the heap (and it should not) and then all hell breaks loose.
> As ScummVM requests more and more memory, this pointer and the end
> of the stack (the stack grows downwards) get closer to each other.
Yeah, that's was my first guess. But now there are > 20 MB
between the heap and the stack ends when we start COMI, so
I would be surprised it they overlap. I even tried disabling
caching in our Ps2Nodes and all the tricks of the DS, like
disabling fancy themes, default save manager, etc. to be as
memory savvy as possible. But it did not help :-(
> situations where code writes into the stack's memory due to an
> uninitialized pointer. Since we do not have virtual memory with any
> protections, this is valid and doesn't yield an error (I can just do
> "*(stackptr + x) = y").
That's what's happening here (I think). How do we lock it down?
a) we don't have a working gdb on PS2 - if we did, how would we
use it to trace this kind of condition?
b) what I am doing is using ee-addr2line against the instruction
counter when it bombs and I was able to see that a certain
stage the stack is corrupted, but then to go back from there
to the point where it got corrupted it's a whole other story...
What would you suggest ?
c) what I was able to see disassembling PS2 ScummVM ELF is that
when you call the GMM in COMI, you hit a common/stack.h @ 107
where both "_stack" and "s" have unrealistic values.
That top is called by CursorManager::isVisible() which is
called by CursorManager::pushCursor which is called by
setupCursor() in GuiManager::runLoop
[as you see I had a hell of a time building a backtrace by
hand just with a MIPS disassembler...]
Now if we comment that setupCursor() we get dialog to show
(of course we lose the cursor in the main launcher too...),
but then if you press on any of the button the widget handler
bombs again (this time in the strcmp in C lib), which suggests
that things are already messed up before setupCursor().
d) if I use PS2 0.12.0 code in 0.13.x (with the minimal set
of mods to get it to compile) we hit the same issue with
COMI/GMM. On the other if I back port 0.13.x to 0.12.0,
we run smooth without any corruption/crash. This leave
us with just a few culprits:
- the issue is outside the PS2 code (unlikely)
- the issue is caused by the PS2 code not complying to some
of the new 0.13.x GUI requirements (maybe one of our funcs
is broken, in this case I would appreciate one of the GUI
gurus to have a quick glimpse and see if this is the case)
- the issue is caused by the bad interaction between the
vintage PS2 compiler and the new hashmap code. Is there
any way we can test 0.13.x but with the 0.12.0 hashmap?
e) there is something fishy on the way the dialog appears (after
we hacked out setupCursor) it's misplaced in the top-left
quadrant. So something is not right there. I did tried to
reproduce it on my Linux/SDL setup but I am unable to (OTOH
I was unable to get the Help to crash as well there even if
I compile it with the scalers disabled so there is something
on my SDL setup that does not match my PS2 setup). Max Horn
was able to reproduce in no time the Help crash on its setup,
I am waiting to see if he can reproduce the misplaced dialog
too, cause that could spread some light.
I am currently out of ideas. So any suggestion is welcome,
otherwise we will have to deprecate COMI on PS2/0.13.1.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 183736 bytes
Desc: not available
More information about the Scummvm-devel