Major Description
When I tried to use commons daemon 1.0.8 for a project, after successfully installing the service, starting it on Windows 7 failed reliably, and it failed sporadically on other platforms. I traced the problem to a heap corruption bug due to an over-long pointer write in utils.c, line 321.
The original line (inside of apxMultiSzToArrayW) reads:
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR) + sizeof(WCHAR));
The fix is to remove the "+ sizeof(WCHAR)" from the line, leaving it as
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR));
Note that you've already taken care of the terminating null inside of "l". After I'd made that change and rebuilt, things worked happily for me. Please could you include this fix in a subsequent release.
To reproduce:
1. Ensure that you do NOT have a JRE or a JDK installed on the target machine.
2. Create a folder structure something like
\MyApp\Jetty
\MyApp\jre7 <<----- copy a JRE into here, but do NOT run the JRE installation
\MyApp\Jetty\bin <<------ place prunsrv.exe here
3. Ensure that you do not have the JRE on your system path
4. Install the service via the command line:
C:\MyApp\Jetty\bin\prunsrv.exe install MyService --DisplayName="My Service" --Install=C:\MyApp\Jetty\bin\prunsrv.exe
--LogPath=C:\MyApp\Jetty\logs --LogLevel=Info --StdOutput=auto --StdError=auto --StartMode=jvm --StopMode=jvm
--JavaHome="C:\MyApp\jre7" --Jvm="C:\MyApp\jre7\bin\client\jvm.dll" --Startup=auto --StartPath=C:\MyApp\Jetty
--Classpath=C:\MyApp\Jetty\start.jar;C:\MyApp\Jetty\commons-daemon-1.0.8.jar
++StartParams=--daemon --StartClass=org.eclipse.jetty.start.Main
--StopClass=org.eclipse.jetty.start.Main ++StopParams=--stop
++JvmOptions=-Djetty.home=C:\MyApp\Jetty ++JvmOptions=-Djetty.port=80
++JvmOptions=-DSTOP.PORT=9131 ++JvmOptions=-DSTOP.KEY=stopMyApp
5. Start the service via "net start MyService". Observe that it fails to start.
Depending on the machine, sometimes it started and sometimes it failed to start.
The joys of heap corruption ...
Anyway, I debugged this with Visual Studio 2010 and used the data change breakpoint to observe the memory write (2 bytes beyond the end of the allocated block).