Deployed app crashing on Server 2003

Greetings,

one of my clients reportS that a deployed Dolphin console application,
which has been running on a Win2000 server for quite some time,
throws an exception. The good news is that this happens after
the app has done its job (preparing HTML reports).

In fact, it looks like it crashes right before closing down.
The application uses a Delphi-based DLL to access data stored
in Paradox tables. That should not be a problem, however, as
I'm passing in a file name and some SQL (read only) and let the
DLL write the query results to a file on disk, which I then
parse into my application.

The to-go-executable lives in a folder, accompanied by it's own
copy of MSVCP60.DLL (version 6.0.xxx on my Win2k box and in the
application folder, version 6.5.xxx in client's system32 folder).

I'll be visiting my client next Tuesday. Any suggestions on what
I could do to look smart? :-)

Thanks,
s.

Stefan Schmiedl wrote:
> I'll be visiting my client next Tuesday. Any suggestions on what
> I could do to look smart? :-)
If the app wrote an ERRORS file you could use your working image with
Ghoul loaded to take a look at it. *If* the issue is Smalltalk related
you should be able to pin it down using Ghoul.

CU,

Udo

Stefan,

In addition to Udo's comment, take your development image, installer for
the IDE (uninstall or at least remove the image when you leave - OA
might have further requirements, but I doubt it), take the VM and
compiler patches (AFAIK, OA never built them into the 5.1 installers),
and/or have a portable from which you can deploy updated executables.

If you rely on finalization to clean up ODBC objects, explicitly close
them before exiting the app.  Unless you have done something else that
could be considered bleeding edge, my first guess would be timing woes
on shutdown.

Also, search the archives for topLevelHandlesDo:, especially in context
of console apps; there might be something we are all forgetting about
them ~:0

Good luck!

Bill

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

On Fri, 11 Nov 2005 16:20:02 +0100, Udo Schneider  
<[hidden email]> wrote:

> Stefan Schmiedl wrote:
>> I'll be visiting my client next Tuesday. Any suggestions on what
>> I could do to look smart? :-)
> If the app wrote an ERRORS file you could use your working image with  
> Ghoul loaded to take a look at it. *If* the issue is Smalltalk related  
> you should be able to pin it down using Ghoul.

*If* there is such a file, I will Ghoul let take a look, but I doubt it...
I tried some stuff over the phone already and my client did not mention
that such a file popped up.

But we'll see.

Thanks,
s.

Thanks for your thoughts, Bill, they're very helpful.


On Fri, 11 Nov 2005 20:06:43 +0100, Bill Schwab <[hidden email]>  
wrote:

>
> In addition to Udo's comment, take your development image, installer for  
> the IDE (uninstall or at least remove the image when you leave - OA  
> might have further requirements, but I doubt it), take the VM and  
> compiler patches (AFAIK, OA never built them into the 5.1 installers),  
> and/or have a portable from which you can deploy updated executables.

That's an idea. Install D5 on the box, patch it, install packages,
deploy executable and see what gives.

>
> If you rely on finalization to clean up ODBC objects, explicitly close  
> them before exiting the app.  Unless you have done something else that  
> could be considered bleeding edge, my first guess would be timing woes  
> on shutdown.

No ODBC in this app. I'm using the DLL explicitely to avoid the ODBC
Paradox driver, which has caused me enough pain already (messed up joins
without error reporting). Do I have to do something special to "close"
an external DLL?

>
> Also, search the archives for topLevelHandlesDo:, especially in context  
> of console apps; there might be something we are all forgetting about  
> them ~:0

I'm seeing that Carsten Haerle had (has?) the same problem with  
suspiciously
similar calling stack on a Win64 server, so the good news might be that  
it's
2003 and not the 64bit part causing the problem.

Then I see your reply from October last year to Mark Derricutt's problem,
which also seems to be the same thing. So I'll answer some of your  
questions
to Mark here

> Is the user in question using any debugging tools (things that hook  
> libraries, etc.)?

No. It's a new Win2003 server (about 1 week old). The "strangest" thing
on this box should be a recent version of Borland's BDE libraries.

> It looks like EnumWindows() is conking out.  Does it do this immediately
> after the exe starts, or is more random?  My first thought (by no means
> necessarily correct) is that you had a zombie view lurking in your image
> at the time of deployment.

I wonder what EnumWindows has to do with *console* applications being
run from cmd.exe ... but I guess that's what I deserve, as linux guy  
developing
Windows software :-/

The problem quite reliably occurs at the end of the run, we tried it  
several
times today.

It is deployed automatically from a quite clean 5.1.4 image (official  
patches and
removed "deployment finished" dialog) via prestart.st script, which  
installs the
pac-file exported from my dev-image and deploys the exe according to the  
packages
saved settings.

[[ Imagine me googling furiously for enumwindows and console application ]]

Quoting Phillip Crews aka Severian on  
http://www.ureader.com/message/836427.aspx

So others are having intermittent trouble in this area, too, even if they
program in C++. Now I only need to find somebody who knows if a deployed
console application fits number 2) from above.

Curious,
s.

Stefan Schmiedl wrote:

> I'll be visiting my client next Tuesday. Any suggestions on what
> I could do to look smart? :-)

Buy a new suit ?


> > InputState>>aboutToIdle

This looks a bit odd.  I might easily be wrong, but I was under the impression
that the Idler process should not normally get a chance to run for a console
app
unless you delay explicitly.  (Or block on COM or (old) Sockets -- in which
case you'll have started a GUI-style "main" Process running explicitly).

It sounds rather as if it's getting a chance to "play" as your application
exits, which doesn't seem right either.
How do you exit from your app ?  Does your SessionManager>>main call #exit:
explicitly, or just fall off the end, or does something else #exit: your
application, or what ?

    -- chris

On Fri, 11 Nov 2005 21:06:31 +0100, Stefan Schmiedl <[hidden email]> wrote:
> [[ Imagine me googling furiously for enumwindows and console application  
> ]]
>

more of the same gives a *very interesting* page, where Noel has a problem:

http://www.eggheadcafe.com/ng/microsoft.public.win32.programmer.ui/Jul2005/post23031214.asp

> For an installer, I created a function (in a DLL) to enumerate all  
> running  applications and to close any instance of my application. That  
> works fine in Windows XP 32-bits and older systems but I was told by a  
> user that this no more work on a Win64 systems (my installer is Win32).  
> I don't have a Win64 system myself. I created a simple console  
> application (see code below) and asked the user to try it on his Win64  
> system and he told me that the application never completes and hangs  
> somewhere in the enumeration.

...

> Here are the information I obtained from the user regarding his  
> configuration: The system is "Microsoft Windows XP Professional x64  
> Edition 5.2.3790 (Win2003 Retail) with SP1"

2003 again, eh?

Rhett Gong, (Microsoft Online Partner Support) replies

> I compile your code in this post, and exec following command in my test  
> box

and it runs. You can copy and paste the compiled exe from URL given above.
Sadly, the end of the thread is not on egghead, but visible in the  
newsgroup
(which, at least on google, lacks the file):

http://tinyurl.com/bnpht

originally (sans line breaks):

http://groups.google.com/group/microsoft.public.win32.progra
mmer.ui/browse_thread/thread/873970fb816533a/fd5bc62450c6a2c
b%23fd5bc62450c6a2cb?sa=X&oi=groupsr&start=2&num=3

Noel again:

> Your code did work on his system so I rebuilt my code using the latest
> Platform SDK and that did the trick. Thank you.

argh. What does that imply for D5 apps?

s.

Hi Chris,

On Fri, 11 Nov 2005 21:42:32 +0100, Chris Uppal  
<[hidden email]> wrote:

> Buy a new suit ?

If I take the right conclusions from my last post, it's the one option I  
still have :-)

Not that I know of.

>
> It sounds rather as if it's getting a chance to "play" as your  
> application
> exits, which doesn't seem right either.
> How do you exit from your app ?  Does your SessionManager>>main call  
> #exit:
> explicitly, or just fall off the end, or does something else #exit: your
> application, or what ?

lemme look ... aha ... amazing what convoluted stuff I wrote 2 years ago...
I have

        ConsoleSessionManager subclass: #Whatever
                ....

and

        Whatever>>main
                (TheRealApp new) main

So it just falls off. I'll have my client give SessionManager>>exit a try  
on Monday,
maybe I'll be able to avoid the suit :-)

Thanks for hope,
s.

On Fri, 11 Nov 2005 22:02:29 +0100, Stefan Schmiedl <[hidden email]> wrote:

What I did today (modulo several typos ... how hard can it be to add one  
line of code?):
1) TheRealApp>>main now looks like
        TheRealApp>>main
                ...
                self isRuntime ifTrue: [SessionManager current exit: 0]

Result: A strange walkback in the deployed console executable:

        aMessageNotUnderstood('True does not understand asValue')

because of
       
        SessionManager>>queryEndSession
        |okToQuit|
        okToQuit := true asValue.
        ...

Of course, 'true asValue' works in the development image...
So I avoid the problem with:

2) TheRealApp>>queryEndSession
        ^true

and now it works on both my Win2k laptop and the Win2003 server.
We'll see tonight if it also works when being called as scheduled task,
but I'm optimistic.

I wonder what the cause of 'true asValue' not being understood in the
deployed app is, though.


Thanks for all of your help, every single bit counted.
s.

Stefan Schmiedl wrote:

> and now it works on both my Win2k laptop and the Win2003 server.
> We'll see tonight if it also works when being called as scheduled task,
> but I'm optimistic.

Sounds good :-)


> I wonder what the cause of 'true asValue' not being understood in the
> deployed app is, though.

A lurking gotcha ;-)  Object>>asValue is a loose method in the 'Dolphin Value
Models' package, and that package will be removed during image stripping unless
you happen to refer to one of the actual classes in that package (moderately
unlikely).  The fix is to set that package as a "manual prerequisite" of you
own session manager's package.

(D6 changes #queryEndSession to use an Association instead of a ValueModel,
thus removing the dependency whilst cunningly maintaining compatibility.)

    -- chris

On Mon, 14 Nov 2005 16:06:49 +0100, Chris Uppal  
<[hidden email]> wrote:

> Stefan Schmiedl wrote:
>
>> and now it works on both my Win2k laptop and the Win2003 server.
>> We'll see tonight if it also works when being called as scheduled task,
>> but I'm optimistic.
>
> Sounds good :-)

and I avoid buying a suit again :-D

oh... in that case, I'll just refuse to deploy another update before D6  
comes
out. So now Object Arts has the future of my business in their hands ...  
but
don't let that put you under pressure, guys :-)

Thanks,
s.