Intermittent crashes

One of my tools adds and removes pages from a tabbed collection dynamically.
Very occasionally, as it does so, D5 crashes totally.  I.e. it just vanishes
with no walkback, no Windows error message, or anything.

It has now done it (I think) three times during the beta.  This is running
on W2k.  The same tool has been running under D4 (on W2k and W98) since D4
came out, and has never given this trouble, ever.  It's a tool I use a lot,
too.

It's just done it again now, the last time before that was a few days ago.

It is remotely possible that the particular page being added is in some way
implicated.  The effect has only happened when I've been adding a particular
page to the tabs; it has a MethodBrowser on it with a View not unlike the
standalone method browser's.  It may easily be just coincidence, though,
since that page is the one I add dynamically most often by far.

I realise that I've said nothing to help you identify  the problem, but I
don't really know where to start looking.

I've just checked my registry, and it appears that crash dump isn't enabled
for D5.  I added a CrashDump key under the D5 entry in HK_LOCAL_MACHINE
which is like the one for D4 (it has no entries in it).  Is that the right
thing to do to enable it -- I'm afraid I can't remember ?

I'm going to rebuild my image from scratch and start again.  I'll let you
know if I see the problem again, but in the meantime, is there anything you
can suggest to help track it down ?

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> One of my tools adds and removes pages from a tabbed collection
dynamically.
> Very occasionally, as it does so, D5 crashes totally.  I.e. it just
vanishes
> with no walkback, no Windows error message, or anything.
>...

We have found that there is an obscure VM bug around its sending of
#mustBeBoolean messages to DeafObject (it
overrides this to return self), and although this problem also presumably
exists in D4, certain changes in D5 make it more likely to happen. It is
possible that this is behind the crash you are seeing, but I would normally
expect to see an unhandled exception dialog.

With the crash dump enabled (see below) you will know if you are
experiencing this problem because the stack dump entry header will include
the line:

...
New Method: DeafObject>>mustBeBoolean
...

However, when a .EXE just drops out like that without a dialog, one normally
won't get a crash dump (I assume something so terrible happens, such as
stack corruption, that Windows isn't able to run the Win32 structured
exception handlers).

Regards

Blair

Blair,
normally normally
> won't get a crash dump (I assume something so terrible happens, such as
> stack corruption, that Windows isn't able to run the Win32 structured
> exception handlers).


I've just seen another crash in the circumstances I described.  On this
occasion Window's did get a hand in and was able to post an error popup, so
it *might* not be the same problem as I was seeing before.  However, I did
get the crash dump, and it does indeed show #mustBeBoolean getting sent to a
DeafObject.

I've still got the crash dump if you want it, but I imagine that you have
traces of your own for this particular bug.

BTW, is the Path setting for the crash dump current ignored.  I tried
setting it using the instructions on the wiki, but it seemed to have no
effect -- the dump was still written to the .errors file.  I could easily
have been doing something wrong, though.

> Blair

    -- chris

Blair,

> BTW, is the Path setting for the crash dump current ignored.  I tried
> setting it using the instructions on the wiki, but it seemed to have no
> effect -- the dump was still written to the .errors file.  I could easily
> have been doing something wrong, though.

This brings to mind an enhancement request: some code (probably a VMLibrary
or SmalltalkSystem method??) to enable the crash dump, set the depths, and
send the output to a particular path.  It could be exposed in the IDE and
also be callable by deployed apps.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > BTW, is the Path setting for the crash dump current ignored.  I tried
> > setting it using the instructions on the wiki, but it seemed to have no
> > effect -- the dump was still written to the .errors file.  I could
easily
> > have been doing something wrong, though.
>
> This brings to mind an enhancement request: some code (probably a
VMLibrary
> or SmalltalkSystem method??) to enable the crash dump, set the depths, and
> send the output to a particular path.  It could be exposed in the IDE and
> also be callable by deployed apps.

VMLibrary>>dump: <msgString> path: <pathString> stackDepth: <slotsInteger>
walkbackDepth: <framesInteger>

This is, in fact, used by all deployed applications (at least those that
don't override RuntimeSessionManager>>logError:), though nil is passed as
the path causing the standard <app name>.error output. It can be called at
any time, and is occassionally useful for (very verbose) debug tracing.

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> I've just seen another crash in the circumstances I described.  On this
> occasion Window's did get a hand in and was able to post an error popup,
so
> it *might* not be the same problem as I was seeing before.  However, I did
> get the crash dump, and it does indeed show #mustBeBoolean getting sent to
a
> DeafObject.
>
> I've still got the crash dump if you want it, but I imagine that you have
> traces of your own for this particular bug.

Please send it anyway, it's always useful to have as many data points as
possible for this sort of problem.

>
> BTW, is the Path setting for the crash dump current ignored.  I tried
> setting it using the instructions on the wiki, but it seemed to have no
> effect -- the dump was still written to the .errors file.  I could easily
> have been doing something wrong, though.

It shouldn't be. The actual path used is written in a trace message with
OutputDebugString, and you can test it out with:

    VMLibrary default crashDump: 'Doh!'

Of course you'll need to have a debug monitor running, and set the default
value of:

    HKEY_LOCAL_MACHINE\SOFTWARE\Object Arts\Dolphin Smalltalk 5.0\CrashDump

to the path you want to use. The directory you specify will have to exist,
otherwise the dump will go elsewhere (though I can't remember where off the
top of my head - again the debug monitor output will confirm).

Regards

Blair

Hi Blair,

> > This brings to mind an enhancement request: some code (probably a
> VMLibrary
> > or SmalltalkSystem method??) to enable the crash dump, set the depths,
and
> > send the output to a particular path.  It could be exposed in the IDE
and
> > also be callable by deployed apps.
>
> VMLibrary>>dump: <msgString> path: <pathString> stackDepth: <slotsInteger>
> walkbackDepth: <framesInteger>
>
> This is, in fact, used by all deployed applications (at least those that
> don't override RuntimeSessionManager>>logError:), though nil is passed as
> the path causing the standard <app name>.error output. It can be called at
> any time, and is occassionally useful for (very verbose) debug tracing.

Turning that around a little, the crash dump is effectively enabled for all
deployed apps (that don't shoot it in the foot) - fair?

Another dumb question: is the crash dump enabled for the IDE as installed?
If so, then you've got it covered, if not, I'd suggest either enabling by
default or having an obvious way to turn it on.  At least a couple of us are
under the impression that we have to create registry keys to enable the
dump, and a small addition to the IDE would idiot proof it - or are we
idiots for not realizing that it's already on? :)  Could we be getting
fooled by it's being enabled for one user and not another?

Have a good one,

Bill

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

Blair,

> > I've still got the crash dump if you want it, but I imagine that you
have
> > traces of your own for this particular bug.
>
> Please send it anyway, it's always useful to have as many data points as
> possible for this sort of problem.

It's on its way (or will be soon).

> > BTW, is the Path setting for the crash dump current ignored.  I tried
> > setting it using the instructions on the wiki, but it seemed to have no
> > effect -- the dump was still written to the .errors file.  I could
easily
> > have been doing something wrong, though.
>
> [...] and set the default
> value of:
>
>     HKEY_LOCAL_MACHINE\SOFTWARE\Object Arts\Dolphin Smalltalk
5.0\CrashDump
>
> to the path you want to use.

Aha!  That's my problem -- I was adding a Path value under ....\CrashDump,
not the setting default value.  It works now, thanks.  BTW, I'd understood
the wiki page to be saying that you do need the Path sub-value (I'm not in a
position to go back and check just now).  Is that wrong, or is it something
that has changed for D5 ?

I'm inclined to agree with Bill that a couple of little utility methods
added to the image that queried/configured the crash dump registry settings
would be a useful thing, if only for their documentary value.  Pointing
people at the wiki is all very well (if it's right and up to date), but
assumes that everyone has Net access all the time.

> Blair

    -- chris

Blair,

> I'm inclined to agree with Bill that a couple of little utility methods
> added to the image that queried/configured the crash dump registry
settings
> would be a useful thing, if only for their documentary value.  Pointing
> people at the wiki is all very well (if it's right and up to date), but
> assumes that everyone has Net access all the time.

I thought a little more about this, and you might export a function from the
VM to allow the image to pull up the keys on the fly; then it would be a
simple thing to write a wrapper around that to turn it on and configure it.

Have a good one,

Bill

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