commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk (Resolved) (JIRA)" <>
Subject [jira] [Resolved] (DAEMON-233) Heap corruption in apxMultiSzToArrayW for windows procrun
Date Wed, 01 Feb 2012 14:24:58 GMT


Mladen Turk resolved DAEMON-233.

       Resolution: Fixed
    Fix Version/s: 1.0.9

Fixed in the 1.0.x branch. Will be part of 1.0.9 release
> Heap corruption in apxMultiSzToArrayW for windows procrun
> ---------------------------------------------------------
>                 Key: DAEMON-233
>                 URL:
>             Project: Commons Daemon
>          Issue Type: Bug
>          Components: Procrun
>    Affects Versions: 1.0.8
>         Environment: All windows versions. 
>            Reporter: Andy Cooper
>            Assignee: Mladen Turk
>             Fix For: 1.0.9
> 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:
> {noformat}
> 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
> --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 ...
> {noformat}
> 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).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message