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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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: Thu Jul 03 10:01:33 2025 UTC