php segmentation fault on /public.php/webdav/ #10241
Comments
|
Here is another stack trace slightly different but in the same vicinity Program received signal SIGSEGV, Segmentation fault.
0x00005555559ef629 in zend_hash_str_find ()
(gdb) bt
#0 0x00005555559ef629 in zend_hash_str_find ()
#1 0x000055555566cef4 in ?? ()
#2 0x000055555566f00a in get_timezone_info ()
#3 0x000055555567009d in php_format_date ()
#4 0x0000555555a85b13 in ?? ()
#5 0x0000555555a886d8 in ?? ()
#6 0x0000555555a88dc9 in ?? ()
#7 0x0000555555a89ec9 in ?? ()
#8 0x0000555555666dec in ?? ()
#9 0x00007ffff570a2e1 in __libc_start_main (main=0x555555666a10, argc=3,
argv=0x7fffffffe9b8, init=, fini=,
rtld_fini=, stack_end=0x7fffffffe9a8)
at ../csu/libc-start.c:291
#10 0x0000555555666ffa in _start ()
|
|
Valgrind finds an error too # valgrind --tool=memcheck -- php -S 0.0.0.0:80 ==35== Memcheck, a memory error detector ==35== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==35== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==35== Command: php -S 0.0.0.0:80 ==35== PHP 7.1.19 Development Server started at Sat Jul 14 23:08:15 2018 Listening on http://0.0.0.0:80 Document root is /opt/nextcloud Press Ctrl-C to quit. [Sat Jul 14 23:08:48 2018] 172.17.0.1:53832 [201]: /public.php/webdav/owl.carousel.css ==35== Invalid read of size 4 ==35== at 0x5A3642: zend_hash_str_find (in /usr/local/bin/php) ==35== by 0x220EF3: ??? (in /usr/local/bin/php) ==35== by 0x223009: get_timezone_info (in /usr/local/bin/php) ==35== by 0x22409C: php_format_date (in /usr/local/bin/php) ==35== by 0x639B12: ??? (in /usr/local/bin/php) ==35== by 0x63C6D7: ??? (in /usr/local/bin/php) ==35== by 0x63CFFD: ??? (in /usr/local/bin/php) ==35== by 0x63DEC8: ??? (in /usr/local/bin/php) ==35== by 0x21ADEB: ??? (in /usr/local/bin/php) ==35== by 0x71A82E0: (below main) (libc-start.c:291) ==35== Address 0x1c736d44 is not stack'd, malloc'd or (recently) free'd ==35== ==35== ==35== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==35== Access not within mapped region at address 0x1C736D44 ==35== at 0x5A3642: zend_hash_str_find (in /usr/local/bin/php) ==35== by 0x220EF3: ??? (in /usr/local/bin/php) ==35== by 0x223009: get_timezone_info (in /usr/local/bin/php) ==35== by 0x22409C: php_format_date (in /usr/local/bin/php) ==35== by 0x639B12: ??? (in /usr/local/bin/php) ==35== by 0x63C6D7: ??? (in /usr/local/bin/php) ==35== by 0x63CFFD: ??? (in /usr/local/bin/php) ==35== by 0x63DEC8: ??? (in /usr/local/bin/php) ==35== by 0x21ADEB: ??? (in /usr/local/bin/php) ==35== by 0x71A82E0: (below main) (libc-start.c:291) ==35== If you believe this happened as a result of a stack ==35== overflow in your program's main thread (unlikely but ==35== possible), you can try to increase the size of the ==35== main thread stack using the --main-stacksize= flag. ==35== The main thread stack size used in this run was 8388608. ==35== ==35== HEAP SUMMARY: ==35== in use at exit: 2,801,506 bytes in 27,692 blocks ==35== total heap usage: 46,209 allocs, 18,517 frees, 17,825,935 bytes allocated ==35== ==35== LEAK SUMMARY: ==35== definitely lost: 0 bytes in 0 blocks ==35== indirectly lost: 0 bytes in 0 blocks ==35== possibly lost: 1,987,880 bytes in 19,455 blocks ==35== still reachable: 813,626 bytes in 8,237 blocks ==35== suppressed: 0 bytes in 0 blocks ==35== Rerun with --leak-check=full to see details of leaked memory ==35== ==35== For counts of detected and suppressed errors, rerun with: -v ==35== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Unfortunately after recompiling php 7.2.7 with -g and not stripping the binary the problem disappears and valgrind does not complain. |
|
This is a known php bug and the suggested workaround export USE_ZEND_ALLOC=0 seems to work. I'll update and close this issue if it no longer shows. |
We usually can't do much, when PHP see faults. So let's close this as the PHP bug you linked. |
|
@dachary Thanks for mentioning @pierreozoux ping - incase other people stumble upon this with the Docker image (nextcloud:apache) |
Steps to reproduce
Note that it is not trivial to verify php dumped core with the above. This is however the minimal reproducer and is included because it is short. The following Steps to debug are useful for forensics.
Steps to debug
Expected behaviour
php keeps running
Actual behaviour
php dumps core
#0 strlen () at ../sysdeps/x86_64/strlen.S:106 #1 0x0000559485e66b8e in _estrdup () #2 0x0000559485b4276d in ?? () #3 0x0000559485b4452c in ?? () #4 0x0000559485b220b6 in php_format_date () #5 0x0000559485f37a83 in ?? () #6 0x0000559485f3a648 in ?? () #7 0x0000559485f3af6e in ?? () #8 0x0000559485f3be39 in ?? () #9 0x0000559485b18dec in ?? () #10 0x00007fb3b15d52e1 in __libc_start_main (main=0x559485b18a10, argc=3, argv=0x7ffd5b4fa338, init=, fini=, rtld_fini=, stack_end=0x7ffd5b4fa328) at ../csu/libc-start.c:291 #11 0x0000559485b18ffa in _start ()Server configuration
Operating system:
The
nextcloud:fpmimage from https://github.com/nextcloud/dockerWeb server:
php manually run
Database:
SQLite
PHP version:
php --version PHP 7.1.18 (cli) (built: Jun 20 2018 22:17:37) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans with Zend OPcache v7.1.18, Copyright (c) 1999-2018, by Zend TechnologiesNextcloud version: (see Nextcloud admin page)
The tip of the stable13 branch
Updated from an older Nextcloud/ownCloud or fresh install:
Fresh.
Where did you install Nextcloud from:
CORE_BRANCH=stable13 ; git clone https://github.com/nextcloud/server.git --recursive --depth 1 -b $CORE_BRANCH nextcloud
Signing status:
Signing status
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: NO
Are you using encryption: NO
Are you using an external user-backend, if yes which one: NO
Client configuration
Browser:
Firefox
Operating system:
Debian stretch
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
The text was updated successfully, but these errors were encountered: