Visits log fails without any error · Issue #15307 · matomo-org/matomo · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Visits log fails without any error #15307

Closed
tsteur opened this issue Dec 22, 2019 · 5 comments · Fixed by #15471
Closed

Visits log fails without any error #15307

tsteur opened this issue Dec 22, 2019 · 5 comments · Fixed by #15471
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc.

Comments

@tsteur
Copy link
Member

tsteur commented Dec 22, 2019

Been debugging the visitor log for few hours which fails with no seg fault, no error, no shutdown function call, no warning, ...

Matomo shows this:
image

Request looks like this:
image

After a while noticed it seems to crash at https://github.com/matomo-org/matomo/blob/3.13.1-b1/core/View.php#L278 particularly when sending a header in https://github.com/matomo-org/matomo/blob/3.13.1-b1/core/ProxyHttp.php#L235-L238

In my visit log I'm showing 10 visits, some of them have a few actions but nothing crazy. As soon as I disable the header function in Common::sendHeader the page renders nicely.

Thought it sends maybe too many headers but this is not the case. Headers weren't sent yet when crashing.
image

This is PHP Version 7.3.12 and using Apache 2.4. Must be some kind of PHP bug I would say. Just thought I create the issue in case someone experiences similar.

@tsteur tsteur added the Bug For errors / faults / flaws / inconsistencies etc. label Dec 22, 2019
@tsteur
Copy link
Member Author

tsteur commented Dec 22, 2019

The page also renders nicely if commenting out all of these sendHeaders: https://github.com/matomo-org/matomo/blob/3.13.1-b1/core/View.php#L278-L290

It renders the view easily > 100 times in my visit log since there are various actions and each action is a view render and we try again and again to send some headers (replace previous).

Even just having still one line that sends header in the View class crashes the visit log. Meaning it seems really to be an issue that a header may be replaced too often and then PHP crashes

@tsteur
Copy link
Member Author

tsteur commented Jan 27, 2020

FYI this is a segmentation fault

[Mon Jan 27 16:11:30.661296 2020] [core:notice] [pid 27670] AH00052: child pid 27690 exit signal Segmentation fault

Upgraded to PHP 7.4 and error still happens. Also happens when disabling xdebug etc.

Here's some info

Process:               httpd [27842]
Path:                  /usr/sbin/httpd
Identifier:            httpd
Version:               2.4.33 (852)
Code Type:             X86-64 (Native)
Parent Process:        httpd [27807]
Responsible:           httpd [27842]
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGBUS)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x000000010fa0a325
Exception Note:        EXC_CORPSE_NOTIFY


VM Regions Near 0x10fa0a325:
    __LINKEDIT             000000010f95c000-000000010f964000 [   32K] r--/rwx SM=COW  /usr/libexec/apache2/mod_rewrite.so
--> __TEXT                 000000010f964000-0000000110509000 [ 11.6M] r-x/rwx SM=COW  /usr/local/Cellar/php/7.4.2/lib/httpd/modules/libphp7.so
    __DATA_CONST           0000000110509000-00000001105c1000 [  736K] r--/rwx SM=COW  /usr/local/Cellar/php/7.4.2/lib/httpd/modules/libphp7.so

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libapr-1.0.dylib              	0x000000011071df93 allocator_alloc + 376
1   libapr-1.0.dylib              	0x000000011071e520 apr_palloc + 97
2   libapr-1.0.dylib              	0x000000011071571a apr_pstrdup + 46
3   libapr-1.0.dylib              	0x000000011071816a apr_table_set + 329
4   libphp7.so                    	0x000000010fd6882e php_apache_sapi_header_handler + 306
5   libphp7.so                    	0x000000010fc9382c sapi_header_add_op + 42
6   libphp7.so                    	0x000000010fc9366b sapi_header_op + 1614
7   libphp7.so                    	0x000000010fc0941b zif_header + 148
8   libphp7.so                    	0x000000010fd514d8 ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_UNUSED_HANDLER + 267
9   libphp7.so                    	0x000000010fd1fccf execute_ex + 35
10  libphp7.so                    	0x000000010fcd5040 zend_call_function + 1230
11  libphp7.so                    	0x000000010fbf630b zif_call_user_func_array + 173
12  libphp7.so                    	0x000000010fd514d8 ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_UNUSED_HANDLER + 267
13  libphp7.so                    	0x000000010fd1fccf execute_ex + 35
14  libphp7.so                    	0x000000010fcd5040 zend_call_function + 1230
15  libphp7.so                    	0x000000010fbf630b zif_call_user_func_array + 173
16  libphp7.so                    	0x000000010fd51767 ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_USED_HANDLER + 284
17  libphp7.so                    	0x000000010fd1fccf execute_ex + 35
18  libphp7.so                    	0x000000010fd1fe87 zend_execute + 352
19  libphp7.so                    	0x000000010fce2a35 zend_execute_scripts + 338
20  libphp7.so                    	0x000000010fc8b70c php_execute_script + 482
21  libphp7.so                    	0x000000010fd68356 php_handler + 1139
22  httpd                         	0x000000010f676b02 ap_run_handler + 98
23  httpd                         	0x000000010f677358 ap_invoke_handler + 392
24  httpd                         	0x000000010f6dd034 ap_process_async_request + 3060
25  httpd                         	0x000000010f6dd114 ap_process_request + 36
26  httpd                         	0x000000010f6d7d10 ap_process_http_sync_connection + 240
27  httpd                         	0x000000010f6d787c ap_process_http_connection + 76
28  httpd                         	0x000000010f695f62 ap_run_process_connection + 98
29  httpd                         	0x000000010f696725 ap_process_connection + 101
30  mod_mpm_prefork.so            	0x000000010f7c154e child_main + 2446
31  mod_mpm_prefork.so            	0x000000010f7c03f8 make_child + 488
32  mod_mpm_prefork.so            	0x000000010f7c0a95 perform_idle_server_maintenance + 1349
33  mod_mpm_prefork.so            	0x000000010f7bf873 prefork_run + 2643
34  httpd                         	0x000000010f699922 ap_run_mpm + 114
35  httpd                         	0x000000010f6838db main + 4171
36  libdyld.dylib                 	0x00007fff67e2b7fd start + 1


Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000016  rbx: 0x000000010fa0a325  rcx: 0x0000000000000000  rdx: 0x000000011b6d4c01
  rdi: 0x00007fcd1f08ea30  rsi: 0x0000020000000000  rbp: 0x00007ffee0589210  rsp: 0x00007ffee05891e0
   r8: 0x000000011b6d4c90   r9: 0x0000000113013510  r10: 0x000000010fd896d2  r11: 0xffffffffffc9b138
  r12: 0x0000000000000001  r13: 0x0000000043414348  r14: 0x00007fcd21322940  r15: 0x0000000000002000
  rip: 0x000000011071df93  rfl: 0x0000000000000202  cr2: 0x000000010fa0a325

  
Logical CPU:     0
Error Code:      0x020000b8
Trap Number:     133

@mattab
Copy link
Member

mattab commented Jan 27, 2020

Works for me on php 7.3.11 without segfault (both CLI and web)

@tsteur
Copy link
Member Author

tsteur commented Jan 27, 2020

BTW I just checked MacOS is actually using Apache Handler by the looks by default so the issue could be there.

@tsteur
Copy link
Member Author

tsteur commented Jan 27, 2020

In case someone experiences this issue, I could reproduce the seg fault using this code:

for ($i = 0; $i < 400; $i++) {

    header('Content-Type: ' . 'text/html');
    header('Referrer-Policy: same-origin');
}
echo 'foo';

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants