[mod_cluster-issues] [JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup
Michal Karm Babacek (JIRA)
issues at jboss.org
Wed Jul 20 17:12:00 EDT 2016
[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michal Karm Babacek updated MODCLUSTER-526:
-------------------------------------------
Description:
h3. Setup
* 3 tomcats
* 2 load balancing groups
* 1 request every 3 seconds (no load at all)
* shutdown and kill of various nodes
* no later than third kill/start iteration causes SIGSEGV
h3. SIGSEGV
{code}
#if AP_MODULE_MAGIC_AT_LEAST(20101223,1)
/* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */
helper->index = 0; /* mark it removed */
worker->s = helper->shared;
crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared));
#else
worker->id = 0; /* mark it removed */
#endif
{code}
h3. Behavior
{code}
957 helper = (proxy_cluster_helper *) worker->context;
961 if (helper) {
962 i = helper->count_active;
963 }
968 if (i == 0) {
971 proxy_worker_shared *stat = worker->s;
972 proxy_cluster_helper *helper = (proxy_cluster_helper *) worker->context;
{code}
At this point, {{helper->shared}} points to a {{proxy_worker_shared}} structure that appears to be properly filled.
{code}
999 if (worker->cp->pool) {
1000 apr_pool_destroy(worker->cp->pool);
1001 worker->cp->pool = NULL;
1002 }
{code}
Regardless of the aforementioned block being there or nor (stuffed after 1010),
{{helper->shared}} suddenly points to {{NULL}}.
{code}
1008 helper->index = 0;
1009 worker->s = helper->shared;
{code}
Above assignment makes {{worker->s}} pointing to NULL.
{code}
1010 memcpy(worker->s, stat, sizeof(proxy_worker_shared));
{code}
And here we go :(
IMHO, _other thread_ already cleared that memory and nulled the pointer, because it absolutely doesn't happen if
I run 1 process and 1 thread.
The [workaround that prevents the core|https://github.com/modcluster/mod_cluster/pull/207] looks like this:
{code}
if (helper->shared) {
worker->s = helper->shared;
memcpy(worker->s, stat, sizeof(proxy_worker_shared));
}
{code}
was:
* 3 tomcats
* 2 load balancing groups
* 1 request every 3 seconds (no load at all)
* shutdown and kill of various nodes
* no later than third kill/start iteration causes SIGSEGV
{code}
#if AP_MODULE_MAGIC_AT_LEAST(20101223,1)
/* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */
helper->index = 0; /* mark it removed */
worker->s = helper->shared;
crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared));
#else
worker->id = 0; /* mark it removed */
#endif
{code}
> SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup
> -----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-526
> URL: https://issues.jboss.org/browse/MODCLUSTER-526
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.3.3.Final
> Environment: Fedora 20, x86_64, httpd 2.4.20
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Blocker
> Fix For: 1.3.4.Final
>
>
> h3. Setup
> * 3 tomcats
> * 2 load balancing groups
> * 1 request every 3 seconds (no load at all)
> * shutdown and kill of various nodes
> * no later than third kill/start iteration causes SIGSEGV
> h3. SIGSEGV
> {code}
> #if AP_MODULE_MAGIC_AT_LEAST(20101223,1)
> /* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */
> helper->index = 0; /* mark it removed */
> worker->s = helper->shared;
> crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared));
> #else
> worker->id = 0; /* mark it removed */
> #endif
> {code}
> h3. Behavior
> {code}
> 957 helper = (proxy_cluster_helper *) worker->context;
> 961 if (helper) {
> 962 i = helper->count_active;
> 963 }
> 968 if (i == 0) {
> 971 proxy_worker_shared *stat = worker->s;
> 972 proxy_cluster_helper *helper = (proxy_cluster_helper *) worker->context;
> {code}
> At this point, {{helper->shared}} points to a {{proxy_worker_shared}} structure that appears to be properly filled.
> {code}
> 999 if (worker->cp->pool) {
> 1000 apr_pool_destroy(worker->cp->pool);
> 1001 worker->cp->pool = NULL;
> 1002 }
> {code}
> Regardless of the aforementioned block being there or nor (stuffed after 1010),
> {{helper->shared}} suddenly points to {{NULL}}.
> {code}
> 1008 helper->index = 0;
> 1009 worker->s = helper->shared;
> {code}
> Above assignment makes {{worker->s}} pointing to NULL.
> {code}
> 1010 memcpy(worker->s, stat, sizeof(proxy_worker_shared));
> {code}
> And here we go :(
> IMHO, _other thread_ already cleared that memory and nulled the pointer, because it absolutely doesn't happen if
> I run 1 process and 1 thread.
> The [workaround that prevents the core|https://github.com/modcluster/mod_cluster/pull/207] looks like this:
> {code}
> if (helper->shared) {
> worker->s = helper->shared;
> memcpy(worker->s, stat, sizeof(proxy_worker_shared));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the mod_cluster-issues
mailing list