[Wrapper-user] Re: RE: Re: Win2000 Service problem

[EXT-Smith, E. M <eri...@bo...>]

Leif,

-----Original Message-----
> There was a typo that was preventing the latest=20
> environment variable values from being loaded from=20
> the registry.  *envKeys as being tested against NULL=20
> to see if the calloc was successful.  But it should=20
> have just been envKeys (without the '*')  My tests=20
> show that this change to your patch is correct, but=20
> can you confirm this just in case I am missing something?

You're right for the *envKeys on line 1260 "if ( NULL !=3D *envKeys ) {" =
 I wanted to test for the first level array allocation, not the internal =
buffer allocation at that point.


> What were the problem(s) that you had been seeing=20
> that led you to look for, and then fix this?  As I=20
> said, I had never seen any problems arise due to=20
> the misuse of the putenv function and would like to=20
> understand the symptoms so I can answer questions=20
> posed by other users.  I also want to describe the=20
> problem being solved in the release notes.

Here's the basic sequence I followed.  It's a bit long winded, but =
fairly complete.  Item 8 details the debug info I saw that lead me to =
the problem:

1) I put valid environment variables into the config file expecting them =
to be resolved correctly.
2) I then executed the service as a console app.  Everything worked.
3) I installed the app as a service.  Still everything worked.
4) I tried running the app as a service.  The service reported starting =
and after about 10 seconds, stopping.  First sign of trouble.
5) I looked at the log and noticed a Number Format error on one of the =
environment variables.  When I looked at the variable declarations, I =
noticed the variable was declared for the "current user" instead of =
system.  Moved the variable to System, and rebooted.
6) I tried running the app as a service.  The service reported starting =
and after about 10 seconds, stopping.  Trouble still exists.
7) Tried alternately executing service as a console app and service and =
examining logs.  Continuously adding more debug statements as we =
narrowed down where the problem occurred.
8) Finally added debug statements to the method that performs the =
putenv/getenv.  After running with this, I noticed the following:
	a) The environment variable causing problems was the first environment =
variable loaded from the registry.
	b) In the first loop, the value was read in, resolved properly, =
displayed in my debug statements, and the putenv was called =
successfully.
	c) If I checked the environment immediately following the putenv, =
everything was ok.
	d) If I checked the environment after all putenv() calls, then all =
environment values except the first one (the one I needed) were =
accessible using getenv.  The first one was not there.
9) Researched the putenv()/getenv() methods and found the quote I sent =
in my last message.
10) Made the modifications I sent to you.
11) Ran numerous tests at different debugging levels to determine =
whether the patch worked.
12) Uninstalled all services and rebooted the machine (to start from a =
clean slate).
13) Reinstalled all services and launched them as services from the =
command line (all started successfully).
14) Rebooted the machine to make sure all services started.  They all =
started successfully.


On a stylistic note...

<        if (*envKeys !=3D NULL) {
            dwIndex =3D 0;

I noticed that you write your if statements in a variable -- value =
sequence. =20
As a defensive coding practice I write mine in a value -- variable =
sequence for the following reason:
	A compiler will report
		if ( NULL =3D envKeys ) { ... }		// should be if ( NULL =3D=3D envKeys =
) { ... }
			as an error.


Sincerely,

Eric M. Smith
InfoStructure Systems
Boeing Chairman's Innovation Initiative