[
https://issues.apache.org/jira/browse/DAEMON-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-163.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.0.4
Right. Pretty wired cause the Alloc calls PoolAlloc with global pool.
The code itself didn't do any harm. It just used the global pool for memory
allocation.
Cleaned up anyhow.
> __apxMultiSzToJvmOptions has odd use of IS_INVALID_HANDLE
> ---------------------------------------------------------
>
> Key: DAEMON-163
> URL: https://issues.apache.org/jira/browse/DAEMON-163
> Project: Commons Daemon
> Issue Type: Bug
> Reporter: Sebb
> Fix For: 1.0.4
>
>
> __apxMultiSzToJvmOptions has odd use of IS_INVALID_HANDLE:
> {code}
> if (IS_INVALID_HANDLE(hPool))
> buff = apxPoolAlloc(hPool, (n + 1) * sizeof(JavaVMOption) + (l + 1));
> else
> buff = apxAlloc((n + 1) * sizeof(JavaVMOption) + (l + 1));
> {code}
> The condition appears to be the wrong way round.
> However, the method apxPoolAlloc also checks for IS_INVALID_HANDLE, and if
> true, the code resolves to calling
> __apxPoolAllocCore(_st_sys_pool, dwSize, 0)
> which is exactly what apxAlloc() does. As far as I can tell, the hPool
> parameter is never used here.
> If that is the intention, then just keep the code in the else part of the
> statement.
> If not, then just keep the code in the if part of the statement.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
