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]... > 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.) > > > 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 |
In reply to this post by talios@gmail.com
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] |
In reply to this post by Don Rylander-3
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.... |
Free forum by Nabble | Edit this page |