Dolphin "crash" at startup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dolphin "crash" at startup

Joseph Frippiat-2
Hi,

When I start Dolphin XP Pro with my image, a debug window opens with this
message :

--- Message begin ---
11:01:49, dimanche 26 décembre 2004: 'UndefinedObject does not understand
#value2Log'
UndefinedObject(Object)>>doesNotUnderstand:
ValueAspectAdaptor>>getValue
ValueAspectAdaptor>>value
TextEdit(ValueConvertingControlView)>>refreshContents
TextEdit>>refreshContents
TextEdit(View)>>onModelChanged
TextEdit(ValueConvertingControlView)>>onFullyCreated
TextEdit>>onFullyCreated
ShellView(View)>>wmParentNotify:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
TextEdit(View)>>basicCreateAt:extent:
TextEdit(View)>>createAt:extent:
MessageSend(MessageSendAbstract)>>value
[] in MessageSequence(MessageSequenceAbstract)>>value
OrderedCollection>>do:
MessageSequence>>messagesDo:
MessageSequence(MessageSequenceAbstract)>>value
TextEdit(View)>>state:
ViewState>>restore
[] in ViewState>>restore
OrderedCollection>>do:
ViewState>>restore
[] in DevelopmentSessionManager(GUISessionManager)>>restoreWindowState
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in DevelopmentSessionManager(GUISessionManager)>>restoreWindowState
OrderedCollection>>do:
DevelopmentSessionManager(GUISessionManager)>>restoreWindowState
[] in DevelopmentSessionManager(GUISessionManager)>>basicTertiaryStartup
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
DevelopmentSessionManager(GUISessionManager)>>basicTertiaryStartup
DevelopmentSessionManager(SessionManager)>>tertiaryStartup
DevelopmentSessionManager(GUISessionManager)>>tertiaryStartup
DevelopmentSessionManager>>tertiaryStartup
[] in DevelopmentSessionManager(SessionManager)>>onStartup:
BlockClosure>>ensure:
[] in DevelopmentSessionManager(SessionManager)>>onStartup:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
DevelopmentSessionManager(SessionManager)>>onStartup:
ProcessorScheduler>>onStartup:
 --- Message end ---

If I don't click fast enough on a button (terminate or debug or ...) then
the debug window disappears and, as I discovered, Dolphin continue to run in
the background whitout any window to interact with.  The only choice I have
is to open the Windows Task Manager and to end the process Dolphin.exe .

After some investigations, I discovered that there is 2 "ghost" instances of
my DailyLoggerShell.  To get rid of them, I tried to put all their variables
to nil, but it didn't do the job.

How can I kill (yes , now I really mean it ;-) ) those instances ?

Thanks

Joseph


Reply | Threaded
Open this post in threaded view
|

Re: Dolphin "crash" at startup

Chris Uppal-3
Joseph Frippiat wrote:

> After some investigations, I discovered that there is 2 "ghost" instances
> of my DailyLoggerShell.  To get rid of them, I tried to put all their
> variables to nil, but it didn't do the job.

There is a general nuisance when developing new Dolphin windows, which is that
many kinds of error during initialisation of a MVP shell will result in zombie
View hanging around (what I think you are calling a ghost instance).  A zombie
is a view that isn't #show-ed, but which is still "real".  It's perfectly legal
for views to be hidden in that way (that's how the Transcript works) but most
often such views are zombies.  A typical error that gives rise to a zombie is
terminating a walkback during window initialisation (#createComponents,
#onViewOpened, etc, etc) which can leave the MVP window half-complete.  Because
this happens during initialisation, the application window is often left in a
state that "should not" be possible, such as having a nil #model, and that can
cause problems when you re-start an image, since each window will attempt to
re-build itself as the image starts up.  If one or more of the windows is in a
state such that it /can't/ rebuild itself (e.g. because the code assumes that
the model is not nil -- as seems to be the case in your example) then the
zombie(s) will cause walkbacks during startup.

BTW: does anyone else find that they end up with zombies more often in the last
year or so ?  I quite often find myself with 5-10 zombies when I would have
expected -- at the very most -- one or two.

There are various ways to get rid of them.

Normally, they will show up in the "window" menu of any Dolphin tool; they will
have "(hidden)" after their name.  Just selecting that item from the menu will
normally show the View, which can then be killed just like any other window.

If that doesn't work (and it may not, especially if you have been trying to
"kill" them in other ways already) then you can try:

    DailyLoggerShell allInstances do: [:each | each view exit].

Another step up the ladder would be to do a "panic", which will kill all the
Dolphin windows, and then re-open the main system-folder window.

If even /that/ doesn't work, then it's time to get nasty.  But I won't go into
that yet -- one of the above should fix it.

    -- chris