php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52389 Memory (de)allocation problem for pgsql notices
Submitted: 2010-07-21 15:50 UTC Modified: 2013-10-15 11:54 UTC
Votes:6
Avg. Score:4.5 ± 0.8
Reproduced:6 of 6 (100.0%)
Same Version:3 (50.0%)
Same OS:0 (0.0%)
From: miroslav dot zacek at skype dot net Assigned:
Status: No Feedback Package: PostgreSQL related
PHP Version: 5.3.2 OS: Linux (Kubuntu)
Private report: No CVE-ID: None
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
18 - 10 = ?
Subscribe to this entry?

 
 [2010-07-21 15:50 UTC] miroslav dot zacek at skype dot net
Description:
------------
In the ext/pgsql.c pgsql_globals->notices structure is allocated as persistent but individual messages non persistent. Thus the destructor _php_pgsql_notice_ptr_dtor happens to try to free memory that was already freed by the garbage collector and the thread exits with segmentation fault.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3cd3013 in _zend_mm_free_int (heap=0x7ffff844b5c0, p=0x7ffff9397390) at /usr/src/php_no_suhosin/php5-5.3.2/Zend/zend_alloc.c:2018
2018            if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) backtrace
#0  0x00007ffff3cd3013 in _zend_mm_free_int (heap=0x7ffff844b5c0, p=0x7ffff9397390) at /usr/src/php_no_suhosin/php5-5.3.2/Zend/zend_alloc.c:2018
#1  0x00007ffff3cd3de1 in _efree (ptr=0x7ffff9397390) at /usr/src/php_no_suhosin/php5-5.3.2/Zend/zend_alloc.c:2351
#2  0x00007fffeb4d3419 in _php_pgsql_notice_ptr_dtor (ptr=0x7ffff9396708) at /tmp/pgsql/pgsql.c:841



Patches

pgsql-fixed.diff (last revision 2010-10-18 10:53 UTC by jaromir dot dolecek at skype dot net)
pgsql.patch (last revision 2010-07-21 13:51 UTC by miroslav dot zacek at skype dot net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-07-22 05:08 UTC] aharvey@php.net
The original description without the double encoding:

In the ext/pgsql.c pgsql_globals->notices structure is allocated as
persistent but individual messages non persistent. Thus the destructor
_php_pgsql_notice_ptr_dtor happens to try to free memory that was
already freed by the garbage collector and the thread exits with
segmentation fault.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3cd3013 in _zend_mm_free_int (heap=0x7ffff844b5c0, p=0x7ffff9397390) 
at /usr/src/php_no_suhosin/php5-5.3.2/Zend/zend_alloc.c:2018
2018            if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) backtrace
#0  0x00007ffff3cd3013 in _zend_mm_free_int (heap=0x7ffff844b5c0, 
p=0x7ffff9397390) at /usr/src/php_no_suhosin/php5-5.3.2/Zend/zend_alloc.c:2018
#1  0x00007ffff3cd3de1 in _efree (ptr=0x7ffff9397390) at 
/usr/src/php_no_suhosin/php5-5.3.2/Zend/zend_alloc.c:2351
#2  0x00007fffeb4d3419 in _php_pgsql_notice_ptr_dtor (ptr=0x7ffff9396708) at 
/tmp/pgsql/pgsql.c:841
 [2010-08-02 00:12 UTC] felipe@php.net
-Status: Open +Status: Feedback
 [2010-08-02 00:12 UTC] felipe@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2010-08-02 10:10 UTC] miroslav dot zacek at skype dot net
-Status: Feedback +Status: Open
 [2010-08-02 10:10 UTC] miroslav dot zacek at skype dot net
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/apache2...done.
(gdb) handle SIG33 pass nostop noprint
Signal        Stop	Print	Pass to program	Description
SIG33         No	No	Yes		Real-time event 33
(gdb) set pagination 0
(gdb) run
Starting program: /usr/sbin/apache2 -k start -X
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe9619710 (LWP 1339)]
[Thread 0x7fffe9619710 (LWP 1339) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3d98343 in _zend_mm_free_canary_int (heap=0x7ffff83fdca0, p=0x37000000d1) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090
2090	        SUHOSIN_MM_CHECK_CANARIES(mm_block, "efree()");
(gdb) backtrace full
#0  0x00007ffff3d98343 in _zend_mm_free_canary_int (heap=0x7ffff83fdca0, p=0x37000000d1) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090
        p = 0x7ffff3d79bc0 "H\203\354\bH\213GHH\205\300t\017\213\267\230"
        mm_block = 0x7ffff91a00d0
        next_block = 0x7ffff3d79bc0
        size = 4165624496
#1  0x00007fffebee2761 in _php_pgsql_notice_ptr_dtor (ptr=0x7ffff83fdca0) at /build/buildd/php5-5.3.2/ext/pgsql/pgsql.c:835
        notice = 0x7ffff87ad648
#2  0x00007ffff3d84b98 in zend_hash_clean (ht=0x7fffec0f9168) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:753
        p = 0x7ffff9298b50
#3  0x00007fffebee9410 in zm_deactivate_pgsql (type=-130032480, module_number=209) at /build/buildd/php5-5.3.2/ext/pgsql/pgsql.c:1034
No locals.
#4  0x00007ffff3d79bdc in module_registry_cleanup (module=0x7ffff83fdca0) at /build/buildd/php5-5.3.2/Zend/zend_API.c:2150
No locals.
#5  0x00007ffff3d84734 in zend_hash_reverse_apply (ht=0x7ffff44701c0, apply_func=0x7ffff3d79bc0 <module_registry_cleanup>) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:957
        result = 0
        p = 0x7ffff84a62b0
#6  0x00007ffff3d7864d in zend_deactivate_modules () at /build/buildd/php5-5.3.2/Zend/zend.c:938
        __orig_bailout = 0x0
        __bailout = {{__jmpbuf = {0, 0, 4098291904, 32767, 3240731330, 2033281132, 4167622472, 32767}, __mask_was_saved = 793223874, __saved_mask = {__val = {0, 32767, 0, 0, 1, 4294967295, 4162878232, 32767, 0, 0, 0, 0, 4179820304, 32767, 4294958864, 1836}}}}
        __orig_bailout = 0x0
        __bailout = {{__jmpbuf = {0, 0, 4098291904, 32767, 3240731330, 2033281132, 4167622472, 32767}, __mask_was_saved = 793223874, __saved_mask = {__val = {0, 32767, 0, 0, 1, 4294967295, 4162878232, 32767, 0, 0, 0, 0, 4179820304, 32767, 4294958864, 1836}}}}
#7  0x00007ffff3d24565 in php_request_shutdown (dummy=0x7ffff83fdca0) at /build/buildd/php5-5.3.2/main/main.c:1623
        report_memleaks = 0 '\000'
#8  0x00007ffff3e04dc7 in php_handler (r=0x7ffff3e04dc7) at /build/buildd/php5-5.3.2/sapi/apache2handler/sapi_apache2.c:512
        ctx = 0x7ffff91b5b08
        conf = 0x7ffff868df48
        brigade = 0x0
        bucket = 0x679b8d7abd51d2
        rv = 2059227602
        parent_req = 0x1
#9  0x00007ffff7fd6140 in ap_run_handler (r=0x7ffff868df48) at /build/buildd/apache2-2.2.14/server/config.c:159
        n = 3
        rv = 2059227602
#10 0x00007ffff7fd9aa8 in ap_invoke_handler (r=0x7ffff868df48) at /build/buildd/apache2-2.2.14/server/config.c:373
        handler = 0x0
        result = 0
        old_handler = 0x7ffff83747d0 "application/x-httpd-php"
        ignore = <value optimized out>
#11 0x00007ffff7fe749c in ap_internal_redirect (new_uri=<value optimized out>, r=<value optimized out>) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:501
        new = 0x7ffff868df48
        access_status = 2059227602
#12 0x00007ffff7fe7517 in ap_process_request (r=0x7ffff86937c8) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:296
        access_status = 2059227602
#13 0x00007ffff7fe4528 in ap_process_http_connection (c=0x7ffff8683648) at /build/buildd/apache2-2.2.14/modules/http/http_core.c:190
        r = 0x7ffff86937c8
        csd = 0x7ffff8683458
#14 0x00007ffff7fddcf8 in ap_run_process_connection (c=0x7ffff8683648) at /build/buildd/apache2-2.2.14/server/connection.c:43
        n = 1
        rv = 2059227602
#15 0x00007ffff7fec037 in child_main (child_num_arg=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:662
        current_conn = <value optimized out>
        csd = 0x7ffff8683458
        ptrans = 0x7ffff86833d8
        allocator = 0x7ffff86812d0
        status = <value optimized out>
        i = <value optimized out>
        lr = <value optimized out>
        pollset = 0x7ffff8681470
        sbh = 0x7ffff8681468
        bucket_alloc = 0x7ffff86856d8
        last_poll_idx = 0
#16 0x00007ffff7fec306 in make_child (s=0x7ffff8214938, slot=0) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:702
No locals.
#17 0x00007ffff7fec953 in ap_mpm_run (_pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:978
        index = <value optimized out>
        remaining_children_to_start = <value optimized out>
        rv = <value optimized out>
#18 0x00007ffff7fc2350 in main (argc=4, argv=0x7fffffffe728) at /build/buildd/apache2-2.2.14/server/main.c:742
        c = 88 'X'
        configtestonly = <value optimized out>
        confname = 0x7ffff7fee92b "/etc/apache2/apache2.conf"
        def_server_root = 0x7ffff7ff252b ""
        temp_error_log = 0x0
        error = <value optimized out>
        process = 0x7ffff820c220
        server_conf = 0x7ffff8214938
        pglobal = 0x7ffff820c128
        pconf = 0x7ffff820e138
        plog = 0x7ffff82422d8
        ptemp = 0x7ffff8216178
        pcommands = 0x7ffff8210148
        opt = 0x7ffff8210240
        rv = <value optimized out>
        mod = <value optimized out>
        optarg = 0x0
(gdb) info registers
rax            0x679b8d7abd51d2	29162954553119186
rbx            0x7ffff83fdca0	140737358322848
rcx            0x7ffff7f8b000	140737353658368
rdx            0xb495beeed0237dbf	-5434227442449154625
rsi            0x37000000d1	236223201489
rdi            0x7ffff83fdca0	140737358322848
rbp            0x37000000d1	0x37000000d1
rsp            0x7fffffffdd40	0x7fffffffdd40
r8             0x7ffff83feba0	140737358326688
r9             0x0	0
r10            0x0	0
r11            0x728	1832
r12            0x7ffff91a00d0	140737372618960
r13            0x7ffff3d79bc0	140737284381632
r14            0x7ffff84a62b0	140737359012528
r15            0x7ffff8207b18	140737356266264
rip            0x7ffff3d98343	0x7ffff3d98343 <_zend_mm_free_canary_int+51>
eflags         0x10206	[ PF IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) x/16i $pc
=> 0x7ffff3d98343 <_zend_mm_free_canary_int+51>:	cmp    %rax,-0x28(%rsi)
   0x7ffff3d98347 <_zend_mm_free_canary_int+55>:	lea    -0x28(%rsi),%r12
   0x7ffff3d9834b <_zend_mm_free_canary_int+59>:	mov    -0x20(%rsi),%r14
   0x7ffff3d9834f <_zend_mm_free_canary_int+63>:	mov    -0x10(%rsi),%r13
   0x7ffff3d98353 <_zend_mm_free_canary_int+67>:	je     0x7ffff3d98460 <_zend_mm_free_canary_int+336>
   0x7ffff3d98359 <_zend_mm_free_canary_int+73>:	mov    0x6b25f8(%rip),%rcx        # 0x7ffff444a958
   0x7ffff3d98360 <_zend_mm_free_canary_int+80>:	xor    %eax,%eax
   0x7ffff3d98362 <_zend_mm_free_canary_int+82>:	mov    %r12,%rdx
   0x7ffff3d98365 <_zend_mm_free_canary_int+85>:	lea    0x402bf4(%rip),%rsi        # 0x7ffff419af60
   0x7ffff3d9836c <_zend_mm_free_canary_int+92>:	mov    $0x1,%edi
   0x7ffff3d98371 <_zend_mm_free_canary_int+97>:	callq  *(%rcx)
   0x7ffff3d98373 <_zend_mm_free_canary_int+99>:	mov    $0x2,%edi
   0x7ffff3d98378 <_zend_mm_free_canary_int+104>:	callq  0x7ffff3d39650 <suhosin_get_config>
   0x7ffff3d9837d <_zend_mm_free_canary_int+109>:	test   %al,%al
   0x7ffff3d9837f <_zend_mm_free_canary_int+111>:	je     0x7ffff3d98506 <_zend_mm_free_canary_int+502>
   0x7ffff3d98385 <_zend_mm_free_canary_int+117>:	mov    0x8a8(%rbx),%rax
(gdb) thread apply all backtrace

Thread 1 (Thread 0x7ffff7f61740 (LWP 1335)):
#0  0x00007ffff3d98343 in _zend_mm_free_canary_int (heap=0x7ffff83fdca0, p=0x37000000d1) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090
#1  0x00007fffebee2761 in _php_pgsql_notice_ptr_dtor (ptr=0x7ffff83fdca0) at /build/buildd/php5-5.3.2/ext/pgsql/pgsql.c:835
#2  0x00007ffff3d84b98 in zend_hash_clean (ht=0x7fffec0f9168) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:753
#3  0x00007fffebee9410 in zm_deactivate_pgsql (type=-130032480, module_number=209) at /build/buildd/php5-5.3.2/ext/pgsql/pgsql.c:1034
#4  0x00007ffff3d79bdc in module_registry_cleanup (module=0x7ffff83fdca0) at /build/buildd/php5-5.3.2/Zend/zend_API.c:2150
#5  0x00007ffff3d84734 in zend_hash_reverse_apply (ht=0x7ffff44701c0, apply_func=0x7ffff3d79bc0 <module_registry_cleanup>) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:957
#6  0x00007ffff3d7864d in zend_deactivate_modules () at /build/buildd/php5-5.3.2/Zend/zend.c:938
#7  0x00007ffff3d24565 in php_request_shutdown (dummy=0x7ffff83fdca0) at /build/buildd/php5-5.3.2/main/main.c:1623
#8  0x00007ffff3e04dc7 in php_handler (r=0x7ffff3e04dc7) at /build/buildd/php5-5.3.2/sapi/apache2handler/sapi_apache2.c:512
#9  0x00007ffff7fd6140 in ap_run_handler (r=0x7ffff868df48) at /build/buildd/apache2-2.2.14/server/config.c:159
#10 0x00007ffff7fd9aa8 in ap_invoke_handler (r=0x7ffff868df48) at /build/buildd/apache2-2.2.14/server/config.c:373
#11 0x00007ffff7fe749c in ap_internal_redirect (new_uri=<value optimized out>, r=<value optimized out>) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:501
#12 0x00007ffff7fe7517 in ap_process_request (r=0x7ffff86937c8) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:296
#13 0x00007ffff7fe4528 in ap_process_http_connection (c=0x7ffff8683648) at /build/buildd/apache2-2.2.14/modules/http/http_core.c:190
#14 0x00007ffff7fddcf8 in ap_run_process_connection (c=0x7ffff8683648) at /build/buildd/apache2-2.2.14/server/connection.c:43
#15 0x00007ffff7fec037 in child_main (child_num_arg=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:662
#16 0x00007ffff7fec306 in make_child (s=0x7ffff8214938, slot=0) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:702
#17 0x00007ffff7fec953 in ap_mpm_run (_pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:978
#18 0x00007ffff7fc2350 in main (argc=4, argv=0x7fffffffe728) at /build/buildd/apache2-2.2.14/server/main.c:742
(gdb) l
2085		}
2086	
2087		mm_block = ZEND_MM_HEADER_OF(p);
2088		size = ZEND_MM_BLOCK_SIZE(mm_block);
2089	#if SUHOSIN_PATCH
2090	        SUHOSIN_MM_CHECK_CANARIES(mm_block, "efree()");
2091	#endif    
2092		ZEND_MM_CHECK_PROTECTION(mm_block);
2093	
2094	#if ZEND_DEBUG || ZEND_MM_HEAP_PROTECTION
 [2010-08-03 00:04 UTC] ethan at remindercall dot com
I've applied this patch to the 5.3.2 sources and it causes new problems - 
PHPPgAdmin doesn't even function with the patch applied.
 [2010-08-13 14:43 UTC] clint at ubuntu dot com
I've not seen the segfault that Miroslav is reporting.

However, I applied the patch to the latest version of php in Ubuntu (5.3.3-
ubuntu4) and there was no problem running phppgadmin as ethan suggests.

I would guess Ethan's problem is more likely this one:

https://sourceforge.net/tracker/?
func=detail&aid=2954087&group_id=37132&atid=418980

Which basically says that phppgadmin won't support php 5.3 in their stable tree.
 [2010-08-14 01:13 UTC] felipe@php.net
-Status: Open +Status: Feedback
 [2010-08-14 01:13 UTC] felipe@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Have you tried it without Suhosin?
 [2010-08-26 11:35 UTC] miroslav dot zacek at skype dot net
I tried to create a simple test that crashes but it is not so easy. More complex page with several requests and session in DB crashes (not always, several reloads are needed usually). I'll try to create it but I'm quite busy now so it won't be that fast. Sorry.
 [2010-10-18 12:56 UTC] 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.
 [2010-10-18 13:18 UTC] 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 13:19 UTC] 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:42 UTC] miroslav dot zacek at skype dot net
-Status: Feedback +Status: Open
 [2010-10-18 13:42 UTC] miroslav dot zacek at skype dot net
Thanks Jaromir :-)
 [2010-10-25 23:16 UTC] felipe@php.net
I can't reproduce it on 8.3.12.
 [2010-10-25 23:37 UTC] php at maxnet dot eu
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
==
 [2010-10-25 23:51 UTC] php at maxnet dot eu
Oops, didn't notice the patch was for 5.3
Applied it to 5.2.14
 [2010-11-20 01:58 UTC] felipe@php.net
-Status: Open +Status: Feedback
 [2010-11-20 01:58 UTC] felipe@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2011-07-12 14:00 UTC] me at dzonder dot net
This bug still exists on PHP 5.3.6 (FreeBSD 8.2 official port).

My workaround is to explicitly call session_write_close() in scripts where sessions with pgsql are used.
 [2011-11-09 21:49 UTC] ecrist at claimlynx dot com
This bug is seen on FreeBSD 8.2-STABLE as of Nov 4, 2011 with PHP 5.3.8 on Apache 
2.2.21 and Postgres 8.4.9.
 [2011-11-10 19:06 UTC] ecrist at claimlynx dot com
Tried the patch attached to this report against 5.3.8 and we get more segfaults 
than before.  Additionally, we've added a call session_write_close() to every 
page and that also doesn't solve the problem for us.  I can provide backtraces or 
anything else needed to aid a solution to this bug.
 [2011-11-18 20:12 UTC] felipe@php.net
-Status: Feedback +Status: Open
 [2011-11-18 20:30 UTC] ecrist at claimlynx dot com
The backtrace for this we were able to come up with was as follows:


#0  0x000000080571f741 in _zend_mm_free_canary_int () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#1  0x0000000808b9bc81 in _php_pgsql_notice_ptr_dtor () from 
/usr/local/lib/php/20090626/pgsql.so
No symbol table info available.
#2  0x000000080570da48 in zend_hash_clean () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#3  0x0000000808ba2474 in zm_deactivate_pgsql () from 
/usr/local/lib/php/20090626/pgsql.so
No symbol table info available.
#4  0x00000008057029ac in module_registry_cleanup () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#5  0x000000080570d544 in zend_hash_reverse_apply () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#6  0x00000008057009dc in zend_deactivate_modules () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#7  0x00000008056acbe5 in php_request_shutdown () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#8  0x000000080578c245 in php_handler () from 
/usr/local/libexec/apache22/libphp5.so
No symbol table info available.
#9  0x00000000004361fa in ap_run_handler (r=0x809ffa0a0) at config.c:157
	n = 2
	rv = Variable "rv" is not available.
(gdb)
 [2011-11-18 20:34 UTC] felipe@php.net
Try disabling suhosin.
 [2013-06-26 22:19 UTC] yohgaki@php.net
-Status: Open +Status: Feedback
 [2013-06-26 22:19 UTC] yohgaki@php.net
Please try using this snapshot:

  http://snaps.php.net/php-trunk-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Could you try current master and report?
 [2013-10-15 11:54 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 23:01:28 2024 UTC