[JBoss JIRA] (MODCLUSTER-623) Ditch 32bit mod_proxy_cluster builds
by Michal Karm Babacek (JIRA)
Michal Karm Babacek created MODCLUSTER-623:
----------------------------------------------
Summary: Ditch 32bit mod_proxy_cluster builds
Key: MODCLUSTER-623
URL: https://issues.jboss.org/browse/MODCLUSTER-623
Project: mod_cluster
Issue Type: Bug
Components: CI & Packaging
Affects Versions: 2.0.0.Alpha1
Environment: Windows
Reporter: Michal Karm Babacek
Assignee: Michal Karm Babacek
Trimming down the build & test matrix. 32bit builds are being deprecated and removed from CI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (MODCLUSTER-622) segfault in process_info
by Hisanobu Okuda (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-622?page=com.atlassian.jira.pl... ]
Hisanobu Okuda commented on MODCLUSTER-622:
-------------------------------------------
[~jfclere], Please review my suspected fix.
I think node.c has some thread-unsafe code and it should be :
{code}
[hokuda@dhcp-193-78 mod_manager]$ diff -p node.c.org node.c
*** node.c.org 2016-06-04 00:28:21.000000000 +0900
--- node.c 2017-10-16 16:40:54.435649902 +0900
*************** apr_status_t insert_update_node(mem_t *s
*** 137,143 ****
memcpy(ou, node, sizeof(nodeinfo_t));
ou->mess.id = ident;
*id = ident;
- s->storage->ap_slotmem_unlock(s->slotmem);
ou->updatetime = apr_time_now();
/* set of offset to the proxy_worker_stat */
--- 137,142 ----
*************** apr_status_t insert_update_node(mem_t *s
*** 147,152 ****
--- 146,153 ----
/* blank the proxy status information */
memset(&(ou->stat), '\0', SIZEOFSCORE);
+ s->storage->ap_slotmem_unlock(s->slotmem);
+
return APR_SUCCESS;
}
*************** nodeinfo_t * read_node(mem_t *s, nodeinf
*** 188,194 ****
*/
apr_status_t get_node(mem_t *s, nodeinfo_t **node, int ids)
{
! return(s->storage->ap_slotmem_mem(s->slotmem, ids, (void **) node));
}
/**
--- 189,198 ----
*/
apr_status_t get_node(mem_t *s, nodeinfo_t **node, int ids)
{
! s->storage->ap_slotmem_lock(s->slotmem);
! apr_status_t status = s->storage->ap_slotmem_mem(s->slotmem, ids, (void **) node);
! s->storage->ap_slotmem_unlock(s->slotmem);
! return(status);
}
/**
[hokuda@dhcp-193-78 mod_manager]$
{code}
> segfault in process_info
> ------------------------
>
> Key: MODCLUSTER-622
> URL: https://issues.jboss.org/browse/MODCLUSTER-622
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.13.Final
> Environment: see the private comment
> Reporter: Hisanobu Okuda
> Assignee: Jean-Frederic Clere
>
> Segfault occured at process_info.
> {code}
> (gdb) bt
> #0 process_info (r=0x7f01039b7088, errtype=<value optimized out>) at mod_manager.c:1150
> #1 0x00007f00fd15b44a in manager_handler (r=0x7f01039b7088) at mod_manager.c:2705
> #2 0x00007f0102927640 in ap_run_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:158
> #3 0x00007f010292aefe in ap_invoke_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:376
> #4 0x00007f0102936300 in ap_process_request (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
> #5 0x00007f0102933178 in ap_process_http_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
> #6 0x00007f010292f148 in ap_run_process_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/server/connection.c:43
> #7 0x00007f010293c052 in process_socket (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:544
> #8 worker_thread (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:894
> #9 0x00007f01011d19d1 in ?? ()
> #10 0x00007f00d8dda700 in ?? ()
> #11 0x0000000000000000 in ?? ()
> {code}
> {code}
> (gdb) disassemble
> ...
> 0x00007f00fd1558f4 <+452>: mov 0x58(%rsp),%rax
> 0x00007f00fd1558f9 <+457>: lea 0x82f0(%rip),%rsi # 0x7f00fd15dbf0
> 0x00007f00fd155900 <+464>: mov %r13,%rdi
> 0x00007f00fd155903 <+467>: add 0x138(%rax),%rax
> => 0x00007f00fd15590a <+474>: mov 0xc0(%rax),%r9
> {code}
> {code}
> (gdb) x/gx $rsp+0x58
> 0x7f00d8dd9b98: 0x00007f01028d4e60
> (gdb) x/gx 0x00007f01028d4e60+0x138
> 0x7f01028d4f98: 0x0000000000000140
> (gdb) print/x 0x00007f01028d4e60+0x140
> $1 = 0x7f01028d4fa0
> (gdb) # therefore, rax should be 0x7f01028d4fa0, but in fact:
> (gdb) info registers rax
> rax 0xfe01a299c750 279282976409424
> (gdb)
> {code}
> It looks occurring under race condition.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (MODCLUSTER-606) Documentation Error - Chapter 10 - Time decay formulas
by Leandro Quiroga (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-606?page=com.atlassian.jira.pl... ]
Leandro Quiroga updated MODCLUSTER-606:
---------------------------------------
Git Pull Request: https://github.com/modcluster/modcluster.io/pull/2
> Documentation Error - Chapter 10 - Time decay formulas
> ------------------------------------------------------
>
> Key: MODCLUSTER-606
> URL: https://issues.jboss.org/browse/MODCLUSTER-606
> Project: mod_cluster
> Issue Type: Bug
> Components: Documentation & Demos
> Affects Versions: 1.2.13.Final, 1.3.7.Final
> Reporter: Leandro Quiroga
> Assignee: Jean-Frederic Clere
> Priority: Minor
> Labels: documentation
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> In chapter 10 (http://docs.jboss.org/mod_cluster/1.3.0/html_single/#java.load), it says:
> The DynamicLoadBalanceFactorProvider applies a time decay function to the loads returned by each metric. The aggregate load, with respect to previous load values, can be expressed by the following formula:
> L = (L ~0~ + L ~1~/D + L ~2~/D ^2^ + L ~3~/D ^3^ + ... + L ~H~/D ^H^) * (1 + D + D ^2^ + D ^3^ + ... D ^H^)
> ... or more concisely as:
> L = (∑^H^~i=0~ L ~i~/D ^i^) * (∑^H^~i=0~ D ^i^)
> ... where D = decayFactor, and H = history.
>
> But both formulas are wrong.
> It should says:
> The DynamicLoadBalanceFactorProvider applies a time decay function to the loads returned by each metric. The aggregate load, with respect to previous load values, can be expressed by the following formula:
> L = (L ~0~*/D ^0^* + L ~1~/D *^1^* + L ~2~/D ^2^ + L ~3~/D ^3^ + ... + L ~H~/D ^H^) */ (1/D ^0^ + 1/D ^1^ + 1/D ^2^ + 1/D ^3^ + ... 1/D ^H^)*
> ... or more concisely as:
> L = (∑^H^~i=0~ L ~i~/D ^i^) */* (∑^H^~i=0~ *1/* D ^i^)
> ... where D = decayFactor, and H = history.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (MODCLUSTER-622) segfault in process_info
by Hisanobu Okuda (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-622?page=com.atlassian.jira.pl... ]
Hisanobu Okuda commented on MODCLUSTER-622:
-------------------------------------------
[~jfclere] Thank you for paying attention!
{code}
[root@rhel6pek work]# ./opencore.sh
...
Program terminated with signal 11, Segmentation fault.
#0 process_info (r=0x7f01039b7088, errtype=<value optimized out>) at mod_manager.c:1150
1150 ap_rprintf(r, ",Elected: %d,Read: %d,Transfered: %d,Connected: %d,Load: %d\n",
(gdb) print ou->offset
$1 = 320
(gdb) print/x ou->offset
$2 = 0x140
{code}
> segfault in process_info
> ------------------------
>
> Key: MODCLUSTER-622
> URL: https://issues.jboss.org/browse/MODCLUSTER-622
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.13.Final
> Environment: see the private comment
> Reporter: Hisanobu Okuda
> Assignee: Jean-Frederic Clere
>
> Segfault occured at process_info.
> {code}
> (gdb) bt
> #0 process_info (r=0x7f01039b7088, errtype=<value optimized out>) at mod_manager.c:1150
> #1 0x00007f00fd15b44a in manager_handler (r=0x7f01039b7088) at mod_manager.c:2705
> #2 0x00007f0102927640 in ap_run_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:158
> #3 0x00007f010292aefe in ap_invoke_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:376
> #4 0x00007f0102936300 in ap_process_request (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
> #5 0x00007f0102933178 in ap_process_http_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
> #6 0x00007f010292f148 in ap_run_process_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/server/connection.c:43
> #7 0x00007f010293c052 in process_socket (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:544
> #8 worker_thread (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:894
> #9 0x00007f01011d19d1 in ?? ()
> #10 0x00007f00d8dda700 in ?? ()
> #11 0x0000000000000000 in ?? ()
> {code}
> {code}
> (gdb) disassemble
> ...
> 0x00007f00fd1558f4 <+452>: mov 0x58(%rsp),%rax
> 0x00007f00fd1558f9 <+457>: lea 0x82f0(%rip),%rsi # 0x7f00fd15dbf0
> 0x00007f00fd155900 <+464>: mov %r13,%rdi
> 0x00007f00fd155903 <+467>: add 0x138(%rax),%rax
> => 0x00007f00fd15590a <+474>: mov 0xc0(%rax),%r9
> {code}
> {code}
> (gdb) x/gx $rsp+0x58
> 0x7f00d8dd9b98: 0x00007f01028d4e60
> (gdb) x/gx 0x00007f01028d4e60+0x138
> 0x7f01028d4f98: 0x0000000000000140
> (gdb) print/x 0x00007f01028d4e60+0x140
> $1 = 0x7f01028d4fa0
> (gdb) # therefore, rax should be 0x7f01028d4fa0, but in fact:
> (gdb) info registers rax
> rax 0xfe01a299c750 279282976409424
> (gdb)
> {code}
> It looks occurring under race condition.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 6 months
[JBoss JIRA] (MODCLUSTER-622) segfault in process_info
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-622?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-622:
------------------------------------------------
https://github.com/modcluster/mod_cluster/blob/1.2.x/native/mod_manager/m...
Could you please check the value of ou->offset?
> segfault in process_info
> ------------------------
>
> Key: MODCLUSTER-622
> URL: https://issues.jboss.org/browse/MODCLUSTER-622
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.13.Final
> Environment: see the private comment
> Reporter: Hisanobu Okuda
> Assignee: Jean-Frederic Clere
>
> Segfault occured at process_info.
> {code}
> (gdb) bt
> #0 process_info (r=0x7f01039b7088, errtype=<value optimized out>) at mod_manager.c:1150
> #1 0x00007f00fd15b44a in manager_handler (r=0x7f01039b7088) at mod_manager.c:2705
> #2 0x00007f0102927640 in ap_run_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:158
> #3 0x00007f010292aefe in ap_invoke_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:376
> #4 0x00007f0102936300 in ap_process_request (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
> #5 0x00007f0102933178 in ap_process_http_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
> #6 0x00007f010292f148 in ap_run_process_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/server/connection.c:43
> #7 0x00007f010293c052 in process_socket (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:544
> #8 worker_thread (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:894
> #9 0x00007f01011d19d1 in ?? ()
> #10 0x00007f00d8dda700 in ?? ()
> #11 0x0000000000000000 in ?? ()
> {code}
> {code}
> (gdb) disassemble
> ...
> 0x00007f00fd1558f4 <+452>: mov 0x58(%rsp),%rax
> 0x00007f00fd1558f9 <+457>: lea 0x82f0(%rip),%rsi # 0x7f00fd15dbf0
> 0x00007f00fd155900 <+464>: mov %r13,%rdi
> 0x00007f00fd155903 <+467>: add 0x138(%rax),%rax
> => 0x00007f00fd15590a <+474>: mov 0xc0(%rax),%r9
> {code}
> {code}
> (gdb) x/gx $rsp+0x58
> 0x7f00d8dd9b98: 0x00007f01028d4e60
> (gdb) x/gx 0x00007f01028d4e60+0x138
> 0x7f01028d4f98: 0x0000000000000140
> (gdb) print/x 0x00007f01028d4e60+0x140
> $1 = 0x7f01028d4fa0
> (gdb) # therefore, rax should be 0x7f01028d4fa0, but in fact:
> (gdb) info registers rax
> rax 0xfe01a299c750 279282976409424
> (gdb)
> {code}
> It looks occurring under race condition.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 6 months
[JBoss JIRA] (MODCLUSTER-622) segfault in process_info
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-622?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-622:
------------------------------------------------
So it cores in https://github.com/modcluster/mod_cluster/blob/1.2.x/native/mod_manager/m...
correct?
How often does that occurs?
> segfault in process_info
> ------------------------
>
> Key: MODCLUSTER-622
> URL: https://issues.jboss.org/browse/MODCLUSTER-622
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.13.Final
> Environment: see the private comment
> Reporter: Hisanobu Okuda
> Assignee: Jean-Frederic Clere
>
> Segfault occured at process_info.
> {code}
> (gdb) bt
> #0 process_info (r=0x7f01039b7088, errtype=<value optimized out>) at mod_manager.c:1150
> #1 0x00007f00fd15b44a in manager_handler (r=0x7f01039b7088) at mod_manager.c:2705
> #2 0x00007f0102927640 in ap_run_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:158
> #3 0x00007f010292aefe in ap_invoke_handler (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/server/config.c:376
> #4 0x00007f0102936300 in ap_process_request (r=0x7f01039b7088) at /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
> #5 0x00007f0102933178 in ap_process_http_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
> #6 0x00007f010292f148 in ap_run_process_connection (c=0x7f00f00ebba0) at /usr/src/debug/httpd-2.2.15/server/connection.c:43
> #7 0x00007f010293c052 in process_socket (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:544
> #8 worker_thread (thd=0x7f010393a1b0, dummy=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/worker/worker.c:894
> #9 0x00007f01011d19d1 in ?? ()
> #10 0x00007f00d8dda700 in ?? ()
> #11 0x0000000000000000 in ?? ()
> {code}
> {code}
> (gdb) disassemble
> ...
> 0x00007f00fd1558f4 <+452>: mov 0x58(%rsp),%rax
> 0x00007f00fd1558f9 <+457>: lea 0x82f0(%rip),%rsi # 0x7f00fd15dbf0
> 0x00007f00fd155900 <+464>: mov %r13,%rdi
> 0x00007f00fd155903 <+467>: add 0x138(%rax),%rax
> => 0x00007f00fd15590a <+474>: mov 0xc0(%rax),%r9
> {code}
> {code}
> (gdb) x/gx $rsp+0x58
> 0x7f00d8dd9b98: 0x00007f01028d4e60
> (gdb) x/gx 0x00007f01028d4e60+0x138
> 0x7f01028d4f98: 0x0000000000000140
> (gdb) print/x 0x00007f01028d4e60+0x140
> $1 = 0x7f01028d4fa0
> (gdb) # therefore, rax should be 0x7f01028d4fa0, but in fact:
> (gdb) info registers rax
> rax 0xfe01a299c750 279282976409424
> (gdb)
> {code}
> It looks occurring under race condition.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 6 months