Doesn't work. [Previously: It works! Re: ADK/Lagoon crashes during build]

Sorry for the repetition here, but News.CIS.DFN.DE seems not to have
this thread anymore or else Netscape just can't be convinced to display
it.  As usual, I spoke too soon about things working.

Getting the MIDI configuration right and/or turning off the sound made
when windows open and close did seem to help, but there also seems to be
a problem related to the window manager I use and/or clicking the mouse
on other windows while Dolphin is stripping.  Someone else mentioned the
second problem and it seems to be related to mine.

In the method below, the line

  progClass allInstances do: [:each | each exit].

takes care of removing the progress window from the screen.  Shortly
thereafter, another window/canvas is opened with the "Please wait..."
message.  Since the progress window is the last open window (at least as
far as my window manager is concerned), the manager (prompted by Windows
perhaps) looks for another window to make active and in most cases
switches screens to show that window.  Dolphin doesn't seem to like this
and crashes.  This screen switching or something similar might also be
caused by clicking the mouse on another window as a different user
explained.

The work-around for me is to have other applications running in the same
screen that will get the focus when there are temporarily no more
Dolphin windows.  This prevents the screen switching from happening.  So
far, this work-around has avoided the problem.

Since it's easier to change Dolphin than change the way I work, I tried
moving the canvas message to before the progClasses exit, but that
doesn't help.  A canvas probably isn't something that can get focus.  I
suspect that if a non-modal dialog were shown temporarily it might work,
but that would change some of the stripping strategy.

If anyone can figure out how to make this method impervious to mouse
clicks or screen changes, please let me know.

Thanks.

Keith Alcock



ImageStripper>>destroyAndRemoveProgressNotifying: notifier
 "Private - Destroy the progress view and remove its class if possible."

 self notify: notifier heading: 'Closing progress dialog for final
stripping cycle'.

 [ | progClass canvas |
  progClass := Smalltalk at: #ImageStripperProgress.
  progClass allInstances do: [:each | each exit].
  SessionManager inputState pumpMessages; processDeferredActions.
  "We have to turn the notifier into a DeafObject"
  progClass allInstances do: [:each | each become: DeafObject basicNew].

  self removeClass: progClass notifying: notifier.

  "Now write a message over the desktop to indicate the the strip is not
quite complete"
  (canvas := View desktop canvas)
   font: (Font name: 'Arial' pointSize: 12) beBold;
   backcolor: Color blue;
   setTextColor: Color white;
   setTextAlign: ##(TA_CENTER|TA_BASELINE);
   text: 'Please wait while Dolphin Lagoon terminates' at: (canvas
extent // 2).
  canvas free.
  canvas := nil.

  SessionManager current isConsoleApplication ifTrue: [
   self stripForConsoleApplicationNotifying: notifier].

  "Ensure RichText converter is not hanging around unecessarily"
  Smalltalk at: #RichText ifPresent: [:rt | rt uninitialize].
  SessionManager inputState purgeDeadWindows.
 ] on: Error do: [:e |
  self notify: notifier status: 'Error (see crash dump): ', e
description.
  VMLibrary default crashDump: e description].

 self collectGarbage.
 self finishedWithAll: #(stripForConsoleApplicationNotifying:
destroyAndRemoveProgressNotifying:)






--------------------------------------------------------------------------------------------

Sorry for the monologue here, but in case this information helps anyone
else,
here's what happened.

Installing IE 5.5 didn't help.

I finally noticed winmm!midiOutGetNumDevs in the dump below and recalled

someone else having problems because of midi configuration.  I think
that when
the ImageStripperProgress view closing was causing a sound to be played
that
was causing problems.  Wouldn't have noticed the sound and crash being
simultaneous with the speakers off.  I fiddled with the midi
configuration and
it started to work!  In the meantime the configuration has been reset to
what
it was previously, but it still works.  Go figure.

There was still a problem with KernelLibrary not understanding
createDirectory:lpSecurityAttributes:.  The problem there was that I had
loaded
in an older package providing directory support that supplied the same
function.  The package manager probably stripped it as it removed the
unnecessary directory package, but still wanted to use it in the
KernelLibrary.

Now I'll have to check whether that chunk file browser can understand
chunks of
type conditionalMethodsFor:  ;-)

Thanks for reading.

Keith Alcock


Keith Alcock wrote:

> Anyone,
>
> The problem seems to be related to this line in
> ImageStripper>>destroyAndRemoveProgressNotifying:
>
>      progClass allInstances do: [:each | each exit ].
>
> This is used to close the ImageStripperProgress view associated with
the
> ImageStripper.  It works fine in a workspace.  If I replace it with
>
>      UserLibrary default sendMessage: (each view) asParameter msg:
WM_CLOSE
> wParam: 0 lParam: 0.
>
> Dolphin still crashes with Dr. Watson information like that below and
> nothing in the error file at all.
>
> I wouldn't doubt that this is a Windows problem, but then someone else

> should be experiencing it too.
>
> Dolphin is great, but Windows is like an Achilles heel.
>
> Keith Alcock
>
> Keith Alcock wrote:
>
> > I'm testing out the ADK on Dolphin 4 both with and without patch 1
under
> > Windows 2000.  Most of the time Dolphin crashes just after entering
> >
> >     Closing progress dialog for final stripping cycle
> >
> > into the htm log file, sometimes it is before that (although some
file
> > buffering might explain the difference).  The executable file is
always na ........, na
> > po nc
> > cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000
> > efl=00000246
> >
> > function: GenericCallback
> >         027815c8 eb0e             jmp     DllUnregisterServer+0x301f

> > (0278a0d8)
> >         027815ca 8b0d00a27902     mov     ecx,[0279a200]
> > ds:0279a200=10010ccc
> >         027815d0 eb06             jmp     HashBytes+0x533 (027843d8)
(02784f38)
> >         027815ec 39882c407902     cmp     [eax+0x279402c],ecx
> > ds:027995ac=10010d74
> >         027815f2 8b8030407902     mov     eax,[eax+0x2794030]
> > ds:027995b0=100171e8
> >         027815f8 753e             jnz     DllUnregisterServer+0x307f

> >
> > *----> Stack Back Trace <----*
> >
> > FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
> > 01A2FE38 02772071 02792AF9 004040A8 0279A394 004040A8
!GenericCallback
> > 01A2FE74 0278C8D2 00000000 004040A8 0279A394 00000000 !<nosymbols>
> > 01A2FEC4 0278613A 02770000 00000000 02792AF8 00000001
!CompileForEval ....t...q na ......4.
> > 0......
> > 0276ff38  8c 30 dc 84 20 30 dc 84 - b0 31 dc 84 1c d6 42 80  .0..
> > 0...1....B.
> > 0276ff48  00 2f 06 80 80 31 dc 84 - 20 30 dc 84 70 1c 71 bd
./...1..
> > 0..p.q.
> > 0276ff58  00 a2 2f 4d ff ff ff ff - 50 fe 76 02 ff ff ff ff
> > ../M....P.v.....
> >
> > State Dump for Thread Id 0x2c4
> >
> > eax=77562bdf ebx=00000002 ecx=00000000 edx=00000000 esi=77f87e6c
> > edi=00000002
> > eip=77f87e77 esp=0a1bff24 ebp=0a1bff70 iopl=0         nv up ei pl zr
na na
> > po nc
> > cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000
> > efl=00000246
> >
> > function: DispatchMessageW
> >         77e14137 90               nop
> >         77e14138 ffff             ???
> >         77e1413a ffff             ???
> >         77e1413c 7407             jz      DrawFrame+0xae4 (77e22545)
ac na
> > po nc
> > cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000
> > efl=00000246
> >
> > function: <nosymbols>
> >
> > I have tried both package-based deployments and those based on a
session
> > manager.  For the test described above, I just did an
> > ApplicationDeploymentWizard show, entered a file name and chose the
> > CalculatorSessionManager.
> >
> > Can anyone recognize or diagnose the problem?  Debugging it is
rather
> > difficult.  It looks like there is some problem during CreateFileA.
> >
> > Thank you.
> >
> > Keith Alcock

Keith

"Keith Alcock" <[hidden email]> wrote in message
news:[hidden email]...
> ....
> Since it's easier to change Dolphin than change the way I work, I tried
> moving the canvas message to before the progClasses exit, but that
> doesn't help.  A canvas probably isn't something that can get focus.

Thats right. I should explain that the choice of drawing the final "Please
wait" message on the desktop was quite deliberate. In order to allow the
progress dialog itself, and anything in its reference net, to be stripped,
it must be closed. To see quite what a difference this makes take a look at
the HTML log file from a successful strip. If you search for the text
'Closing progress dialog for final stripping cycle', after that point you
will see details of all the classes and methods that become candidates for
stripping when the progress dialog has been cleared away. In the case of a
simple GUI app like hello world more than 80 further classes and hundreds
more methods are stripped. In the case of a console application the "silent"
stripping stage is especially important because it is only then that the GUI
support (most importantly the View hierarchy) can be stripped.

>...I
> suspect that if a non-modal dialog were shown temporarily it might work,
> but that would change some of the stripping strategy.

Yes, as I describe above it would considerably impact the stripping
effectiveness.

> If anyone can figure out how to make this method impervious to mouse
> clicks or screen changes, please let me know.

It sounds as if there is a problem in switching away from Dolphin at this
critical stage, but we've so far been unable to reproduce it here. There was
a related problem we experienced during 4.0 development, but that was
solved. Without reproducability the next best thing is a Dolphin crash dump
(not one from Dr. Watson, as the latter doesn't tell us anything about the
state of the imate at the time of the failure). Without either then it will
be difficult to fix. We can surmise that some Windows message is being sent
to Dolphin that it isn't prepared to handle at that stage in the stripping
process, perhaps because the window subsystem is partially shut down, but
that's just a guess.

Regarding your workaround, can your screen manager not be configured to
remain on the current screen regardless of whether there any any windows
open on it? It might be that it can't because Windows will try to activate
another top-level Window, which would presumably initiate a screen swap,
something that personally I would find rather annoying.

Looking forward to that crash dump
(http://www.object-arts.com/wiki/html/Dolphin/CrashDump.htm)

Regards

Blair

Blair,

Thanks for the background information and for the tips.  I hadn't seen the Wiki
info on the crash dump.  Unfortunately, no crash dump is ever produced.  Just to
be thorough, I crashed it both as a normal user and as an administrator and with
and without the program DebugView.exe running and also with and without the
registry settings at the default value.  The only way I could get anything was
with VMLibrary default crashDump: 'testing'.  That worked nicely.  For each real
crash the Doctor Watson version of the dump did get written, but that doesn't
help you.

The screen manager doesn't have an option to turn off the automatic switching,
but now that I finally know what is going on and can prevent the crash, I'm
satisfied.

If for some reason you want to look into it further (because of that mouse
problem or the crash dump problem), I'm running Win2K and the screen manager is
called Expanse 1.1 and can be had at
http://softseek.zdnet.com/Utilities/Taskbar_Start_Menu_and_Explorer_Enhancements/Virtual_Desktops/D_26751_index.html.

Thanks,

Keith


Blair McGlashan wrote:

Keith

You wrote in message news:[hidden email]...
>...
> If for some reason you want to look into it further (because of that mouse
> problem or the crash dump problem), I'm running Win2K and the screen
manager is
> called Expanse 1.1 and can be had at
>
http://softseek.zdnet.com/Utilities/Taskbar_Start_Menu_and_Explorer_Enhancem
ents/Virtual_Desktops/D_26751_index.html.

Thanks for the link, I downloaded Expanse, fired it up, and had a quick look
with a debugger. This is a most unusual problem. What is happenning is that
a foreign thread (i.e. not one started by Dolphin) is crashing as soon as
one attempts to switch the desktop. Just starting a deployment, waiting a
bit until it gets underway, and then clicking on the Expanse window to move
to another desktop will immediately cause the Windows GPF dialog to appear
(assuming you don't want Dr Watson configured to start automatically). If
you get the GPF dialog and just leave it there, the deployment will complete
successfully, because Dolphin itself is unaffected, even though the dialog
reports that Dolphin.exe has crashed. The GPF dialog can be misleading, in
that it isn't Dolphin that has crashed but one of the threads running within
it, and in this case not one of the Dolphin threads. Because it isn't a
Dolphin thread that crashes no Dolphin crash dump is produced.

You may be wondering what is going on! Well, any DLL loaded into a process
can start a thread in it. Should that thread GPF, then Windows reports that
the executable has caused an exception. Strictly speaking this isn't true,
the process started by the executable has caused an exception, not
necessarily the executable's own code. Another example is that if the
Dolphin plugin running inside Internet Explorer/Netscape crashes, then
Windows blames the browser because the Dolphin plug-in runs "in-process"
(inside the browser process that is), starting its own threads to run the
"live" image.

Now I don't know what started the offending thread. It could be a system
thread started by Windows, or it could be a thread belonging to Expanse,
since it would appear that it loads a DLL entitled hook.dll into the address
space of all processes.

I also don't know why the thread is crashing - it seems to end up in the
middle of nowhere, which is frequently an after effect of stack corruption
(basically overwritig return addresses), but one can't be sure. What I do
know is that this happens repeatably when one attempts to switch desktop
during a deployment, and I doubt it has anything to do with the intermittent
fault, reported by someone else, that occurs when using ALT+TAB to switch to
another application and back.

In summary: Either use your workaround of avoiding/preventing switches of
desktop during deployment, or avoid this particular desktop manager.

Regards

Blair

Blair,

Thanks again for looking into it.  While I'm glad that the problem was
reproducible on another machine for once, I regret taking your time if the other
program is at fault.

I had never tried purposely clicking the mouse to get the screen change.  Sure
enough, the GPF happens immediately.  The only difference between your
observation and mine is that although I do get an exe file, it is empty.  The
stripping process does not run to completion.

Please put this one on the tab of whoever at Microsoft decided to identify the
crash as belonging to the host application instead of the application that
injected the hook.

Keith

P.S. I'm about to send a bug report, so don't start celebrating too soon :-)



Blair McGlashan wrote:

Keith

You wrote in message news:[hidden email]...
> ...
> Thanks again for looking into it.  While I'm glad that the problem was
> reproducible on another machine for once, I regret taking your time if the
other
> program is at fault.

It still may be a bug in Dolphin, or at least something we can work around.
On the one hand it doesn't seem to happen to other applications, and doesn't
occur to Dolphin when one is not actually deploying. On the other hand it
appears to be a foreign thread that is causing the fault. We just can't be
sure at present, so it will remain on the bug system and I'll look into it a
bit more when we have completed the maintenance release.

>
> I had never tried purposely clicking the mouse to get the screen change.
Sure
> enough, the GPF happens immediately.  The only difference between your
> observation and mine is that although I do get an exe file, it is empty.
The
> stripping process does not run to completion.
>
> Please put this one on the tab of whoever at Microsoft decided to identify
the
> crash as belonging to the host application instead of the application that
> injected the hook.

I suppose the reasoning is that from a user point of view one has to point
the finger at something.

>
> P.S. I'm about to send a bug report, so don't start celebrating too soon
:-)

All genuine bug reports are welcome, especially if they come with an SUnit
test to reproduce them :-)

Regards

Blair