You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Andy Cooper (Created) (JIRA)" <ji...@apache.org> on 2011/12/19 20:27:30 UTC
[jira] [Created] (DAEMON-233) Heap corruption in apxMultiSzToArrayW
for windows procrun
Heap corruption in apxMultiSzToArrayW for windows procrun
---------------------------------------------------------
Key: DAEMON-233
URL: https://issues.apache.org/jira/browse/DAEMON-233
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.8
Environment: All windows versions.
Reporter: Andy Cooper
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).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-233) Heap corruption in apxMultiSzToArrayW
for windows procrun
Posted by "Sebb (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DAEMON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated DAEMON-233:
------------------------
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:
{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 --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 ...
{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).
was:
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).
Make command easier to read
> Heap corruption in apxMultiSzToArrayW for windows procrun
> ---------------------------------------------------------
>
> Key: DAEMON-233
> URL: https://issues.apache.org/jira/browse/DAEMON-233
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
> Affects Versions: 1.0.8
> Environment: All windows versions.
> Reporter: Andy Cooper
> Assignee: Mladen Turk
>
> 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 --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 ...
> {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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-233) Heap corruption in
apxMultiSzToArrayW for windows procrun
Posted by "Mladen Turk (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DAEMON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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: https://issues.apache.org/jira/browse/DAEMON-233
> 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 --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 ...
> {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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-233) Heap corruption in
apxMultiSzToArrayW for windows procrun
Posted by "Mladen Turk (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DAEMON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172555#comment-13172555 ]
Mladen Turk commented on DAEMON-233:
------------------------------------
Sure, good catch.
> Heap corruption in apxMultiSzToArrayW for windows procrun
> ---------------------------------------------------------
>
> Key: DAEMON-233
> URL: https://issues.apache.org/jira/browse/DAEMON-233
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
> Affects Versions: 1.0.8
> Environment: All windows versions.
> Reporter: Andy Cooper
> Assignee: Mladen Turk
>
> 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).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira