php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #74760 strduo() from signal handler causing a deadlock
Submitted: 2017-06-14 20:49 UTC Modified: 2017-06-14 21:19 UTC
From: rasmus@php.net Assigned: rasmus (profile)
Status: Closed Package: *General Issues
PHP Version: 5.6Git-2017-06-14 (snap) OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rasmus@php.net
New email:
PHP Version: OS:

 

 [2017-06-14 20:49 UTC] rasmus@php.net 
Description:
------------
We have a strdup call at in the php_error_cb() function which can cause a deadlock in malloc:

https://github.com/php/php-src/blob/master/main/main.c#L1046-L1047

On a timeout, we might be in a malloc() in some third-party lib and since malloc isn't reentrant this can deadlock. 

Example (from PHP 7.0 but the code is similar in master):

#0  0x00007f6410c246ac in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007f6410ba31c7 in _L_lock_14687 () from /lib64/libc.so.6
#2  0x00007f6410ba02c3 in malloc () from /lib64/libc.so.6
#3  0x00007f6410ba6aba in strdup () from /lib64/libc.so.6
#4  0x00007f640993ca25 in php_error_cb (type=1, error_filename=0x7f62b4fb0988 "/var/www/script.php", error_lineno=26, format=<optimized out>, 
    args=<optimized out>) at /builddir/build/BUILD/php-src-7ed028b1080c44a8de4da1d775fd8e38c6536845/main/main.c:1012
#5  0x00007f6409b6d15b in soap_error_handler (error_num=1, error_filename=0x7f62b4fb0988 "/var/www/script.php", error_lineno=26, 
    format=0x7f640a2d9560 "Maximum execution time of %pd second%s exceeded", args=0x7ffc65849ff0)
    at /builddir/build/BUILD/php-src-7ed028b1080c44a8de4da1d775fd8e38c6536845/ext/soap/soap.c:2210
#6  0x00007f640993e811 in zend_error (type=type@entry=1, format=format@entry=0x7f640a2d9560 "Maximum execution time of %pd second%s exceeded")
    at /builddir/build/BUILD/php-src-7ed028b1080c44a8de4da1d775fd8e38c6536845/Zend/zend.c:1163
#7  0x00007f6409ce0fdf in zend_timeout (dummy=<optimized out>) at /builddir/build/BUILD/php-src-7ed028b1080c44a8de4da1d775fd8e38c6536845/Zend/zend_execute_API.c:1207
#8  <signal handler called>
#9  0x00007f6410b9bb1a in malloc_consolidate () from /lib64/libc.so.6
#10 0x00007f6410b9ded5 in _int_malloc () from /lib64/libc.so.6
#11 0x00007f6410ba026c in malloc () from /lib64/libc.so.6
#12 0x00007f63f854facc in _string_check(memcached_string_st*, unsigned long) () from /lib64/libmemcached.so.11
#13 0x00007f63f85494ae in _read_one_response(memcached_instance_st*, char*, unsigned long, memcached_result_st*) () from /lib64/libmemcached.so.11
#14 0x00007f63f854973c in memcached_response(memcached_instance_st*, char*, unsigned long, memcached_result_st*) () from /lib64/libmemcached.so.11
#15 0x00007f63f85427a2 in memcached_fetch_result () from /lib64/libmemcached.so.11

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-06-14 20:56 UTC] nikic@php.net 
This is fixed in PHP 7.1 with the new VM interrupt based timeout handling mechanism. I don't think we will take any action in earlier versions -- it's not a question of just a strdup() call, what we were doing there was just inherently unsafe.
 [2017-06-14 21:19 UTC] rasmus@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: rasmus
 [2017-06-14 21:19 UTC] rasmus@php.net 
Ah, true, I forgot we moved that to vm interrupts in 7.1.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jul 02 10:01:38 2025 UTC