GPF exiting a deployed dolphin application...

I have a deployed (to go)  Dolphin application that is causing a GPF when
the program is closed.  The GPF happens on my 1.8 ghz Xenon Windows XP
system (and a users system, but I don't know his specs at the moment), but
it does not happen on my 300 mhz Windows NT or 200 mhz Windows 2000 systems.
The GPF only occurs when I give the program a bit of a workout (opening some
files that cause database use), if I just open and close the program (and do
nothing) I do not get the GPF.  I had hoped that the GPF was related to the
database finalization issues fixed in the beta patch, but I also deployed
from a patched image and still get the GPF on close except with the patch it
always seems to be a write error rather than a read error.

Has anyone encountered anything like this?  Any tips on debugging?  Dolphin
does not get a chance to write an error log and I don't see anything
interesting on the debug trace.

Here is the gpf info:
---------------------------
em.exe - Application Error
---------------------------
The instruction at "0xe82527ef" referenced memory at "0xe82527ef". The
memory could not be "read".
---------------------------
em(Patch2).exe - Application Error
---------------------------
The instruction at "0x002c02b4" referenced memory at "0x7ffe0304". The
memory could not be "written".
====================

Chris

Christopher J. Demers wrote:

> Has anyone encountered anything like this?  Any tips on debugging?

Have you tried letting Windows start a/the system debugger (VC++ or whatever)
on it ?  It's a long shot, but you *may* be able to see something in the call
stack that will either give you a clue, or at least rule out some
possibilities.  If you have the system debugging symbols installed then the
chances of it helping go up to, oh, at least 1 in 20...

As I say, it is a long shot, but it did help me diagnose one nigglingly
irregular crash once.

    -- chris

Chris,

> I have a deployed (to go)  Dolphin application that is causing a GPF when
> the program is closed.  The GPF happens on my 1.8 ghz Xenon Windows XP
> system (and a users system, but I don't know his specs at the moment), but
> it does not happen on my 300 mhz Windows NT or 200 mhz Windows 2000
systems.
> The GPF only occurs when I give the program a bit of a workout (opening
some
> files that cause database use), if I just open and close the program (and
do
> nothing) I do not get the GPF.  I had hoped that the GPF was related to
the
> database finalization issues fixed in the beta patch, but I also deployed
> from a patched image and still get the GPF on close except with the patch
it
> always seems to be a write error rather than a read error.

I've never been able to trust ODBC finalization.  OA has patched various
problems over time, but explicit cleanup is the only way I've been able to
make it reliable.  I most recently saw a problem just about a year ago, on a
Win2k machine - clearly before the beta patch.  However, I could just as
easily believe that there is still a problem.  Note that the problem would
not necessarily have to be in Dolphin.

Another possible variable is the shutdown behavior of your app.  I've
removed most (maybe all) of the early startup code (from the days when it
was necessary to think about secondary and tertiary startup), but I still
use #keepAlive to slash and burn lots of stuff before apps close.  That
might be preventing some types of problems???


> Has anyone encountered anything like this?  Any tips on debugging?

Time spent in database activity isn't a big problem for me right now, mostly
because I don't have any current need to do 10^atLeastFive operations all at
once.  The last time I did, I found it to be a very slow process, and
attempted to enter the world of prepared statements.  I _knew<g> it was
going to give me at least a couple orders of magnitude boost.  Instead of
10^2, I got 1^2 :(  Ok, halving the time is a big improvement, but not worth
the effort to propagate to my other apps: they simply don't spend all that
much time pounding on databases.  Worse, of the time that remained, most of
it was spent resetting the prepared statements for their next use; it was
almost as costly as just making a new statement, hence the less than
dramatic improvement.  With prepared statements, the task would have taken
1.5 days vs. 3 days (extrapolating from <1% of the job), and by just writing
text files with the data, it was over in about 10 **minutes** IIRC.


> Dolphin
> does not get a chance to write an error log and I don't see anything
> interesting on the debug trace.

Are you certain the crash dump is enabled?  Are you looking in the right
place for it?  I would recommend firing off an explicit dump just to make
sure, and for end users, you could add an obscure menu item to let them
exercise the dump.  With that said, I have seen dumps that were all but
empty, but unless it's writing a dump that tells you it can't write anything
meaningful, I'd double check that it's trying.

The Wiki is still hung over from an apparent overdose of Christmas cheer, so
I can't review the crash dump specs.  I don't recall whether it documented
D5's behavior.  FWIW, it seems to have gotten easier to get output, because
there appears to be a default for x:\somewhere\on\your\drive\appname.exe to
log to x:\somewhere\on\your\drive\appname.ERRORS.

One final thought: some older VM (or maybe it was the DLL stub???) would
overwrite vs. append to a dump, so make sure that you are not losing info
that way.

Have a good one,

Bill

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

Chris,
"Christopher J. Demers" <[hidden email]> wrote in
message news:avikio$g74ka$[hidden email]...
> I have a deployed (to go)  Dolphin application that is causing a GPF when
> the program is closed.  The GPF happens on my 1.8 ghz Xenon Windows XP
> system (and a users system, but I don't know his specs at the moment), but
> it does not happen on my 300 mhz Windows NT or 200 mhz Windows 2000
systems.
> The GPF only occurs when I give the program a bit of a workout (opening
some
> files that cause database use), if I just open and close the program (and
do
> nothing) I do not get the GPF.  I had hoped that the GPF was related to
the
> database finalization issues fixed in the beta patch, but I also deployed
> from a patched image and still get the GPF on close except with the patch
it
> always seems to be a write error rather than a read error.
>
> Has anyone encountered anything like this?  Any tips on debugging?
Dolphin
> does not get a chance to write an error log and I don't see anything
> interesting on the debug trace.
I seem to recall having had a problem with this a while ago, and that
updating or reinstalling MDAC fixed it.  I don't recall whether there's an
easy way to check the version of things, though; it seems to me there
wasn't.

HTH,

Don

"Christopher J. Demers" <[hidden email]> wrote in
message news:avikio$g74ka$[hidden email]...
> I have a deployed (to go)  Dolphin application that is causing a GPF when
> the program is closed.  The GPF happens on my 1.8 ghz Xenon Windows XP
> system (and a users system, but I don't know his specs at the moment), but
...

Thanks for all the feedback.  It turns out that the problem was likely
something to do with database finalization.  I overrode the shutdown method
in my session manager to explicitly close the database (ReStore actually).
I also added a half second delay for good measure just to force a GC.  That
may not be critical, but I wanted to be sure.  I sealed it off and have not
been able to cause a GPF so it looks like it is fixed.

In this case I guess it has something to do with the speed of the computer
since it did not happen on the slower system.  Perhaps the image was closing
before finalization could be completed.

Chris

Chris,

> Thanks for all the feedback.  It turns out that the problem was likely
> something to do with database finalization.  I overrode the shutdown
method
> in my session manager to explicitly close the database (ReStore actually).
> I also added a half second delay for good measure just to force a GC.

You send #collectGarbage.  Of course, fast machines seem to be your concern,
and for them 500 msec is a long time w/o being a long time for the user - it
might be a pretty good solution.


> In this case I guess it has something to do with the speed of the computer
> since it did not happen on the slower system.  Perhaps the image was
closing
> before finalization could be completed.

In that case, the shutdown behavior would do the freeing.  It raises the
question of whether the statements and connections get cleaned up in the
correct order when finalization is not invoked.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:avl08d$gq151$[hidden email]...
>
> You send #collectGarbage.  Of course, fast machines seem to be your
concern,
> and for them 500 msec is a long time w/o being a long time for the user -
it
> might be a pretty good solution.

Thanks for the tip.  For some reason I had always been using delays to force
a GC.  It sounds like #collectGarbage is a more sure way to do it.

While I am talking about image termination here is an interesting
experience:
I have a program that saves settings to a configuration file when it closes.
Actually the main Shell was doing this.  It worked fine when testing in the
image.  In a deployed application the configuration file would be truncated.
It turns out that the file was not being explicitly closed, so in the image
finalization was closing it.  In the deployed image that was not happening.
The simple fix (and the way it should have been done in the first place) was
to manually close the file.  But my theoretical question is should the image
termination have forced a finalization of the file before termination?

Chris

Christopher J. Demers wrote:

> But my theoretical question is should the image
> termination have forced a finalization of the file before
> termination?

I would say no:

You can break down the kinds of actions performed by finalisation into three
categories:

1) Actions with an externally visible (i.e. outside the Dolphin program)
effect.
2) Actions which flush/recycle resources needed for the continuing health of
the image, but which are not externally visible.
3) Everything else, e.g. maintaining a count of instances with some property.

In case 2, I believe it is usually poor practice to rely on finalisation --
although it is necessary sometimes -- since finalisation is tied to memory use,
and memory is likely to be far more readily available than the resource that
needs recycling.  In this case the flushing of the finalisation queues that the
system does before an image save is just a convenience -- it reduces the amount
of "stuff" that needs to be saved in the image.  And, of course, in many cases
the recycled resource cannot be saved with the image anyway, but would need to
be recreated on next startup.  Since a deployed app will not save and restart
an image, there is no point in runnning this category of finalisation.

In case 3, the finalisation is used only to maintain an internally coherent
state in the image.  The finalisation done on image save is not necessary
(though it does no harm).  Again, for deployed apps there would be no point in
finalising before exit.

In case 1 -- which applies to your example -- I'd say that relying on
finalisation is more than poor practice, it is actually a programming *error*.
The reasoning being that in this case the externally-visible effect is
dependent on the time at which finalisation is run, but finalisation may (in
theory) be postponed indefinitely -- which isn't very different from "it may
not happen at all".  So in this case I don't think there is a need for
automatic finalisation on exit either.  BTW, if for some reason -- I can't
think of one offhand -- an application *needs* to rely on finalisation in this
way in a deployed app, then there is nothing to stop the programmer flushing
the finalisation queues explicitly before exiting (or at any other time).

    -- chris

P.S.  I think a good case could be made that the finalisers for external
state -- such as open files and sockets -- should do something like
"Notification signal: 'Warning: finalising ' , self printString." if they find
that they are still open (or whatever) when they reach #finalize.  It'd be a
nuisance for working in a workspace, though.

    -- c

"Chris Uppal" <[hidden email]> wrote in message
news:3e1eab90$0$153$[hidden email]...
| Christopher J. Demers wrote:
|
| > But my theoretical question is should the image
| > termination have forced a finalization of the file before
| > termination?
<SNIP>
 | In case 1 -- which applies to your example -- I'd say that relying on
| finalisation is more than poor practice, it is actually a programming
*error*.
| The reasoning being that in this case the externally-visible effect is
| dependent on the time at which finalisation is run, but finalisation may
(in
| theory) be postponed indefinitely -- which isn't very different from "it
may
| not happen at all".  So in this case I don't think there is a need for
| automatic finalisation on exit either.  BTW, if for some reason -- I can't
| think of one offhand -- an application *needs* to rely on finalisation in
this
| way in a deployed app, then there is nothing to stop the programmer
flushing
| the finalisation queues explicitly before exiting (or at any other time).

I think it depends on the way you look at finalization. When it you see it
as the last act before reusing a piece of memory you're right; finalization
may never take place. But when you look at finalization as a link between
the automatic memory managment of ST objects and the 'manual' lifetime
managment of external resources I would expect Dolphin to finalize before
exiting.
Also I wouldn't consider relying on finalization of for example BSTR's or
COM objects a programming error (but I agree with you on using finalization
for files and sockets).

 - Pieter


PS. One of the things that make a Smalltalk programmer a happy programmer is
the automatic object life time managment, lets try to not let the world
outside our ST image spoil this happyness to much ;-)

Pieter,

> I think it depends on the way you look at finalization. When it you see it
> as the last act before reusing a piece of memory you're right;
finalization
> may never take place. But when you look at finalization as a link between
> the automatic memory managment of ST objects and the 'manual' lifetime
> managment of external resources I would expect Dolphin to finalize before
> exiting.

No, Dolphin should not finalize before exiting. Finalization is used to
indicate that an object is no longer referenced and about to disappear.
Exiting the image merely puts the object into stasis but references to it
still exist. Imagine the confusion if, for example, finalization was being
used to remove an object from a database when no further references to it
existed. If the finalization procedure was run when then image shut down
then the object would be removed from the persistent store at this stage.
What would then happen when the image restarted?

> Also I wouldn't consider relying on finalization of for example BSTR's or
> COM objects a programming error (but I agree with you on using
finalization
> for files and sockets).

> PS. One of the things that make a Smalltalk programmer a happy programmer
is
> the automatic object life time managment, lets try to not let the world
> outside our ST image spoil this happyness to much ;-)

I think it is fair to accept that finalization *will* run after an object
expires. However, it is not possible to predict *when* it will run (just as
it is normal to predict when a garbage collection will reclaim memory). If
your application has critical resources that cannot reliably be reclaimed
within this framework then you should consider explicitly freeing them. For
example, one area in the image where we already do this is in the paint
handlers for views. Typically we will explicitly free any Canvas that is
created since these consume a fair few system resources and may exhaust the
Windows pool before finalization can automatically reclaim them.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Pieter,

I said.

> No, Dolphin should not finalize before exiting.

I may have misunderstood what you were implying. If you were suggesting that
a finalization of all live objects should be run then, no, that is not
correct. If, however, you were suggesting the finalization process should be
run for all expiring objects already on the finalization queue then that is
a more reasonable suggestion.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---