Shutdown problem with in-process GUI app
Don Rylander
converting to DX6. Whenever the host application (Outlook) shuts down, I
get this error multiple times in a row (the full 28K log is at:
http://a4a.us/FCGProlog.ERRORS.txt):
=========================================================
16:40:41 PM, 4/14/2006: SmallInteger does not understand
#callback:vfn:withArgumentsAt:
*----> VM Context <----*
Process: {0E810004:size 186 words, suspended frame 0E810619, priority 5,
callbacks 1
last failure 0:nil, FPE mask 3, thread nil}
Active Method: SessionManager>>logError:
IP: 04969AE9 (9)
SP: 0E8103CC
BP: 0E8103A0 (216)
ActiveFrame: {0E8103A4: cf 0E810385, sp 0E8103BC, bp 0E8103A0, ip 5,
GUIAXDllSessionManager(SessionManager)>>logError:}
receiver: a GUIAXDllSessionManager
arg[0]: a MessageNotUnderstood
New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: dump:path:stackDepth:walkbackDepth:
=========================================================
By way of clarification, GUIAXDllSessionManager is fairly minimal subclass
of AXDllGUISessionManager (it predates its X6 superclass by a few years, and
it's probably superfluous now, but that's a later phase in the
conversion...).
Any helpful thoughts are greatly appreciated.
TIA,
Don
Blair McGlashan
message news:_q6dncCo8uF3gd3Z...@totallyobjects.com...
> Hello all, I'm having a problem with an in-process app that I'm just
> converting to DX6. Whenever the host application (Outlook) shuts down, I
> get this error multiple times in a row (the full 28K log is at:
> http://a4a.us/FCGProlog.ERRORS.txt):
>
Don, this looks as though a COM interface implemented in Dolphin is being
called after the associated COM object has already gone away - I think this
could be handled better, but that is essentially the problem. If you look at
this entry in the call stack:
{0E810218: cf 0E8101E1, sp 0E810234, bp 0E810204, ip 35,
ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:}
receiver: a ProcessorScheduler
arg[0]: 3
arg[1]: 4
arg[2]: 1
arg[3]: 91288772
arg[4]: 45644278
The first argument is the index into the virtual function table of the COM
function being called. Its a 1-based index, so this is an attempted
invocation of Release() (the first three functions are always
QueryInterface(), AddRef(), and Release()). This suggests that whatever is
holding a reference to the interface (presumably Outlook) is attempting to
clean up, but too late. This could either be due to a reference count error,
or its because the COM shutdown code in Dolphin has already run. I would
suggest you insert some instrumentation in COMInterface>>onExit to trace out
the interfaces that are still referenced when the Dolphin DLL is shutting
down. That might give you a clue as to what Outlook object to free first so
as to get the shutdown order right. Remember that it is often the case with
automation object models that there are circular references, so you need
something to force the COM object network to destruct. Outlook will be doing
this on shutdown, but that might be too late if your Dolphin DLL has already
cleaned everything up.
As a workaround you could prevent the COMInterface>>onExit code from
free'ing up the object. Since the host process is shutting down, you don't
really care if the DLL cleans up properly as the OS will make a good job of
that. It's still possible that this will not work, as when the Release calls
come in from Outlook, the Dolphin image may not be in a valid state to
process them correctly.
Regards
Blair
Don Rylander
[...] I would
> suggest you insert some instrumentation in COMInterface>>onExit to trace
> out the interfaces that are still referenced when the Dolphin DLL is
> shutting down. That might give you a clue as to what Outlook object to
> free first so as to get the shutdown order right. Remember that it is
> often the case with
> As a workaround you could prevent the COMInterface>>onExit code from
> free'ing up the object. Since the host process is shutting down, you don't
> really care if the DLL cleans up properly as the OS will make a good job
> of that. It's still possible that this will not work, as when the Release
> calls come in from Outlook, the Dolphin image may not be in a valid state
> to process them correctly.
Thanks for the quick response. I'll give this a shot first thing on
Monday. Outlook has been a real pain in this respect, as its clean-up
behavior and what it expects (or allows) in-process COM components to do
seems to vary from one update to the next.
Thanks again,
Don
>
> Regards
>
> Blair
>
Don Rylander
to have a few COM objects hanging around when they shouldn't have been. The
problem was masked by the fact that our error occurred in the course of
responding to an AXEventSink event. Using SysInternals' DebugView and
Dolphin's Trace stream (a nice feature I'd never used before) in
COMInterface>>onExit and a couple places in our own code helped track this
down, as well as finding another unrelated issue, too.
Thanks again for your quick and informative reply!
Don