Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69123
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Date: Fri, 13 Sep 2013 22:10:56 +0200
Message-ID: <CAAPSnn21kq2_-4RGoMKW_8eWDNNv_0Aon30SRsp3U_v+2098AA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: free deadlock in timeout signal handler
From: lazy404@gmail.com (Lazy)

Hello internals,

I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
internal libc lock.

Backtrace follows

#0  0x0000030b555024cb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000030b554986b8 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000030b55496aa1 in free () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x0000000000734989 in php_error_cb (type=1,
error_filename=0x100013bbf18 "xxx", error_lineno=7, format=<optimized
out>,
   args=<optimized out>) at main/main.c:837
#4  0x0000000000623e15 in soap_error_handler (error_num=1,
error_filename=0x100013bbf18 "/class.cbase.php", error_lineno=7,
   format=0xa749c0 "Maximum execution time of %d second%s exceeded",
args=0x3a2de4d3fa0) at //ext/soap/soap.c:2115
#5  0x0000000000777066 in zend_error (type=1, format=0xa749c0 "Maximum
execution time of %d second%s exceeded") at /Zend/zend.c:976
#6  <signal handler called>
#7  0x0000030b55493302 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000030b55496aac in free () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x0000030b57f817c5 in free_root () from
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
#10 0x0000030b57f65a34 in free_rows () from
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
#11 0x0000030b57f6620d in mysql_free_result () from
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
#12 0x000000000058cd1c in _free_mysql_result (rsrc=<optimized out>) at
ext/mysql/php_mysql.c:275
#13 0x000000000078340e in list_entry_destructor (ptr=0x5074760) at
Zend/zend_list.c:184

From my understanding free is not safe to use in a signal handler, and
this seems to be the issue here.

http://marc.info/?l=php-internals&m=121999390109071&w=2 seems to
address this issue but it's not present in 5.3 or later releases.

Very similar deadlock but with time() instead of free(),
https://bugs.php.net/bug.php?id=31749

Current php also uses free() in php_error_cb() and external
destructors in list_entry_destructor() aren't protected by
HANDLE_BLOCK_INTERRUPTIONS() (which seems to be a noop in fastcgi
mode), so I suspect 5.5 may also contain this deadlock.

main/main.c
php_error_cb()
    835     if (display) {
    836         if (PG(last_error_message)) {
    837             free(PG(last_error_message));
...                    ^^^^^^ deadlock if previous free was
interrupted by a timeout signal
    845         PG(last_error_type) = type;
    846         PG(last_error_message) = strdup(buffer);

I'm thinking about "fixing" this by leaking memory pointed by
PG(last_error_message) if php called when a timeout is pending
(timeouts are usually very rare, php processes will eventually be
restarted so this little memory waste won't have time to make any
impact.

Is this issue fixed in modern php ? If so I would be grateful for some
information about the way it was done. This would save me a lot of
time trying to trigger
a non existing confition.

I will try to reproduce this in a modern version of php.

Thanks,

Michal Grzedzicki