]
Jan Andres updated MODCLUSTER-381:
----------------------------------
Attachment: mod_cluster-1.2.6-20140109.diff
[Patch] Stability and portability issues in native code
-------------------------------------------------------
Key: MODCLUSTER-381
URL:
https://issues.jboss.org/browse/MODCLUSTER-381
Project: mod_cluster
Issue Type: Patch
Affects Versions: 1.2.6.Final
Reporter: Jan Andres
Assignee: Jean-Frederic Clere
Attachments: mod_cluster-1.2.6-20140109.diff
Hi,
Please find attached a patch for some issues I came across while deploying mod_cluster
for Apache on Solaris/SPARC. The patch applies to the 1.2.6 release and addresses a total
of 3 issues:
1. A memory leak in add_balancers_workers(). The current code will allocate new memory
from the config pool for the balancer's "sticky" parameter on each update
but throw away the pointer (thus losing memory) if the value generated equals the
balancer's current value. The patch changes this to first do the apr_psprintf() from a
temporary pool and only apr_pstrdup() this temporary string into the config pool in case
it differs from the old value and actually needs to be updated.
2. Memory alignment issues. Some parts of the code use custom memory alignment logic and
will generally align memory blocks to a multiple of sizeof(void*). This poses a problem on
some architectures such a 64-bit SPARC CPU running a "32-bit application" which
really means the process has a 32-bit memory space (i.e. sizeof(void*) is 4), but can
still use native 64-bit instructions to operate on data. On SPARC and some other
architectures, these instructions require 8-byte data alignment and will lead to a Bus
error if this is not observed. The patch replaces the custom alignment logic by
invocations of APR_ALIGN_DEFAULT() which also makes the code somewhat more concise and
readable.
3. Heap corruption issues on process exit, sometimes resulting in core dumps, because
mod_proxy_cluster's watchdog thread never terminates and continues to run while the
main thread is already freeing up resources and destroying all the memory pools. The patch
adds a mechanism to signal the watchdog thread to terminate and wait for it to exit prior
to the freeing of the memory resources. This mechanism is invoked via a pre-cleanup hook
on the config pool.
Regards,
Jan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: