Error when stopping an Ice-based Windows service

[dwolfe5272]

I have a very simple Ice-based Windows service that starts just fine:

C:\ICT\bin>ICTViewerBridge.exe --start ICTViewerBridge
Service start pending.
Service is running.


However, when I try to stop it, I see in the console:

C:\ICT\bin>ICTViewerBridge.exe --stop ICTViewerBridge
Stop request sent to service.
Current state: 4
Exit code: 0
Service specific exit code: 0
Check point: 0
Wait hint: 0

and a message box pops up saying:

Debug Error!

Program C:\ICT\bin\ICTViewerBridge.exe

DAMAGE: after Normal block (#219) at 0x00397538


Things are slightly better if I compile in Release mode; I'm usually
able to stop the service with no errors. But occasionally I get a
msgbox saying:

The instruction at "0x0012e48c" referenced memory at "0x00000000".
The memory could not be "written".


Did I do something wrong? (See attached source...)


TIA,

Dave

----------


#include <ViewerBridgeImpl.h>
#include <Ice/ice.h>
#include <Ice/Service.h>

using namespace ICT;

class ViewerService: public Ice::Service
{
private:
Ice::ObjectAdapterPtr adapter_;

protected:
virtual bool start( int argc, char* argv[] );
};

bool ViewerService::start( int argc, char* argv[] )
{
// Create an 'adapter' for the server
adapter_ = communicator()->createObjectAdapterWithEndpoints(
"ICTViewerBridgeAdapter", "default -p 48105" );

// Create/add a servant implementing the ICTViewerBridge interface
Ice::ObjectPtr obj = new ViewerBridgeImpl;
adapter_->add( obj, Ice::stringToIdentity( "ICTViewerBridge" ) );
adapter_->activate();

return true;
}



int main(int argc, char* argv[])
{
ViewerService svc;
return svc.main(argc, argv);
}

[mes]

Hi Dave,

We will try to reproduce this, but it would help us to know the versions of Windows, Ice and Visual C++ you are using.

Thanks,
- Mark

[dwolfe5272]

> We will try to reproduce this, but it would help us to know the
> versions of Windows, Ice and Visual C++ you are using.

Of course--silly of me not to include this info in the first place. :-%
I'm using Ice 2.1.1, Windows XP (SP2) and Visual C++ .NET Standard
Edition (a.k.a. VC++ 7.1).

I don't think it matters, but what I did was buy the 'cheap' version
of the Visual C++ IDE that comes with compiler optimization disabled,
and then replaced the compiler portion with the (optimizing) compiler
from the (free) Visual C++ 2003 Toolkit, as described at:
http://www.sawtoothdistortion.com/Ar...gCompiler.html.
I've been using this setup since October with no problems.

Something that is more likely to be relevant is: I have my XP box
tuned way, way down in terms of the number of services it runs at
startup. I have turned off every service possible. 'COM+ System
Application', for example, isn't running because I have no idea what it
does and haven't needed it yet. Could it be that Ice::Service relies on
some Windows service I have disabled?

[michi]

From the error message, I would suspect memory corruption as the cause. Can you try using Purify?

Cheers,

Michi.

[bernard]

You don't need to have any Windows service running to use an Ice Service.

For the debug error, do you use /MDd and the *d.lib Ice libs for everything?

Cheers,
Bernard

[dwolfe5272]

I don't have a licensed copy of Purify, but I tried installing an eval
copy. I had no luck getting Purify to run my app as a Windows service,
but the (text) output from running it *without* the '--service' arg is
attached, FWIW. Is this helpful? (Purify did carp a lot about cases of
'Freeing Mismatched Memory [FMMs]', and seemed to be pointing the finger
at some Ice calls; but I've no prior experience with the utility, so I'm
not sure what to make of any of this... :-% )

[bernard]

Could you relink your exe with /FIXED:NO to get rid of the FMMs?

More details in:
http://www.zeroc.com/vbulletin/showthread.php?t=1272

Cheers,
Bernard

[dwolfe5272]

Okay, I relinked with /FIXED:NO and now the Purify output looks
clean[?]--as far as I can tell (see attached). To answer Bernhard's
earlier question: yes, I'm using /MDd and linking with Iced.lib and
IceUtild.lib.

Can anyone offer advice about using Purify when the app is run as a
service? What I tried is described below. Checking 'Allow service to
interact with the desktop' did not have the effect the Purify online
help seemed to imply it would, i.e., Purify did *not* start when I
started the service. Trying to run the instrumented app from within
Purify directly and specifying arguments of '--service ICTViewerTest'
also didn't work. Any other suggestions? :-)

----------

C:\app\bin>purify /Run=no /Out=ICTViewerBridge_pure.exe test.exe

Purify: While processing file C:\app\bin\ICTViewerBridge.exe:
Note: Incremental linking has been allowed.
Incrementally linked programs are not
supported by Purify.
Purify for Windows,
(C) Copyright IBM Corporation. 1992, 2004. All Rights Reserved.
Version 2003.06.03; Build: 5352;
WinNT 5.1 2600 Service Pack 2 Uniprocessor Free
Instrumenting:
ICTViewerBridge.exe 913408 bytes

Purify: Note: Compilation for "Edit and Continue" has been detected.
Applying changes to a running program is not
supported by Purify.

Purify: Note: Instrumentation repeating with 7 additional entry points.


C:\app\bin>test.exe --install ICTViewerBridgeTest

[Ran services.msc, right-clicked ICTViewerBridgeTest and chose
'Properties', and in 'Log On' tab checked 'Allow service to interact
with desktop'.]

C:\app\bin>test.exe --start ICTViewerBridgeTest
Service start pending.
Service is running.

C:\app\bin>test.exe --stop ICTViewerBridgeTest

[Got same error as before. Purify never started.]

[mes]

Dave,

Just for the sake of completeness, can you post the rest of your sample service (specifically the ViewerBridgeImpl)?

Thanks,
- Mark

[mes]

Dave,

You may already be aware of this issue, but you need to make sure that the service is configured to use the purified executable. For example, if purify is generating server_pure.exe, then the service needs to be configured for that executable.

Note that using the command

> server_pure --install MyServer

does not register the service for server_pure.exe. We recommend using the following command to ensure that the correct executable is used for purify:

> server --install MyServer --executable C:\Path\To\server_pure.exe

Also, this page has information on using purify with a Windows service.

Hope that helps,
- Mark

[dwolfe5272]

Sure. Please see the attached example, which is lifted almost verbatim
from section 8.3 of the Ice manual. This exhibits the same behavior
on my machine when compiled using the attached project file. (Hopefully
you'll find something blatantly wrong with the settings! :-> )

[dwolfe5272]

Mark--from your tip about how to change the service executable, I
was able to get Purify to work with my TestService program. It appears
to be crashing in ntdll.dll (see attached output file). It also flagged three
Array Bounds Write errors (all in Ice::stringSeqToArgs()), but I'm guessing these
are spurious(?)

[mes]

Hi Dave,

Thanks for the purify log. We've encountered the same issues when trying to reproduce your situation. We've already got a fix for the ABW errors, but we're still trying to track down the access violation. Unfortunately purify isn't giving us much help on that one. We'll keep you posted.

If you're willing to modify an Ice source file and rebuild the Ice library, you can fix the ABW problems by editing src\Ice\Initialize.cpp and commenting out the lines shown below in stringSeqtoArgs:

    if(argv)
    {
        argv[argc] = 0;
    }

Note that this is just a temporary (but safe) fix. A better fix will be included in the next release.

Thanks,
- Mark

[mes]

Dave,

We think we've located the problem causing the access violation. To fix it, you'll need to edit src\Ice\Service.cpp and add WINAPI as shown below:

void WINAPI
Ice_Service_ServiceMain(DWORD argc, LPTSTR* argv)
...
void WINAPI
Ice_Service_CtrlHandler(DWORD ctrl)

Let us know if that helps.

Thanks,
- Mark

[dwolfe5272]

Just checked the behavior with Ice-2.1.2 (released today), and it does,
indeed, fix the problem. Pretty impressive how quickly you guys were able to
turn around a fix--thanks! I was going to build from source with the mods you
suggested, but now I don't need to... :-)