Edit report at http://bugs.php.net/bug.php?id=52389&edit=1
ID: 52389
Comment by: php at maxnet dot eu
Reported by: miroslav dot zacek at skype dot net
Summary: Memory (de)allocation problem for pgsql notices
Status: Open
Type: Bug
Package: PostgreSQL related
Operating System: Linux (Kubuntu)
PHP Version: 5.3.2
Block user comment: N
New Comment:
The pgsql-fixed.diff patch results in a lot more core dumps for me than
the
original problem under FreeBSD.
Seems to happen on any notice.
==
Oct 25 23:23:02 www3 kernel: pid 76489 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:03 www3 kernel: pid 76502 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:13 www3 kernel: pid 76483 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:15 www3 kernel: pid 76503 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:22 www3 kernel: pid 76485 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:22 www3 kernel: pid 76487 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:38 www3 kernel: pid 76506 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:45 www3 kernel: pid 76511 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:46 www3 kernel: pid 76515 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:51 www3 kernel: pid 76508 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:23:52 www3 kernel: pid 76513 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:24:04 www3 kernel: pid 76521 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:24:07 www3 kernel: pid 76525 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:24:09 www3 kernel: pid 76522 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:24:10 www3 kernel: pid 76526 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:24:16 www3 kernel: pid 76520 (php), uid 80: exited on signal 6
(core
dumped)
Oct 25 23:24:23 www3 kernel: pid 76527 (php), uid 80: exited on signal 6
(core
dumped)
==
==
www3# gdb /usr/local/bin/php php.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `php'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /usr/local/pgsql/lib/libpq.so.5...done.
Loaded symbols for /usr/local/pgsql/lib/libpq.so.5
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.2...done.
Loaded symbols for /lib/libpthread.so.2
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x00000008012990bc in kill () from /lib/libc.so.6
[New LWP 100277]
(gdb) bt
#0 0x00000008012990bc in kill () from /lib/libc.so.6
#1 0x0000000801297f4d in abort () from /lib/libc.so.6
#2 0x0000000801231025 in _UTF8_init () from /lib/libc.so.6
#3 0x000000080123105c in _UTF8_init () from /lib/libc.so.6
#4 0x0000000801231ffd in _UTF8_init () from /lib/libc.so.6
#5 0x00000000004a6431 in _php_pgsql_notice_ptr_dtor (ptr=0x12ada) at
/usr/home/max/tmp/php-5.2.14/ext/pgsql/pgsql.c:397
#6 0x00000000005b13e2 in _zend_hash_index_update_or_next_insert
(ht=0x85b928,
h=4, pData=0x7fffffff7d78, nDataSize=8, pDest=0x0, flag=76482)
at /usr/home/max/tmp/php-5.2.14/Zend/zend_hash.c:374
#7 0x00000000004a63be in _php_pgsql_notice_handler (resource_id=0x4,
message=0xa15e00 "WARNING: nonstandard use of \\\\ in a string
literal\nLINE 1: ...id AND n.id=p.groupid ORDER BY similarity(r.name,
'SECRET_WE...\n", ' ' <repeats 61 times>, "^\nHINT: Use"...) at
/usr/home/max/tmp/php-5.2.14/ext/pgsql/pgsql.c:384
#8 0x0000000800b6d09a in pqGetErrorNotice3 () from
/usr/local/pgsql/lib/libpq.so.5
#9 0x0000000800b6d66a in pqParseInput3 () from
/usr/local/pgsql/lib/libpq.so.5
#10 0x0000000800b65d0f in PQgetResult () from
/usr/local/pgsql/lib/libpq.so.5
#11 0x0000000800b65ece in PQgetResult () from
/usr/local/pgsql/lib/libpq.so.5
#12 0x00000000004a806a in zif_pg_query (ht=76506, return_value=0x8978f0,
return_value_ptr=0x12ac2, this_ptr=0x8012990dc,
return_value_used=-2138572576)
at /usr/home/max/tmp/php-5.2.14/ext/pgsql/pgsql.c:1178
#13 0x00000000005c5e3c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffffff81b0) at zend_vm_execute.h:200
#14 0x00000000005c577f in execute (op_array=0xa19c00) at
zend_vm_execute.h:92
#15 0x00000000005c5a3c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffffff9f50) at zend_vm_execute.h:234
#16 0x00000000005c577f in execute (op_array=0xa59360) at
zend_vm_execute.h:92
#17 0x00000000005c5a3c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffffffb190) at zend_vm_execute.h:234
#18 0x00000000005c577f in execute (op_array=0x8858f8) at
zend_vm_execute.h:92
#19 0x00000000005a7778 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/home/max/tmp/php-5.2.14/Zend/zend.c:1134
#20 0x00000000005669e6 in php_execute_script
(primary_file=0x7fffffffed00) at
/usr/home/max/tmp/php-5.2.14/main/main.c:2036
#21 0x00000000006352e7 in main (argc=1, argv=0x7fffffffedc8) at
/usr/home/max/tmp/php-5.2.14/sapi/cgi/cgi_main.c:1999
==
Previous Comments:
------------------------------------------------------------------------
[2010-10-25 23:16:48] fel...@php.net
I can't reproduce it on 8.3.12.
------------------------------------------------------------------------
[2010-10-18 13:42:22] miroslav dot zacek at skype dot net
Thanks Jaromir :-)
------------------------------------------------------------------------
[2010-10-18 13:19:45] jaromir dot dolecek at skype dot net
Trigger script (must replace DBNAME and USER with proper info):
<?php
$c = pg_connect("host=localhost port=6001 dbname=DBNAME user=USER");
function nop() { }
function trigger_notice() {
global $c;
$rv2 = pg_query($c, 'SELECT * FROM foo()');
}
$rv = pg_query($c, 'CREATE OR REPLACE FUNCTION foo() RETURNS integer AS
$$
BEGIN
RAISE NOTICE \'foo\';
RETURN 3;
END
$$ LANGUAGE \'plpgsql\' VOLATILE');
session_set_save_handler('nop', 'nop', 'nop', 'trigger_notice', 'nop',
'nop');
session_start();
------------------------------------------------------------------------
[2010-10-18 13:18:33] jaromir dot dolecek at skype dot net
This problem happens due to interaction with user session save handler
and pgsql extension. Repeat script is included as next comment.
So after further analysis, this is what happens:
1. request ends, PHP runs RSHUTDOWN method of individual modules in
reverse
order than loaded - i.e. pgsql (dynamically loaded) before session
(which is
builtin)
2. pgsql RSHUTDOWN is called, PGG(notices) is cleared
3. session RSHUTDOWN is called, which runs user session save method,
invoking
pgsql code
4. if sql query generates notice, message is added to PGG(notices) using
non-persistent memory
5. new notice stays in PGG(notice) after RSHUTDOWN process is finished,
the non-persistent memory is cleared automatically by PHP, leaving
PGG(notices) with
dangling pointer
On next request, this is what happens:
1. when pgsql RSHUTDOWN is called, code tries to remove the stale entry
2. the pointer is no longer valid, so random memory is overwritten
(either double free if the memory happens to point to newly allocated
valid value, or just
random memory)
Problem happens only when using PHP as Apache module or FastCGI - it
needs the same process to process at least two separate requests. That's
also reason why the
crash never happens for first request.
Proper fix is for session code to not abuse RSHUTDOWN for running
session store. Similar problem might happen for other modules with local
deinicialization in
RSHUTDOWN method.
I know it's documented that session_write_close() should be called
explicitly, but PHP interpreter should not allow this to happen -
session code should not
invoke user code in RSHUTDOWN. To make explicit and force people fix
code, it should issue some PHP warning if session is still active in
RSHUTDOWN.
Bandaid fix for pgsql is included in pgsql-fixed.diff.
Note it generates some memory leaks warnings with DEBUG, but that is not
possible to avoid when session runs after pgsql cleanup.
------------------------------------------------------------------------
[2010-10-18 12:56:41] jaromir dot dolecek at skype dot net
I've uploaded revised patch - the previous version has crash problem
with
pg_last_error(), because _php_pgsql_trim_message() was also used in
context, where
non-persistent return value was expected
I'll post the repeat PHP skript and some analysis shortly.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52389
--
Edit this bug report at http://bugs.php.net/bug.php?id=52389&edit=1
