<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This looks quite promising.<br><br>Robert Megone<br><br><br><br><br>> From: scummvm-devel-request@lists.sourceforge.net<br>> Subject: Scummvm-devel Digest, Vol 35, Issue 5<br>> To: scummvm-devel@lists.sourceforge.net<br>> Date: Thu, 9 Apr 2009 08:04:28 +0000<br>> <br>> Send Scummvm-devel mailing list submissions to<br>>    scummvm-devel@lists.sourceforge.net<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>>        https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br>> or, via email, send a message with subject or body 'help' to<br>>     scummvm-devel-request@lists.sourceforge.net<br>> <br>> You can reach the person managing the list at<br>>    scummvm-devel-owner@lists.sourceforge.net<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of Scummvm-devel digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>>    1. Re: Fwd:  PS2 : stack madness (sunmax@libero.it)<br>>    2. Re: Fwd:  PS2 : stack madness (Willem Jan Palenstijn)<br>>    3. Re: Fwd:  PS2 : stack madness (sunmax@libero.it)<br>>    4. Re: Fwd:  PS2 : stack madness (Willem Jan Palenstijn)<br>>    5. Re: Fwd:  PS2 : stack madness (sunmax@libero.it)<br>>    6. Re: Fwd:  PS2 : stack madness (Willem Jan Palenstijn)<br>>    7. ida dosbox plugin (Pawel Kolodziejski)<br>>    8. Re: SCI: _k_disable_delete_for_now () (lskovlun@image.dk)<br>>    9. Re: Cruise for a Corpse music handling (Gregory Montoir)<br>>   10. Re: Cruise for a Corpse music handling (Paul Gilbert)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Tue,  7 Apr 2009 22:48:52 +0200<br>> From: "sunmax\@libero\.it" <sunmax@libero.it><br>> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness<br>> To: "bertrand_augereau" <bertrand_augereau@yahoo.fr><br>> Cc: max <max@quendi.de>, scummvm-devel<br>>   <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <KHR0HG$EF4C4003CC6567D1549A3124B56E46D5@libero.it><br>> Content-Type: text/plain; charset=iso-8859-1<br>> <br>> Hi there!<br>> <br>> > Is there a big stack allocation somewhere related?<br>> <br>> This is one of my possible culprits too - to see if something<br>> in-between 0.12.x to 0.13.0 went stack-on-steroids.<br>> <br>> Any idea?<br>> <br>> <br>> > For instance a templated stack array or a malloca for storing<br>> > a few temporary lines or something?<br>> <br>> In MADE moving few stack items to heap made it PS2-friendly<br>> (well, kinda: I have to find a way to improve performance on<br>> our beloved console!).<br>> <br>> On the other hand we want to be careful, cause I am afraid<br>> that doing this (I mean: moving the possible out of the stack)<br>> we could be just dancing around the bug, instead of squeezing it.<br>> <br>> Thanks!<br>>  -max<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 2<br>> Date: Tue, 7 Apr 2009 21:08:01 +0000<br>> From: Willem Jan Palenstijn <wjp@usecode.org><br>> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness<br>> To: "sunmax@libero.it" <sunmax@libero.it><br>> Cc: max <max@quendi.de>, scummvm-devel<br>>     <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <20090407210801.GA30052@usecode.org><br>> Content-Type: text/plain; charset=us-ascii<br>> <br>> On Tue, Apr 07, 2009 at 10:48:52PM +0200, sunmax@libero.it wrote:<br>> > Hi there!<br>> > <br>> > > Is there a big stack allocation somewhere related?<br>> > <br>> > This is one of my possible culprits too - to see if something<br>> > in-between 0.12.x to 0.13.0 went stack-on-steroids.<br>> > <br>> > Any idea?<br>> <br>> I see no large stack allocations when starting COMI and opening the F5 and<br>> Ctrl-F5 menus.<br>> <br>> (Testing method: I told valgrind to make a large block of memory 1024<br>> bytes below the stack pointer at the start of scummvm_main inaccessible.<br>> This triggered no errors. I'm using 64 bit linux.)<br>> <br>> <br>> -Willem Jan<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 3<br>> Date: Tue,  7 Apr 2009 23:17:38 +0200<br>> From: "sunmax\@libero\.it" <sunmax@libero.it><br>> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness<br>> To: "wjp" <wjp@usecode.org><br>> Cc: scummvm-devel <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <KHR1TE$907D37C9B5C0034B4D4C0B80A56BEC74@libero.it><br>> Content-Type: text/plain; charset=iso-8859-1<br>> <br>> Hi Willem!<br>> <br>> Thanks for following up!<br>> <br>> > I see no large stack allocations when starting COMI<br>> <br>> Note that "big" in PS2 world is a signed word: 32 Kb ;-)<br>> <br>> <br>> > and opening the F5 and Ctrl-F5 menus.<br>> <br>> Sorry about this! That's was the first version of the report,<br>> it actually happens independently from calling the GMM.<br>> <br>> It's likely somewhere in GuiManager::runLoop or just a bit earlier.<br>> <br>> Which scaler are you using?<br>> <br>> Thanks!<br>>  -max<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 4<br>> Date: Tue, 7 Apr 2009 21:38:35 +0000<br>> From: Willem Jan Palenstijn <wjp@usecode.org><br>> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness<br>> To: "sunmax@libero.it" <sunmax@libero.it><br>> Cc: scummvm-devel <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <20090407213835.GB30052@usecode.org><br>> Content-Type: text/plain; charset=us-ascii<br>> <br>> On Tue, Apr 07, 2009 at 11:17:38PM +0200, sunmax@libero.it wrote:<br>> > Which scaler are you using?<br>> <br>> No scaler, just running in native 640x480. It behaves the same with<br>> '-g 2x', though.<br>> <br>> <br>> I noticed in another mail that you found a place where SP was bogus. Did<br>> you try putting lots of printfs of the stack pointer (or of a local<br>> stack variable) just before that? That might help pin down the exact<br>> code that corrupts the stack. As Max (Horn) mentioned, this could be<br>> done indirectly by a return from a function call.<br>> <br>> That would really help, since it's very hard to analyze bugs like this<br>> without run-time information.<br>> <br>> <br>> Did you already track down what caused the menu to be placed near the<br>> upper-left corner instead of in the center, by the way? (The issue you<br>> illustrated with a photo on March 8.) Maybe that would give a clue<br>> too...<br>> <br>> -Willem Jan<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 5<br>> Date: Wed,  8 Apr 2009 05:59:09 +0200<br>> From: "sunmax\@libero\.it" <sunmax@libero.it><br>> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness<br>> To: "wjp" <wjp@usecode.org><br>> Cc: scummvm-devel <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <KHRKEL$335957A1F7C768C8C1455E51DA5DA546@libero.it><br>> Content-Type: text/plain; charset=iso-8859-1<br>> <br>> Hi there Willem!<br>> <br>> > > Which scaler are you using?<br>> > <br>> > No scaler, just running in native 640x480.<br>> <br>> Got it.<br>> <br>> Is there any way you can start your GUI 320x200 and then let<br>> the Scumm engine to crank it up to 640x480 before starting<br>> COMI and see if this makes a difference?<br>> <br>> <br>> > I noticed in another mail that you found a place where SP was bogus<br>> <br>> Yes.<br>> <br>> As in most of stack related issues, just moving functions or adding<br>> new ones can cause the crash to move. The good things of our crash<br>> is that's predictable:<br>> <br>> given a certain code base and compiler settings it will always<br>> crash at the same point. On the other hand when we keep adding<br>> new variables on the stack and more printf, we "lose" it:<br>> it starts crashing somewhere else :-(<br>> <br>> Obviously the point where it crashes is not the cause but just<br>> a "side effect" of the real bug.<br>> <br>> <br>> > you try putting lots of printfs of the stack pointer (or of a local<br>> > stack variable) just before that?<br>> <br>> I was able to trace it back up to guiManager::runLoop but then I<br>> "lose" it from there - having gdb would definitely make a diff ;-)<br>> <br>> It only happens with 640x480 (but that could be a red herring).<br>> <br>> <br>> > Did you already track down what caused the menu to be placed near<br>> > the upper-left corner instead of in the center, by the way?<br>> <br>> No, but I am sure they are related. It seems the GUI engine still<br>> "thinks" the screens is 320x200 and paints in the corresponding<br>> corner, that's why I was asking to see if you can start 320x200<br>> and then when you start COMI see if things make a difference<br>> going up to 640x480 on the fly.<br>> <br>> Thanks for the great support guys!<br>>  -max<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 6<br>> Date: Wed, 8 Apr 2009 08:22:31 +0000<br>> From: Willem Jan Palenstijn <wjp@usecode.org><br>> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness<br>> To: "sunmax@libero.it" <sunmax@libero.it><br>> Cc: scummvm-devel <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <20090408082231.GC30052@usecode.org><br>> Content-Type: text/plain; charset=us-ascii<br>> <br>> On Wed, Apr 08, 2009 at 05:59:09AM +0200, sunmax@libero.it wrote:<br>> > Is there any way you can start your GUI 320x200 and then let<br>> > the Scumm engine to crank it up to 640x480 before starting<br>> > COMI and see if this makes a difference?<br>> <br>> Running scummvm with '-g 1x' (so that it runs in 320x200) and then<br>> starting COMI from the launcher shows nothing strange, and no large<br>> stack increase either.<br>> <br>> <br>> > given a certain code base and compiler settings it will always<br>> > crash at the same point. On the other hand when we keep adding<br>> > new variables on the stack and more printf, we "lose" it:<br>> > it starts crashing somewhere else :-(<br>> <br>> That itself might also give a clue. This is a bit of a longshot, but it<br>> might work:<br>> <br>> <br>> Take the function where adding printfs makes you "lose" the crash.<br>> <br>> At the very beginning of that function, add some code:<br>> <br>> int canary[64];<br>> for (int ci=0; ci<64; ++ci) canary[i] = 0x12345678;<br>> <br>> Then after every function call in that function (and maybe in other<br>> places too), put a check:<br>> <br>> for (int ci=0; ci<64; ++ci) assert(canary[i] == 0x12345678);<br>> <br>> <br>> If it shows that a specific function call corrupted the canary-variable,<br>> you can then repeat this procedure inside that function. That _might_<br>> give enough info to find the guilty code.<br>> <br>> <br>> <br>> One other option: does your gcc support the option -fstack-protector-all ?<br>> <br>> <br>> <br>> -Willem Jan<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 7<br>> Date: Wed, 8 Apr 2009 17:16:24 +0200<br>> From: Pawel Kolodziejski <aquadran@xtr.net.pl><br>> Subject: [Scummvm-devel] ida dosbox plugin<br>> To: scummvm-devel <scummvm-devel@lists.sourceforge.net><br>> Message-ID: <2F434436-EAFD-4326-B980-E5F830EA48B5@xtr.net.pl><br>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes<br>> <br>> Hi everyone,<br>> <br>> I found today interested info about released ida pro plugin for  <br>> dosbox :)<br>> <br>> http://efry.users.sourceforge.net/idados/<br>> and info from:<br>> http://www.hex-rays.com/forum/viewtopic.php?f=8&t=2286<br>> <br>> Pawel<br>> <br>> <br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 8<br>> Date: Wed, 8 Apr 2009 18:41:02 +0200 (CEST)<br>> From: lskovlun@image.dk<br>> Subject: Re: [Scummvm-devel] SCI: _k_disable_delete_for_now ()<br>> To: "Max Horn" <max@quendi.de><br>> Cc: scummvm-devel@lists.sourceforge.net, Lars Skovlund<br>>  <lskovlun@image.dk><br>> Message-ID:<br>>       <49902.80.164.116.14.1239208862.squirrel@webmail.tiscali.dk><br>> Content-Type: text/plain;charset=iso-8859-1<br>> <br>> > That was me. (The SVN "annotate" feature is a great way to find out<br>> > who added a certain piece of code:<br>> > <http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/engines/sci/engine/kgraphics.cpp?view=annotate<br>> >  >).<br>> <br>> I thought it was you, actually.<br>> <br>> > Yeah, well, from what you wrote, that's actually exactly what I would<br>> > call a "workaround" for buggy or bad behavior in the original game<br>> > resp. engine... ;-). Anyway, the comment was really referring to the<br>> > "if()" block it preceded, but having looked closer now, I think the<br>> > whole function deserves a good explanatory comment :-). I guess we can<br>> > just copy the text of your email for that.<br>> <br>> Can't argue with that.<br>> <br>> >> It sounds like we could intercept file opens of *SG.DIR and<br>> >> construct an<br>> >> appropriate file on-the-fly. Similarly we could intercept truncates of<br>> >> SCI-style savegame files to actually delete the appropriate savegame.<br>> >> Would this work?<br>> ><br>> > It would be possible to do what you describe, I think. Whether it<br>> > would work... Lars? :) Or, well, let's just try it. I'll take a look<br>> > at this one day, but you folks shouldn't wait for me, I am not going<br>> > to do much before my PhD defense in less than two weeks ;).<br>> <br>> As stated elsewhere, we are already doing something like it - but without<br>> the interception of calls.<br>> This solution would certainly be compatible with "most" games, but then<br>> again, we are already compatible with "most" games.<br>> <br>> > I don't see any reason right now to replace the save/load UI of<br>> > FreeSCI, and that's not "the plan" as far as I am concerned.<br>> <br>> OK.<br>> <br>> > the ability to quit<br>> <br>> Possible.<br>> <br>> > return to the launcher<br>> <br>> Possible.<br>> <br>> >  access the about dialog (with credits)<br>> <br>> Heuristically possible (we know what the menus contain, and they are<br>> fairly consistent with the leftmost "Sierra logo" menu containing about<br>> and help; could be messy for non-english versions)<br>> <br>> , and in the future, help dialogs. Well,<br>> > and load & save dialogs if the engine supports this.<br>> <br>> I don't think we can guarantee that for all games. For some, we can.<br>> <br>> > (Another very nice AEF is the ability to load savestates from the<br>> > command line. Very handy when debugging stuff.)<br>> <br>> We already had this in FreeSCI, so this is certainly possible.<br>> <br>> > Aha? Well, can't comment, don't know that game at all... If there are<br>> > issues, I hope they'll eventually be logged and then addressed :)<br>> <br>> This is Walter's domain.<br>> <br>> Lars<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 9<br>> Date: Wed, 08 Apr 2009 23:40:58 +0200<br>> From: Gregory Montoir <cyx@users.sourceforge.net><br>> Subject: Re: [Scummvm-devel] Cruise for a Corpse music handling<br>> To: scummvm-devel@lists.sourceforge.net<br>> Message-ID: <49DD19EA.2030100@users.sourceforge.net><br>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>> <br>> <br>> Hi,<br>> <br>> > Just yesterday I committed the beginnings of music support for Cruise <br>> > for a Corpse (Cruise engine). As many of you will now, music handling is <br>> > one area in particular that I'm not very familiar with, so I'm hoping <br>> > that someone else will be able to complete support on top of the basics <br>> > I've already added. At the moment, I've implemented a skeleton <br>> > MusicPlayer class which loads the raw data associated with a given song, <br>> > and set in place calls to it from the appropriate library routines.<br>> > <br>> > Hopefully someone more familiar with the common music structures will be <br>> > able to recognise what kind of encoding it's using, and be able to <br>> > complete the implementation.<br>> <br>> operation stealth and cruise use a very similar (if not the same) sound <br>> code ; soundfx modules with custom pcspeaker/adlib/roland instruments. <br>> So looking at cine/sound.cpp may be a good starting point.<br>> <br>> Hope this helps.<br>> Gregory<br>> <br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 10<br>> Date: Thu, 9 Apr 2009 18:04:25 +1000<br>> From: Paul Gilbert <paulfgilbert@gmail.com><br>> Subject: Re: [Scummvm-devel] Cruise for a Corpse music handling<br>> To: ScummVM devel <scummvm-devel@lists.sourceforge.net><br>> Message-ID:<br>>      <a3b832620904090104k65c98e2do3165b19416d876b@mail.gmail.com><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> On Thu, Apr 9, 2009 at 7:40 AM, Gregory Montoir<br>> <cyx@users.sourceforge.net>wrote:<br>> <br>> ><br>> > operation stealth and cruise use a very similar (if not the same) sound<br>> > code ; soundfx modules with custom pcspeaker/adlib/roland instruments.<br>> > So looking at cine/sound.cpp may be a good starting point.<br>> ><br>> > Hope this helps.<br>> > Gregory<br>> ><br>> <br>> Thanks for the tip - it certainly will simplify things if I can just re-use<br>> code already written for ScummVM. I'll have a look into it.<br>> <br>> Paul.<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> <br>> ------------------------------<br>> <br>> ------------------------------------------------------------------------------<br>> This SF.net email is sponsored by:<br>> High Quality Requirements in a Collaborative Environment.<br>> Download a free trial of Rational Requirements Composer Now!<br>> http://p.sf.net/sfu/www-ibm-com<br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> Scummvm-devel mailing list<br>> Scummvm-devel@lists.sourceforge.net<br>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br>> <br>> <br>> End of Scummvm-devel Digest, Vol 35, Issue 5<br>> ********************************************<br><br /><hr />Windows Live Hotmail just got better. <a href='http://clk.atdmt.com/UKM/go/134665311/direct/01/' target='_new'>Find out more!</a></body>
</html>