#46025 [Sus]: zend_bailout can deadlock APC
ID: 46025 Updated by: sh...@php.net Reported By: askalski at gmail dot com Status: Suspended Bug Type: Reproducible crash Operating System: redhat PHP Version: 5.2.6 New Comment: Lucas Nealan and I are working on fixing some items in the signals patch, and would like to push forward on this getting integrated in core. Would you be willing to try the patch for PHP to see if it corrects your problem? It would be of great use to know that it fixes your specific issue. If so let me know which specific version of PHP you want a patch against and I'll make sure we get you the latest one that cleanly patches against it. Previous Comments: [2009-02-27 20:09:27] pierre at archlinux dot de This problem is still reproducable with version 5.2.9. The cgi version is affected, too (as expected). [2009-02-15 00:01:20] dan at archlinux dot org Any progress here? This is definitely reproducible and we have seen it on archlinux.org about once every 3 or 4 days- it kind of stinks. Is there any current workaround besides increasing the timeout value and hoping for the best? Running: Apache 2.2.11 PHP 5.2.8 APC 3.0.19 [2008-09-09 00:46:09] scott...@php.net This is essentially what http://wiki.php.net/rfc/zendsignals is for, it was considered for PHP 5.3 but has been deferred for the moment. [2008-09-08 23:56:04] askalski at gmail dot com Reproduced with latest checkouts from both the PHP_5_2 and PHP_5_3 tags. X-Powered-By: PHP/5.2.7-dev X-Powered-By: PHP/5.3.0alpha3-dev [2008-09-08 21:16:43] j...@php.net Can you reproduce this with latest CVS checkout of PHP_5_2 (and preferrably PHP_5_3) ?? 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/46025 -- Edit this bug report at http://bugs.php.net/?id=46025edit=1
#47859 [Ver-Csd]: parse_ini_file() does not like asterisk (*) in key in the beginning
ID: 47859
Updated by: sh...@php.net
Reported By: ce at beer dot com
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3CVS, 6CVS (2009-04-01)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-04-01 10:19:59] ce at beer dot com
Description:
parse_ini_file no longer likes * (asterisk) in the beginning of the
configuration keys.
Works just fine in PHP 5.2.5
it is a copy of http://bugs.php.net/bug.php?id=46347
but still the first part of the key cannot be *
Reproduce code:
---
Ini file with the following content:
[section]
*.part1.part2 = 1
PHP file:
?php
parse_ini_file('test.ini');
Expected result:
ini file being parsed without any error messages
Actual result:
--
Warning: syntax error, unexpected '*' in test.ini on line 2
in test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=47859edit=1
#47596 [Ver]: Bus error on parsing file
ID: 47596 Updated by: sh...@php.net Reported By: pahan at hubbitus dot info Status: Verified Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.3.0beta1 Assigned To: scottmac New Comment: This is being caused because of mis-use of mmap(). We are currently relying on mmap to pad the end of our mmap'd file with zeros for detection of EOF in the scanner and scanning ahead. We specifically add ZEND_MMAP_AHEAD to the len passed to mmap in zend_stream_fixup(): /* *buf[size] is zeroed automatically by the kernel */ *buf = mmap(0, size + ZEND_MMAP_AHEAD, PROT_READ, MAP_PRIVATE, fileno(file_handle-handle.fp), 0); But AFAIK mmap does not support this usage of the len parameter, as it's a limit rather than able to extend the mmap region. This appears to work under most cases as mmap will pad zeroes up to PAGESIZE. This error will occur anytime we use mmap in this way on a file that is not ZEND_MMAP_AHEAD bytes less than PAGESIZE and therefore attempt to access a byte over PAGESIZE. It will be easy to fix the mmap calls, however this will break the re2c scanner. Originally for the EOF checks I was going to re-implement YYFILL to malloc additional space for the scanner after EOF, this may be an option to correct this. Previous Comments: [2009-03-10 18:23:04] scott...@php.net Looks like something in the re2c stuff that's causing it to overread. [2009-03-10 18:13:53] pahan at hubbitus dot info No, as I also mentioned abowe, this is not require any externul stuff (include_path=: even . dir not contain!, so, can't be include files). [2009-03-10 16:59:28] j...@php.net That script requires some external crap that is NOT included. At least provide ALL the files necessary to run the script. Otherwise the next status this report gets is Bogus. [2009-03-10 11:12:19] pahan at hubbitus dot info This script completely self-contained reproducing script. But as I mention before, I can't make it smaller because it break reproducibility. [2009-03-08 09:37:43] pahan at hubbitus dot info Description: On particular file php always crashes with Bus Error. I'm try split file to get only sensible data, but I can't. ANY changes in it do predictable behavior and all works as expected. Even add/delete comment, any letter, space in any place... $ php test.bus.error.php Bus error Its contain many external dependencies, but it is absolutely unneeded for reproducibility: $ php -dinclude_path=: test.bus.error.php Bus error [pa...@x-www _SHARED_]$ ulimit -c unlimited [pa...@x-www _SHARED_]$ php -dinclude_path=/ test.bus.error.php Bus error (core dumped) This file is my working mess for test and sandboxing :), so, it is really not intended for any use outside and even any use except probes and examples. But as I can't even change 1 letter in it, I place it as is: http://ru.bir.ru/_temp/php-bugs/2/test.bus.error.php.gz Coredump file also available for download: http://ru.bir.ru/_temp/php- bugs/2/core.19581 Reproduce code: --- http://ru.bir.ru/_temp/php-bugs/2/test.bus.error.php.gz Sorry, I can't do that smaller. -- Edit this bug report at http://bugs.php.net/?id=47596edit=1
#46817 [Ver-Csd]: tokenizer misses last single-line comment (PHP 5.3+, with re2c lexer)
ID: 46817
Updated by: sh...@php.net
Reported By: master dot jexus at gmail dot com
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0alpha3
Assigned To: shire
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-03-06 07:41:45] lu...@php.net
I'm seeing what could be related if not the same problem trying to
detect trailing windows CR+LF in T_WHITESPACE:
Reproduce code:
---
?php
// this comment and trailing blank contain windows CR+LF^M
^M
Expected result:
array(3) {
[0]=
array(3) {
[0]=
int(367)
[1]=
string(6) ?php
[2]=
int(1)
}
[1]=
array(3) {
[0]=
int(365)
[1]=
string(57) // this comment and trailing blank contain windows
CR+LF
[2]=
int(2)
}
[2]=
array(3) {
[0]=
int(370)
[1]=
string(3)
int(2)
}
}
[2]=
int(2)
}
}
Actual result:
--
array(2) {
[0]=
array(3) {
[0]=
int(368)
[1]=
string(6) ?php
[2]=
int(1)
}
[1]=
array(3) {
[0]=
int(366)
[1]=
string(57) // this comment and trailing blank contain windows
CR+LF
[2]=
int(2)
}
}
[2008-12-10 10:25:25] nlop...@php.net
this is a problem in the new lexer. The problem is reproduceable if
after the comment there's the EOF (with no \n after the comment).
This, again, is triggered because of the difference in handling the EOF
between flex and re2c..
A simple hack would be to detect the ST_ONE_LINE_COMMENT state on EOF
and return the correct value, but I would prefer a more general thing.
[2008-12-09 22:35:46] master dot jexus at gmail dot com
Description:
When using the tokenizer to lex given text, the output seems to miss
the last token, if it was a single line comment.
It only seems to occur if there isn't a newline behind the comment
lexeme.
Note the last entries in the arrays.
Reproduce code:
---
?php
print_r(token_get_all(file_get_contents(__FILE__)));
// test
$var = 5;
// test
Expected result:
Array
(
[0] = Array
(
[0] = 367
[1] = 1
)
[1] = Array
(
[0] = 307
[1] = print_r
[2] = 2
)
[2] = (
[3] = Array
(
[0] = 307
[1] = token_get_all
[2] = 2
)
[4] = (
[5] = Array
(
[0] = 307
[1] = file_get_contents
[2] = 2
)
[6] = (
[7] = Array
(
[0] = 364
[1] = __FILE__
[2] = 2
)
[8] = )
[9] = )
[10] = )
[11] = ;
[12] = Array
(
[0] = 370
[1] =
[2] = 2
)
[13] = Array
(
[0] = 365
[1] = // test
[2] = 4
)
[14] = Array
(
[0] = 309
[1] = $var
[2] = 5
)
[15] = Array
(
[0] = 370
[1] =
[2] = 5
)
[16] = =
[17] = Array
(
[0] = 370
[1] =
[2] = 5
)
[18] = Array
(
[0] = 305
[1] = 5
[2] = 5
)
[19] = ;
[20] = Array
(
[0] = 370
[1] =
[2] = 5
)
[21] = Array
(
[0] = 365
[1] = // test
[2] = 6
)
)
Actual result:
--
Array
(
[0] = Array
(
[0] = 368
[1] = 1
)
[1] = Array
(
[0] = 307
[1] = print_r
[2] = 2
)
[2] = (
[3] = Array
(
[0] = 307
[1] = token_get_all
[2] = 2
)
[4] = (
[5] = Array
(
[0] = 307
[1] = file_get_contents
[2] = 2
)
[6] = (
[7] = Array
(
[0] = 365
[1] = __FILE__
[2] = 2
)
[8] = )
[9] = )
[10] = )
[11] = ;
[12] = Array
(
[0] = 371
[1] =
[2] = 2
)
[13] = Array
(
[0] = 366
[1] = // test
[2] = 4
)
[14] = Array
(
[0] = 309
#46701 [Opn]: Creating associative array with long values in the key fails on 32bit linux
ID: 46701 Updated by: sh...@php.net Reported By: testuzer at hotmail dot com Status: Open Bug Type: Arrays related Operating System: Linux 32bit - ubuntu PHP Version: 5CVS, 6CVS (2008-11-28) New Comment: Proposed patches to make $array[$double] perform the same as $array[intval($double)]... http://tekrat.com/patches/bug46701.php6.patch http://tekrat.com/patches/bug46701.php53.patch http://tekrat.com/patches/bug46701.php52.patch Previous Comments: [2008-12-04 01:43:46] msara...@php.net Array ( [-2147483648] = 1 ) Reproduced here. [2008-12-01 01:49:09] cyberquoter at gmail dot com OS: Debian Linux 2.6.18-6-686 (32bit) PHP: 5.2.0-8+etch13 Result: Array ( [-2147483648] = 1 ) [2008-11-29 06:56:11] testuzer at hotmail dot com Can also confirm Linux -ubuntu 64bit works. Actual result Linux 64bit (php 5.2.4): -- Array ( [3428599296] = 1 [3459455488] = 1 [3459616768] = 1 ) Obviously the 32bit os treats it as a signed 32bit value and a 64bit os as a 64bit value. so you get a positive value. The array key handling is _only_ broken on linux 32bit. [2008-11-29 06:18:33] testuzer at hotmail dot com Here is a simple test: Reproduce code: --- echo 0xcc5c4600; var_dump( 0xcc5c4600 ); print_r( 0xcc5c4600 ); For both Windows and Linux - ubuntu the result is the same. Actual result Windows 32bit: -- 3428599296 float(3428599296) 3428599296 Actual result Linux 32bit: -- 3428599296 float 3428599296 3428599296 So it is not a hex to long conversion problem. Running the same array test using decimals and same values. Reproduce code: --- $test_array = array( 3428599296 = 1, 3459455488 = 1, 3459616768 = 1 ); print_r( $test_array ); Actual result Windows 32bit: -- Array ( [-866368000] = 1 [-835511808] = 1 [-835350528] = 1 ) Actual result Linux 32bit: -- Array ( [-2147483648] = 1 ) [2008-11-28 20:10:29] matt...@php.net Is this really only happening with array indexes...? Either way, the bug title isn't accurate. If it's only with array indexes, it shouldn't be hexadecimal-related, but would be coming from the simple (long) cast of any double value (from long values in the key) in zend_hash_*, resulting in undefined behavior. But, are those values even correct before the array part gets processed? e.g. does var_dump(0xcc5c4600) give 3428599296? If not, then it's obviously not array-specific. :-) Hmm, I was just going to say, see Bug #45068 for the possible cause (and http://news.php.net/php.internals/40199), but I just noticed that you marked that Bogus Jani? Cross-compiling isn't supported? Well, I guess you're not doing that then when reproducing this... How about you, bug reporter? 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/46701 -- Edit this bug report at http://bugs.php.net/?id=46701edit=1
#45591 [NoF-Csd]: Bus error on file_get_contents
ID: 45591 Updated by: [EMAIL PROTECTED] Reported By: rommer at active dot by -Status: No Feedback +Status: Closed Bug Type: Reproducible crash Operating System: linux-2.6.x i386 PHP Version: 5.2CVS-2008-07-22 (snap) Previous Comments: [2008-11-14 21:48:39] [EMAIL PROTECTED] Looks like this is fixed in php-5.2.6+ (I just tested this). Can you please verify if this is still an open issue for you as well using latest CVS or php-5.2.6+ [2008-10-27 19:12:38] steveh at brendata dot co dot uk I'm seeing the same issue, also, the original poster has supplied the required information but has not changed the status so this may have been missed? php -v PHP 5.2.4-2ubuntu5.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Jul 23 2008 06:44:49) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans php -m [PHP Modules] bcmath bz2 calendar ctype date dba dom exif fileinfo filter ftp gd gettext hash iconv json libxml mbstring mime_magic mysql mysqli ncurses openssl pcntl pcre PDO pdo_mysql posix readline Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xdebug xml xmlreader xmlwriter zip zlib [Zend Modules] Xdebug [2008-09-29 15:29:48] rlucia at iscanet dot com # php -v PHP 5.2.5 (cli) (built: Apr 16 2008 19:24:05) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator # php -m [PHP Modules] ctype curl date dom eAccelerator ffmpeg filter gd geoip hash iconv json libxml magickwand mcrypt memcache mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML SPL SQLite standard tokenizer xml xmlreader xmlwriter zlib [Zend Modules] eAccelerator Core was generated by `/usr/local/apache2//bin/httpd -k start'. Program terminated with signal 7, Bus error. #0 0xb7d09b35 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d09b35 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7af3f4c in _php_stream_copy_to_mem (src=0xb6ed7db8, buf=0xbff4f9bc, maxlen=4294967295, persistent=0) at /usr/local/src/php-5.2.5/main/streams/streams.c:1223 #2 0xb7a83106 in zif_file_get_contents (ht=1, return_value=0xb2372fd4, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-5.2.5/ext/standard/file.c:563 #3 0xb7b3cbb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff4fbd0) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #4 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #5 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff4fe10) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #6 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #7 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50050) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #8 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #9 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50290) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #10 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #11 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50740) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #12 0xb7b3bbe8 in execute (op_array=0xb23b5e9c) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #13 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50a40) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #14 0xb7b3bbe8 in execute (op_array=0xb23af4b8) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #15 0xb7b13df8 in zend_call_function (fci=0xbff50b88, fci_cache=0xbff50bac) at /usr/local/src/php-5.2.5/Zend/zend_execute_API.c:990 #16 0xb7a03ca5 in zim_reflection_method_invokeArgs (ht=2, return_value=0xb236d4f8, return_value_ptr=0x0, this_ptr=0xb236cedc, return_value_used=1) at /usr/local/src/php-5.2.5/ext/reflection/php_reflection.c:2479 #17 0xb7b3cbb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50dc0) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #18 0xb7b3bbe8 in execute (op_array=0xb23e9094) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #19 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff51080) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #20 0xb7b3bbe8 in execute (op_array=0xb23e9160) at
#45591 [NoF]: Bus error on file_get_contents
ID: 45591 Updated by: [EMAIL PROTECTED] Reported By: rommer at active dot by Status: No Feedback Bug Type: Reproducible crash Operating System: linux-2.6.x i386 PHP Version: 5.2CVS-2008-07-22 (snap) New Comment: Looks like this is fixed in php-5.2.6+ (I just tested this). Can you please verify if this is still an open issue for you as well using latest CVS or php-5.2.6+ Previous Comments: [2008-10-27 19:12:38] steveh at brendata dot co dot uk I'm seeing the same issue, also, the original poster has supplied the required information but has not changed the status so this may have been missed? php -v PHP 5.2.4-2ubuntu5.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Jul 23 2008 06:44:49) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans php -m [PHP Modules] bcmath bz2 calendar ctype date dba dom exif fileinfo filter ftp gd gettext hash iconv json libxml mbstring mime_magic mysql mysqli ncurses openssl pcntl pcre PDO pdo_mysql posix readline Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xdebug xml xmlreader xmlwriter zip zlib [Zend Modules] Xdebug [2008-09-29 15:29:48] rlucia at iscanet dot com # php -v PHP 5.2.5 (cli) (built: Apr 16 2008 19:24:05) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator # php -m [PHP Modules] ctype curl date dom eAccelerator ffmpeg filter gd geoip hash iconv json libxml magickwand mcrypt memcache mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML SPL SQLite standard tokenizer xml xmlreader xmlwriter zlib [Zend Modules] eAccelerator Core was generated by `/usr/local/apache2//bin/httpd -k start'. Program terminated with signal 7, Bus error. #0 0xb7d09b35 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d09b35 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7af3f4c in _php_stream_copy_to_mem (src=0xb6ed7db8, buf=0xbff4f9bc, maxlen=4294967295, persistent=0) at /usr/local/src/php-5.2.5/main/streams/streams.c:1223 #2 0xb7a83106 in zif_file_get_contents (ht=1, return_value=0xb2372fd4, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-5.2.5/ext/standard/file.c:563 #3 0xb7b3cbb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff4fbd0) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #4 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #5 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff4fe10) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #6 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #7 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50050) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #8 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #9 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50290) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #10 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #11 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50740) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #12 0xb7b3bbe8 in execute (op_array=0xb23b5e9c) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #13 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50a40) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #14 0xb7b3bbe8 in execute (op_array=0xb23af4b8) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #15 0xb7b13df8 in zend_call_function (fci=0xbff50b88, fci_cache=0xbff50bac) at /usr/local/src/php-5.2.5/Zend/zend_execute_API.c:990 #16 0xb7a03ca5 in zim_reflection_method_invokeArgs (ht=2, return_value=0xb236d4f8, return_value_ptr=0x0, this_ptr=0xb236cedc, return_value_used=1) at /usr/local/src/php-5.2.5/ext/reflection/php_reflection.c:2479 #17 0xb7b3cbb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50dc0) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #18 0xb7b3bbe8 in execute (op_array=0xb23e9094) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #19 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff51080) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #20 0xb7b3bbe8 in execute (op_array=0xb23e9160) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #21 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff512d0) at
#42850 [Opn-Csd]: array_walk_recursive() leaves references
ID: 42850
Updated by: [EMAIL PROTECTED]
Reported By: ltaupiac at lfdj dot com
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: windows/solaris
PHP Version: 5.3.0-dev
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-11-26 08:00:18] ltaupiac at lfdj dot com
I have tested on window with apache 2.2.6 the snap.zip you given.
The bug is still there.
A for reference is still leaved after call array_walk_recursive on
val2 and original array can't be duplicate anymore after.
Reproduce code:
--
echo PHP_VERSION;
$data = array ('key1' = 'val1', array('key2' = 'val2'));
echo 'pre';
function foo2($item, $key) {}; // dumb callback function
var_dump($data);
array_walk_recursive($data, 'foo2');
$data2 = $data; // Duplicate array
$data2[0] = 'altered'; // Alter copy
var_dump($data);
var_dump($data2);
Expected result:
5.3.0-dev
array(2) {
[key1]=
string(4) val1
[0]=
array(1) {
[key2]=
string(4) val2
}
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) val2
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) altered
}
Actual result:
--
5.3.0-dev
array(2) {
[key1]=
string(4) val1
[0]=
array(1) {
[key2]=
string(4) val2
}
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) altered
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) altered
}
[2007-11-25 17:35:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
[2007-10-04 08:10:34] ltaupiac at lfdj dot com
Description:
I have to reopen this bug http://bugs.php.net/bug.php?id=42655 because
it was incorrectly closed and tony2001 doesn't seem to receive email.
Here Copy/paste email i send him.
This is not the same bug.
In #34982, an array is modified outside the function func() that call
array_walk_recursive. This bug doesn't exist anymore in 5.2.4
The bug i report is when calling array_walk_recursive on an array
(callback function doesn't even have reference for array input and
does nothing).
Original array shouldn't be modified, but if you var_dump it, you can
see reference on subarray
[0]= array(1)
instead of
[0]= array(1)
The array shouldn't have been modified but array_walk_recursive leaves
references.
This can cause trouble, eg you cant duplicate the original array
anymore. Look at following example
$data = array ('key1' = 'val1', array('key2' = 'val2'));
function foo($item, $key) {}; // dumb callback function
var_dump($data);
array_walk_recursive($data, 'foo');
$data2 = $data; // Duplicate array
$data2[0] = 'altered'; // Alter copy
var_dump($data);
var_dump($data2);
array(2) {
[key1]= string(4) val1
[0]= string(5) bingo
}
array(2) {
[key1]= string(4) val1
[0]= string(5) bingo
}
both $data and $data2 are altered;
Reproduce code:
---
$data = array ('key1' = 'val1', array('key2' = 'val2'));
function dumb($i, $k){}
var_dump($data);
array_walk_recursive($data,'foo');
// Double check the [0]=array(1) in actual result
var_dump($data);
Expected result:
Expected result:
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
Actual result:
--
Actual result:
--
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
--
Edit this bug report at http://bugs.php.net/?id=42850edit=1
#39891 [Opn]: htmlentities missing entity
ID: 39891
Updated by: [EMAIL PROTECTED]
Reported By: jeff at dakusan dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Multiple (XP RedHat)
PHP Version: 5.2.0
New Comment:
Hello, if you specify the encoding type UTF-8 this should work as
expected, I don't believe right single quote is part of the default
iso-8859-1 specification.
?php
$char = html_entity_decode('rsquo;', ENT_COMPAT, 'UTF-8');
echo $char;
echo htmlentities($char, ENT_COMPAT, 'UTF-8');
?
Previous Comments:
[2006-12-19 17:39:15] jeff at dakusan dot com
Description:
htmlentities is missing the character as rsquo;.
Reproduce code:
---
print htmlentities();
Expected result:
rsquo;
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=39891edit=1
#30074 [NoF-Csd]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Updated by: [EMAIL PROTECTED]
Reported By: owen dot beresford at murphx dot com
-Status: No Feedback
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-12-10 00:55:50] shire at facebook dot com
I forgot to specify that in this case extract is setting the
EG(uninitialized_zval_ptr)-is_ref = 1, causing further problems later
in the code.
[2006-12-10 00:54:25] shire at facebook dot com
I'm able to reproduce this using current CVS. The problem appears to
be when a CV value is passed into extract() either as the array or an
array value. Looks like in this case the IS_CV value is assigned to
EG(uninitialized_zval_ptr). The following patch will correct the
problem for this case (and still pass a php 'make test'). However I'm
not familiar enough with CV to know if there's a better way to correct
to this problem:
diff --git a/ext/standard/array.c b/ext/standard/array.c
index fad4bf2..fdc9a88 100644
--- a/ext/standard/array.c
+++ b/ext/standard/array.c
@@ -1438,7 +1438,7 @@ PHP_FUNCTION(extract)
*orig_var = *entry;
} else {
- if
((*var_array)-refcount 1) {
+ if
((*var_array)-refcount 1 || *entry == EG(uninitialized_zval_ptr)) {
SEPARATE_ZVAL_TO_MAKE_IS_REF(entry);
} else {
(*entry)-is_ref = 1;
[2005-06-15 23:06:27] t3 at rohms dot com
Has this bug been fixed in a release yet? I'd like to see comments
added to these to indicate so and with what versions.
[2005-03-15 01:00:12] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-03-07 21:42:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
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/30074
--
Edit this bug report at http://bugs.php.net/?id=30074edit=1
#30074 [Com]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Comment by: shire at facebook dot com
Reported By: owen dot beresford at murphx dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
I'm able to reproduce this using current CVS. The problem appears to
be when a CV value is passed into extract() either as the array or an
array value. Looks like in this case the IS_CV value is assigned to
EG(uninitialized_zval_ptr). The following patch will correct the
problem for this case (and still pass a php 'make test'). However I'm
not familiar enough with CV to know if there's a better way to correct
to this problem:
diff --git a/ext/standard/array.c b/ext/standard/array.c
index fad4bf2..fdc9a88 100644
--- a/ext/standard/array.c
+++ b/ext/standard/array.c
@@ -1438,7 +1438,7 @@ PHP_FUNCTION(extract)
*orig_var = *entry;
} else {
- if
((*var_array)-refcount 1) {
+ if
((*var_array)-refcount 1 || *entry == EG(uninitialized_zval_ptr)) {
SEPARATE_ZVAL_TO_MAKE_IS_REF(entry);
} else {
(*entry)-is_ref = 1;
Previous Comments:
[2005-06-15 23:06:27] t3 at rohms dot com
Has this bug been fixed in a release yet? I'd like to see comments
added to these to indicate so and with what versions.
[2005-03-15 01:00:12] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-03-07 21:42:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-29 21:36:34] t3 at rohms dot com
I believe my problem may be related; I also filed a a
href=http://bugs.php.net/?id=31753;report/a but not every isntance
of extract() was causing problems. I was running 4.3.6 with no
problems; upgraded to 4.3.10 and code didn't work; updated to latest
version of zend; didn't work; downgraded back to 4.3.6, didn't work;
downgraded to 4.3.6 and switched back to previous version of zend:
worked. It seems that the new version of zend may be invovled in the
problem. I wonder if turning down the optimization level would help?
[2005-01-19 22:10:26] [EMAIL PROTECTED]
See also bug #31217
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/30074
--
Edit this bug report at http://bugs.php.net/?id=30074edit=1
#30074 [Com]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Comment by: shire at facebook dot com
Reported By: owen dot beresford at murphx dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
I forgot to specify that in this case extract is setting the
EG(uninitialized_zval_ptr)-is_ref = 1, causing further problems later
in the code.
Previous Comments:
[2006-12-10 00:54:25] shire at facebook dot com
I'm able to reproduce this using current CVS. The problem appears to
be when a CV value is passed into extract() either as the array or an
array value. Looks like in this case the IS_CV value is assigned to
EG(uninitialized_zval_ptr). The following patch will correct the
problem for this case (and still pass a php 'make test'). However I'm
not familiar enough with CV to know if there's a better way to correct
to this problem:
diff --git a/ext/standard/array.c b/ext/standard/array.c
index fad4bf2..fdc9a88 100644
--- a/ext/standard/array.c
+++ b/ext/standard/array.c
@@ -1438,7 +1438,7 @@ PHP_FUNCTION(extract)
*orig_var = *entry;
} else {
- if
((*var_array)-refcount 1) {
+ if
((*var_array)-refcount 1 || *entry == EG(uninitialized_zval_ptr)) {
SEPARATE_ZVAL_TO_MAKE_IS_REF(entry);
} else {
(*entry)-is_ref = 1;
[2005-06-15 23:06:27] t3 at rohms dot com
Has this bug been fixed in a release yet? I'd like to see comments
added to these to indicate so and with what versions.
[2005-03-15 01:00:12] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-03-07 21:42:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-29 21:36:34] t3 at rohms dot com
I believe my problem may be related; I also filed a a
href=http://bugs.php.net/?id=31753;report/a but not every isntance
of extract() was causing problems. I was running 4.3.6 with no
problems; upgraded to 4.3.10 and code didn't work; updated to latest
version of zend; didn't work; downgraded back to 4.3.6, didn't work;
downgraded to 4.3.6 and switched back to previous version of zend:
worked. It seems that the new version of zend may be invovled in the
problem. I wonder if turning down the optimization level would help?
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/30074
--
Edit this bug report at http://bugs.php.net/?id=30074edit=1
#30777 [NEW]: Apache/PHP/DB3/DB4/Subversion causes repeatable segfault
From: shire at tekrat dot com Operating system: Linux Slackware PHP version: 4.3.9 PHP Bug Type: Apache related Bug description: Apache/PHP/DB3/DB4/Subversion causes repeatable segfault Description: I've noticed segfaults occuring both on the initial call of any php file or on the imap_open call, although the nature of the code/call seems to be irrelevent to the actual problem. It becames apparent that the PHP/Apache/Subversion/DB3/DB4 combination becomes a problem. Even with PHP/Apache/Subversion compiled with DB4, if a DB3.so is added to the system, then php/apache will begin to segfault. This has been observed in php4.3.8 (faults on any php script) and php4.3.9(fault on imap_open). it appears that php will try and load any db library it finds, rather than the latest module ie: db4 over db3. This apparently causes a conflict/segfault in php/apache. Reproduce code: --- You can reproduce this by compiling php/apache/subversion with DB4(required by subversion) and then adding db3.so to the system. Expected result: n/a -- Edit bug report at http://bugs.php.net/?id=30777edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30777r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30777r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30777r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30777r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30777r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30777r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30777r=needscript Try newer version: http://bugs.php.net/fix.php?id=30777r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30777r=support Expected behavior: http://bugs.php.net/fix.php?id=30777r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30777r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30777r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30777r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30777r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30777r=dst IIS Stability: http://bugs.php.net/fix.php?id=30777r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30777r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30777r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30777r=mysqlcfg
#30777 [Fbk-Opn]: Apache/PHP/DB3/DB4/Subversion causes repeatable segfault
ID: 30777
User updated by: shire at tekrat dot com
Reported By: shire at tekrat dot com
-Status: Feedback
+Status: Open
Bug Type: Apache related
Operating System: Linux Slackware
PHP Version: 4.3.9
New Comment:
Backtrace
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 30943)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x40945928 in ?? ()
#2 0x409459e0 in ?? ()
#3 0x409443fe in ?? ()
#4 0x40944668 in ?? ()
#5 0x4037c7cf in getprotobyname_r () from /lib/libc.so.6
#6 0x4037c67d in getprotobyname () from /lib/libc.so.6
#7 0x4059c76a in tcp_socket_open (family=2, adr=0x8350608, adrlen=4,
port=143,
tmp=0xbfff5c5c
\223Å´\b¼äÿ¿f([EMAIL PROTECTED]:@¼äÿ¿!'[EMAIL PROTECTED]@\n,
ctr=0xbfff5c58, hst=0x835062e .com)
at tcp_unix.c:225
#8 0x4059c5ce in tcp_open (host=0xbfff652c .com, service=0x0,
port=143) at tcp_unix.c:184
#9 0x405af673 in net_open_work (dv=0x4067ba00, host=0xbfff652c
x.com, service=0xbfff68ae imap, port=143,
portoverride=143, flags=0) at mail.c:5947
#10 0x405adef3 in net_open (mb=0xbfff652c, dv=0x0, port=143,
ssld=0x4067b840, ssls=0x40662bcc *imaps, sslp=993)
at mail.c:5918
#11 0x405c0062 in imap_open (stream=0x834c498) at imap4r1.c:823
#12 0x405a38d9 in mail_open (stream=0x834c498, name=0x829cb04
{tekrat.com:143/imap/notls}, options=0) at mail.c:1206
#13 0x404b1418 in php_imap_do_open (ht=4, return_value=0x8337424,
this_ptr=0x0, return_value_used=1, persistent=0)
at /home/shire/install/php-4.3.9/ext/imap/php_imap.c:740
#14 0x404b14c9 in zif_imap_open (ht=4, return_value=0x8337424,
this_ptr=0x0, return_value_used=1)
at /home/shire/install/php-4.3.9/ext/imap/php_imap.c:761
#15 0x4058cdc3 in execute (op_array=0x829765c) at
/home/shire/install/php-4.3.9/Zend/zend_execute.c:1642
#16 0x4058cf3a in execute (op_array=0x8295244) at
/home/shire/install/php-4.3.9/Zend/zend_execute.c:1684
#17 0x4058cf3a in execute (op_array=0x81b9804) at
/home/shire/install/php-4.3.9/Zend/zend_execute.c:1684
#18 0x4057b08e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/shire/install/php-4.3.9/Zend/zend.c:891
#19 0x40552c55 in php_execute_script (primary_file=0xb3d8) at
/home/shire/install/php-4.3.9/main/main.c:1735
#20 0x4059449f in php_handler (r=0x81af140) at
/home/shire/install/php-4.3.9/sapi/apache2handler/sapi_apache2.c:540
#21 0x080671f9 in ap_run_handler (r=0x81af140) at config.c:151
#22 0x08067743 in ap_invoke_handler (r=0x81af140) at config.c:358
#23 0x08064b06 in ap_process_request (r=0x81af140) at
http_request.c:246
#24 0x08060a8a in ap_process_http_connection (c=0x81a9108) at
http_core.c:250
#25 0x0806f658 in ap_run_process_connection (c=0x81a9108) at
connection.c:42
#26 0x0806f91c in ap_process_connection (c=0x81a9108, csd=0x81a9030) at
connection.c:175
#27 0x08065e80 in child_main (child_num_arg=0) at prefork.c:609
#28 0x08065f3c in make_child (s=0x809c310, slot=0) at prefork.c:649
#29 0x08066031 in startup_children (number_to_start=10) at
prefork.c:721
#30 0x08066333 in ap_mpm_run (_pconf=0x809a570, plog=0x80c4618,
s=0x809c310) at prefork.c:940
#31 0x0806baee in main (argc=2, argv=0xb7a4) at main.c:617
(gdb)
here's the output of an strace call of httpd -X, while calling the same
code as above(summarized)
[This is loading lidb4 when apache starts]
open(/usr/local/apache2/lib/libdb-4.0.so, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/local/BerkeleyDB.4.0/lib/libdb-4.0.so, O_RDONLY) = 3
open(/usr/local/apache2/lib/libdb3.so.3, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/local/BerkeleyDB.4.0/lib/libdb3.so.3, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/lib/libdb3.so.3, O_RDONLY) = 21
[This is after the php is called, and php.so loads the
libdb3.so]
let me know if there's anything else I can provide...
Previous Comments:
[2004-11-13 21:25:03] [EMAIL PROTECTED]
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
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.
[2004-11-13 21:19:23] shire at tekrat dot com
Description:
I've noticed segfaults occuring both on the initial call of any php
file or on the imap_open call, although the nature of the code/call
seems to be irrelevent to the actual problem. It becames apparent that
the PHP/Apache/Subversion/DB3/DB4 combination becomes a problem. Even
with PHP/Apache/Subversion compiled with DB4, if a DB3.so is added to
the system, then php/apache will begin
#30777 [Bgs]: Apache/PHP/DB3/DB4/Subversion causes repeatable segfault
ID: 30777
User updated by: shire at tekrat dot com
Reported By: shire at tekrat dot com
Status: Bogus
Bug Type: Apache related
Operating System: *
PHP Version: *
New Comment:
I think I'm being misunderstood. PHP is loading the db3 shared object
rather than the db4 library when both are present and when PHP was
compiled with only the db4 library present. This means that in order
to run PHP/Apache/Subversion I have to remove db3 from the system, and
can NEVER install db3. Is this the correct functionality of PHP? Is
there a way to prevent php from loading the db3 library? Thanks.
Previous Comments:
[2004-11-13 23:57:28] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You can not load more than one db* module in one process unless you
configure them to have different names. That said i wonder how you
could build your installation.
[2004-11-13 23:25:19] shire at tekrat dot com
Backtrace
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 30943)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x40945928 in ?? ()
#2 0x409459e0 in ?? ()
#3 0x409443fe in ?? ()
#4 0x40944668 in ?? ()
#5 0x4037c7cf in getprotobyname_r () from /lib/libc.so.6
#6 0x4037c67d in getprotobyname () from /lib/libc.so.6
#7 0x4059c76a in tcp_socket_open (family=2, adr=0x8350608, adrlen=4,
port=143,
tmp=0xbfff5c5c
\223Å´\b¼äÿ¿f([EMAIL PROTECTED]:@¼äÿ¿!'[EMAIL PROTECTED]@\n,
ctr=0xbfff5c58, hst=0x835062e .com)
at tcp_unix.c:225
#8 0x4059c5ce in tcp_open (host=0xbfff652c .com, service=0x0,
port=143) at tcp_unix.c:184
#9 0x405af673 in net_open_work (dv=0x4067ba00, host=0xbfff652c
x.com, service=0xbfff68ae imap, port=143,
portoverride=143, flags=0) at mail.c:5947
#10 0x405adef3 in net_open (mb=0xbfff652c, dv=0x0, port=143,
ssld=0x4067b840, ssls=0x40662bcc *imaps, sslp=993)
at mail.c:5918
#11 0x405c0062 in imap_open (stream=0x834c498) at imap4r1.c:823
#12 0x405a38d9 in mail_open (stream=0x834c498, name=0x829cb04
{tekrat.com:143/imap/notls}, options=0) at mail.c:1206
#13 0x404b1418 in php_imap_do_open (ht=4, return_value=0x8337424,
this_ptr=0x0, return_value_used=1, persistent=0)
at /home/shire/install/php-4.3.9/ext/imap/php_imap.c:740
#14 0x404b14c9 in zif_imap_open (ht=4, return_value=0x8337424,
this_ptr=0x0, return_value_used=1)
at /home/shire/install/php-4.3.9/ext/imap/php_imap.c:761
#15 0x4058cdc3 in execute (op_array=0x829765c) at
/home/shire/install/php-4.3.9/Zend/zend_execute.c:1642
#16 0x4058cf3a in execute (op_array=0x8295244) at
/home/shire/install/php-4.3.9/Zend/zend_execute.c:1684
#17 0x4058cf3a in execute (op_array=0x81b9804) at
/home/shire/install/php-4.3.9/Zend/zend_execute.c:1684
#18 0x4057b08e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/shire/install/php-4.3.9/Zend/zend.c:891
#19 0x40552c55 in php_execute_script (primary_file=0xb3d8) at
/home/shire/install/php-4.3.9/main/main.c:1735
#20 0x4059449f in php_handler (r=0x81af140) at
/home/shire/install/php-4.3.9/sapi/apache2handler/sapi_apache2.c:540
#21 0x080671f9 in ap_run_handler (r=0x81af140) at config.c:151
#22 0x08067743 in ap_invoke_handler (r=0x81af140) at config.c:358
#23 0x08064b06 in ap_process_request (r=0x81af140) at
http_request.c:246
#24 0x08060a8a in ap_process_http_connection (c=0x81a9108) at
http_core.c:250
#25 0x0806f658 in ap_run_process_connection (c=0x81a9108) at
connection.c:42
#26 0x0806f91c in ap_process_connection (c=0x81a9108, csd=0x81a9030) at
connection.c:175
#27 0x08065e80 in child_main (child_num_arg=0) at prefork.c:609
#28 0x08065f3c in make_child (s=0x809c310, slot=0) at prefork.c:649
#29 0x08066031 in startup_children (number_to_start=10) at
prefork.c:721
#30 0x08066333 in ap_mpm_run (_pconf=0x809a570, plog=0x80c4618,
s=0x809c310) at prefork.c:940
#31 0x0806baee in main (argc=2, argv=0xb7a4) at main.c:617
(gdb)
here's the output of an strace call of httpd -X, while calling the same
code as above(summarized)
[This is loading lidb4 when apache starts]
open(/usr/local/apache2/lib/libdb-4.0.so, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/local/BerkeleyDB.4.0/lib/libdb-4.0.so, O_RDONLY) = 3
open(/usr/local/apache2/lib/libdb3.so.3, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/local/BerkeleyDB.4.0/lib/libdb3.so.3, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/lib/libdb3.so.3, O_RDONLY) = 21
[This is after the php is called, and php.so loads the
libdb3.so]
let me know if there's anything else I can provide
