[Scummvm-devel] Fwd: PS2: stack overlfow

[sunmax at libero.it]

Hi Andre!

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.

Thanks!
 -max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comi-menu.jpg
Type: image/jpeg
Size: 183736 bytes
Desc: not available
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090308/1c8e8dd5/attachment.jpg>