DolphinToGo DLL running image stripper and crashing...

Hey all,

I've got this weird stacktrace being submitted from some users ( this is
just a snippet as the things darn HUGE ):

************************** Dolphin Virtual Machine Dump Report ***************************

14:48:15 PM, 1/06/2005: Recursion too deep; the stack overflowed. (16r3E9: Recursion too deep; the stack overflowed.)

*----> VM Context <----*
Process: {09D40004:size 33856 words, suspended frame 09D60FED, priority 8, callbacks 0
last failure 2:nil, FPE mask 3, thread nil}
Active Method: SessionManager>>logError:
IP: 09C53BBD (13)
SP: 09D611B0
BP: 09D61188 (33873)
ActiveFrame: {09D6118C: cf 09D61171, sp 09D611A0, bp 09D61188, ip 5, GUIAXDllSessionManager(SessionManager)>>logError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a Win32Error


.....several thousand lines snipped.....

New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: #dump:path:stackDepth:walkbackDepth:



{09D40254: cf 09D40239, sp 09D40264, bp 09D30438, ip 43, [] in GUIAXDllSessionManager(SessionManager)>>onStartup:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a Array

{09D40238: cf 09D40225, sp 09D40250, bp 09D30470, ip 11, BlockClosure>>ifCurtailed:}
        receiver: [] @ 1d88006 in nil
        arg[0]: [] @ 4d in SessionManager>>onStartup:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{09D40224: cf 09D40205, sp 09D40234, bp 09D4021C, ip 4, BlockClosure>>ensure:}
        receiver: [] @ 23 in SessionManager>>onStartup:
        arg[0]: [] @ 4d in SessionManager>>onStartup:
        temp[0]: nil

{09D40204: cf 09D401F1, sp 09D40214, bp 09D30438, ip 56, GUIAXDllSessionManager(SessionManager)>>onStartup:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a Array

{09D401F0: cf 09D401D5, sp 09D40200, bp 09D401EC, ip b, ProcessorScheduler>>onStartup:}
        receiver: a ProcessorScheduler
        arg[0]: a Array

{09D401D4: cf 09D401B9, sp 09D401E4, bp 09D303C8, ip b, [] in ProcessorScheduler>>vmi:list:no:with:}
        receiver: a ProcessorScheduler
        arg[0]: 17c
        arg[1]: nil
        arg[2]: 8
        arg[3]: a Array

{09D401B8: cf 09D401A5, sp 09D401D0, bp 09D30400, ip 11, BlockClosure>>ifCurtailed:}
        receiver: [] @ 1d88006 in nil
        arg[0]: [] @ 10 in ProcessorScheduler>>vmi:list:no:with:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{09D401A4: cf 09D40181, sp 09D401B4, bp 09D303C8, ip 14, ProcessorScheduler>>vmi:list:no:with:}
        receiver: a ProcessorScheduler
        arg[0]: 17c
        arg[1]: nil
        arg[2]: 8
        arg[3]: a Array

{09D40180: cf 09D4015D, sp 09D401A0, bp 09D40174, ip 2f, BatchAXDllImageStripper(ImageStripper)>>snapshot:}
        receiver: a BatchAXDllImageStripper
        arg[0]: 'C:\code\dolphin\dolphin\build\SMSComposer.tmp'
        temp[0]: a GUIAXDllSessionManager
        temp[1]: 6

{09D4015C: cf 09D40149, sp 09D4016C, bp 09D2DB78, ip f, BatchAXDllImageStripper>>saveExecutable:}
        receiver: a BatchAXDllImageStripper
        arg[0]: 'C:\code\dolphin\dolphin\build\SMSComposer.dll'
        temp[0]: 'C:\code\dolphin\dolphin\build\SMSComposer.tmp'
        temp[1]: nil
        temp[2]: true
        temp[3]: nil
        temp[4]: nil

{09D40148: cf 09D40131, sp 09D40158, bp 09D40148, ip 6, MessageSend(MessageSendAbstract)>>value}



        receiver: a MessageSend





Why on earth would a stripped executable want to continue trying to
strip and save itself?  This is using Dolphin 5 ( patch level 3 i think?
) - this would seem a pretty major "bug".  I think I asked about this
before when it came up an earlier time but never seemed to find any
resolution. ( *Google Groups reference - http://tinyurl.com/c344y )*.

 From reading that old thread, I never had the end of the stack trace,
which I seem to have now, anyone got any ideas/solutions?

Mark

Mark,
"Mark Derricutt" <[hidden email]> wrote in message
news:[hidden email]... [...]
>
> Why on earth would a stripped executable want to continue trying to strip
> and save itself?  This is using Dolphin 5 ( patch level 3 i think?
[...]

It's not really that the image is still stripping itself.  Blair explained
in a thread last August
(http://groups-beta.google.com/group/comp.lang.smalltalk.dolphin/browse_thread/thread/642958cc23bc3485/6e61d546534ed304?q=%22solution+or+workaround%22+group:comp.lang.smalltalk.dolphin+author:Blair+author:McGlashan&rnum=1&hl=en#6e61d546534ed304)
that:

<quote>
When an image starts up, it runs initially on the Process that was executing
when the image snapshot was made, i.e. it just continues from where it
suspended itself as a saved image.
</quote>

So, it's not as weird as it looks.

Fascinating as that is, it doesn't do much to solve your actual problem.
Per your January problem, my experience coincides with Chris Uppal's:
recursion problems usually get caused by something going wrong in the error
reporting process.  Assuming it's something similar to what you asked about
in January, it looks like there was an HRESULTError involved, too.  I've had
situations where, in trying to report the error, I found myself using
something from the HRESULTError that wasn't actually available for use.
IIRC (big if!), this is something that Outlook sometimes does, returning
some semi-valid object that, if you try to use it as you'd normally use it,
simply generates additional errors.

HTH,

Don

Mark,

> I've got this weird stacktrace being submitted from some users ( this is
> just a snippet as the things darn HUGE ):

True, but it contains a lot of useful information, so it's better than
just a crash w/ no feedback.


> Why on earth would a stripped executable want to continue trying to
> strip and save itself?  

That looks strange at first, but it's really what happens - the image
rips itself apart and then jumps into the exe file after throwing the
stub in there; the exe wakes up with a hangover from it.  How's that for
technical writing :)


 > This is using Dolphin 5 ( patch level 3 i think?
> ) - this would seem a pretty major "bug".  I think I asked about this
> before when it came up an earlier time but never seemed to find any
> resolution. ( *Google Groups reference - http://tinyurl.com/c344y )*.

I agree with Chris that this looks like a recursive problem with error
reporting.

Blair, please take a look at #InterfaceSupportsErrorInfo:; it uses an
hresult return type, which might be causing an exception when it is not
wanted???

Mark, failing that, you might use Trace and DebugView to look inside
your startup code to see just where it is getting kicked out.  It's not
a fun way to debug, but it eventually works.  Also, see if Ghoul can
parse your error log; if it can, it might be very helpful.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Don Rylander wrote:

>Fascinating as that is, it doesn't do much to solve your actual problem.
>Per your January problem, my experience coincides with Chris Uppal's:
>recursion problems usually get caused by something going wrong in the error
>  
>
I overrode that method in my session manager and now my app seems to run
under VMware, where it was crashing earlier - but in a slightly
different manner to what the client was seeing.  Will give that a bash
in the wild on a select user....