#28009 [Bgs]: "make test" got hung
ID: 28009 User updated by: dhananjaya dot eadala at oracle dot com Reported By: dhananjaya dot eadala at oracle dot com Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 4.3.6RC3 New Comment: Here is complete info about system I used. OS: Redhat Enterprise Linux 3.0 AS glibc version: 2.3.2-95.3 sniper, do you need any further info to analyse the problem. Previous Comments: [2004-04-15 19:13:49] [EMAIL PROTECTED] There is some bug in your system. (Not enough information given to say exactly what is wrong but I bet it's buggy glibc..) [2004-04-15 11:11:10] dhananjaya dot eadala at oracle dot com when I remove the bug21523.phpt from test suite, "make test" went on fine. [2004-04-15 10:51:00] dhananjaya dot eadala at oracle dot com Description: php cli and .so was built successfully. after when I issue "make test" command, it is getting hung at running the test for ext/standard/tests/math/bug21523.phpt test. assuming it is problem with make, I ran the same test manually using php cli. still I ran to same problem of getting hung. Is there any work around for this. -- Edit this bug report at http://bugs.php.net/?id=28009&edit=1
#28017 [NEW]: php_pdf.dll corrupt in final 4.3.6 zip package
From: phpcoder at jkap dot com Operating system: windows 2000 PHP version: 4.3.6RC3 PHP Bug Type: Dynamic loading Bug description: php_pdf.dll corrupt in final 4.3.6 zip package Description: Extract older php_pdf.dll (528kb) into extensions dir from previous release (4.3.6RC3) to replace current one contained in zip package(72kb). Reproduce code: --- Uncomment 'extension=php_pdf.dll' in php.ini. Expected result: Error will pop up on server indicating "Unable to load dynamic library '.\extensions\php_pdf.dll' - The specified module could not be found. -- Edit bug report at http://bugs.php.net/?id=28017&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28017&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28017&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28017&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28017&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28017&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28017&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28017&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28017&r=support Expected behavior: http://bugs.php.net/fix.php?id=28017&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28017&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28017&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28017&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28017&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28017&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28017&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28017&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28017&r=float
#28008 [Bgs]: apache 2 and php4 child segfaults when accessing php pages
ID: 28008 Updated by: [EMAIL PROTECTED] Reported By: dzila at tassadar dot physics dot auth dot gr Status: Bogus Bug Type: Apache2 related Operating System: Slackware 8 , kernel 2.4.25 PHP Version: 4CVS-2004-04-15 (stable) New Comment: See bug #25400 and bug #26929 Previous Comments: [2004-04-15 20:47:05] dzila at tassadar dot physics dot auth dot gr I have installed gdb 6 which provides some more info , not sure if it is of any use gdb ./httpd GNU gdb 6.0 Copyright 2003 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x082e1ca0 in ?? () (gdb) bt #0 0x082e1ca0 in ?? () #1 0x405e9e1e in db_open () from /lib/libnss_db.so.2 #2 0x405e9ed0 in internal_setent () from /lib/libnss_db.so.2 #3 0x405e962e in _nss_db_endservent () from /lib/libnss_db.so.2 #4 0x405e98c3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2 #5 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #6 0x40386771 in getservbyname () from /lib/libc.so.6 #7 0x4056c3bf in mysql_once_init () from /disk2/daemons/mysql/lib/mysql/libmysqlclient.so.12 #8 0x4056eeb4 in mysql_init () from /disk2/daemons/mysql/lib/mysql/libmysqlclient.so.12 #9 0x403fe0a6 in php_mysql_do_connect (ht=3, return_value=0x81c8444, this_ptr=0x0, return_value_used=1, persistent=0) at /disk2/builder/web2/php4-STABLE-200404151230/ext/mysql/php_mysql.c:771 #10 0x403fe3c5 in zif_mysql_connect (ht=3, return_value=0x81c8444, this_ptr=0x0, return_value_used=1) at /disk2/builder/web2/php4-STABLE-200404151230/ext/mysql/php_mysql.c:827 #11 0x405128e2 in execute (op_array=0x82c091c) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1635 #12 0x40512b2c in execute (op_array=0x82b1264) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #13 0x40512b2c in execute (op_array=0x81df2b8) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #14 0x40512b2c in execute (op_array=0x81dda08) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #15 0x40512b2c in execute (op_array=0x81be10c) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #16 0x404ff484 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend.c:886 #17 0x404c310c in php_execute_script (primary_file=0xb61c) at /disk2/builder/web2/php4-STABLE-200404151230/main/main.c:1731 #18 0x4051939c in php_handler (r=0x81b0ef0) at /disk2/builder/web2/php4-STABLE-200404151230/sapi/apache2handler/sapi_apache2.c:561 #19 0x08097929 in ap_run_handler (r=0x81b0ef0) at config.c:151 #20 0x08097e73 in ap_invoke_handler (r=0x81b0ef0) at config.c:358 #21 0x08087a76 in ap_process_request (r=0x81b0ef0) at http_request.c:246 #22 0x0808393a in ap_process_http_connection (c=0x81acec0) at http_core.c:250 #23 0x080a0e88 in ap_run_process_connection (c=0x81acec0) at connection.c:42 #24 0x080a115c in ap_process_connection (c=0x81acec0, csd=0x81acde8) at connection.c:175 #25 0x080965b0 in child_main (child_num_arg=0) at prefork.c:609 #26 0x0809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #27 0x08096761 in startup_children (number_to_start=5) at prefork.c:721 #28 0x08096a63 in ap_mpm_run (_pconf=0x80dc270, plog=0x8114350, s=0x80df138) at prefork.c:940 ---Type to continue, or q to quit--- #29 0x0809c26e in main (argc=2, argv=0xba04) at main.c:617 [2004-04-15 10:43:21] dzila at tassadar dot physics dot auth dot gr Description: I am compiling apache2 and php for the first time. Every time a php page is accessed the apache child segfaults and no php page can be displayed. I tried with 4.3.5 and the latest 4 snap.Non php pages work fine /configure --with-apxs2=/disk2/daemons/www2/bin/apxs --with-openssl --enable-cli --enable-ftp --with-zlib --with-zip --with-mysql=/disk2/daemons/mysql --enable-debug (also tried only with-apxs and no other options , --with-mysql on its on, same results) I am launching apache2 because I want ipv6 enabled web server , I tried binding it to both ipv6 and ipv4 addresses with same results Reproduce code: --- a postnuke site which works ok with apache 1.3 Actual result: -- gdb ./httpd GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free
#28008 [Opn->Bgs]: apache 2 and php4 child segfaults when accessing php pages
ID: 28008 Updated by: [EMAIL PROTECTED] Reported By: dzila at tassadar dot physics dot auth dot gr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Slackware 8 , kernel 2.4.25 PHP Version: 4CVS-2004-04-15 (stable) New Comment: The backtrace just proves it: The crash happens in the mysql library, there's absolutely nothing we can do about it. (a guess: You have some module in apache using mysql libs/or those other libs and they collide somehow..) Previous Comments: [2004-04-15 20:47:05] dzila at tassadar dot physics dot auth dot gr I have installed gdb 6 which provides some more info , not sure if it is of any use gdb ./httpd GNU gdb 6.0 Copyright 2003 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x082e1ca0 in ?? () (gdb) bt #0 0x082e1ca0 in ?? () #1 0x405e9e1e in db_open () from /lib/libnss_db.so.2 #2 0x405e9ed0 in internal_setent () from /lib/libnss_db.so.2 #3 0x405e962e in _nss_db_endservent () from /lib/libnss_db.so.2 #4 0x405e98c3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2 #5 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #6 0x40386771 in getservbyname () from /lib/libc.so.6 #7 0x4056c3bf in mysql_once_init () from /disk2/daemons/mysql/lib/mysql/libmysqlclient.so.12 #8 0x4056eeb4 in mysql_init () from /disk2/daemons/mysql/lib/mysql/libmysqlclient.so.12 #9 0x403fe0a6 in php_mysql_do_connect (ht=3, return_value=0x81c8444, this_ptr=0x0, return_value_used=1, persistent=0) at /disk2/builder/web2/php4-STABLE-200404151230/ext/mysql/php_mysql.c:771 #10 0x403fe3c5 in zif_mysql_connect (ht=3, return_value=0x81c8444, this_ptr=0x0, return_value_used=1) at /disk2/builder/web2/php4-STABLE-200404151230/ext/mysql/php_mysql.c:827 #11 0x405128e2 in execute (op_array=0x82c091c) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1635 #12 0x40512b2c in execute (op_array=0x82b1264) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #13 0x40512b2c in execute (op_array=0x81df2b8) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #14 0x40512b2c in execute (op_array=0x81dda08) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #15 0x40512b2c in execute (op_array=0x81be10c) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #16 0x404ff484 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend.c:886 #17 0x404c310c in php_execute_script (primary_file=0xb61c) at /disk2/builder/web2/php4-STABLE-200404151230/main/main.c:1731 #18 0x4051939c in php_handler (r=0x81b0ef0) at /disk2/builder/web2/php4-STABLE-200404151230/sapi/apache2handler/sapi_apache2.c:561 #19 0x08097929 in ap_run_handler (r=0x81b0ef0) at config.c:151 #20 0x08097e73 in ap_invoke_handler (r=0x81b0ef0) at config.c:358 #21 0x08087a76 in ap_process_request (r=0x81b0ef0) at http_request.c:246 #22 0x0808393a in ap_process_http_connection (c=0x81acec0) at http_core.c:250 #23 0x080a0e88 in ap_run_process_connection (c=0x81acec0) at connection.c:42 #24 0x080a115c in ap_process_connection (c=0x81acec0, csd=0x81acde8) at connection.c:175 #25 0x080965b0 in child_main (child_num_arg=0) at prefork.c:609 #26 0x0809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #27 0x08096761 in startup_children (number_to_start=5) at prefork.c:721 #28 0x08096a63 in ap_mpm_run (_pconf=0x80dc270, plog=0x8114350, s=0x80df138) at prefork.c:940 ---Type to continue, or q to quit--- #29 0x0809c26e in main (argc=2, argv=0xba04) at main.c:617 [2004-04-15 20:26:36] [EMAIL PROTECTED] Oh...then your slackware 8 system is broken.. [2004-04-15 20:18:22] dzila at tassadar dot physics dot auth dot gr thanks for your reply sniper , can you be a bit more specific ? I have repeated the same process step by step on another system (slackware 9 ) with the same sources , and it works ok there. I have copied the exact same httpd.conf file. thanks for the help again :) [2004-04-15 19:15:54] [EMAIL PROTECTED] You have misconfigured PHP in the httpd.conf. Please ask supp
#28016 [Opn->Asn]: is_resource() returns false for resources of type "Unknown"
ID: 28016 Updated by: [EMAIL PROTECTED] Reported By: php at ter dot dk -Status: Open +Status: Assigned -Bug Type: Unknown/Other Function +Bug Type: Scripting Engine problem -Operating System: Linux 2.4.17 +Operating System: * -PHP Version: 4.3.6 +PHP Version: 4CVS, 5CVS (2004-04-16) -Assigned To: +Assigned To: derick New Comment: Derick, IMO, the fix for bug #27822 was incorrect. Resource is still a resource even if it's closed.. Or you need to unset the variable with any 'close'.. :) Previous Comments: [2004-04-15 21:15:58] php at ter dot dk Description: (version of PHP is 4.3.6, not 4.3.6RC3, but I wasn't able to select that) If a resource for some reason is of type "Unknown", is_resource() returns false. Though, gettype() still returns "resource" as type, as always. This behaviour in is_resource() has changed between 4.3.5 and 4.3.6. I'm guessing here, but the new behaviour could be related to changes introduced to fix bug 27822 (which was fixed in between 4.3.5 and 4.3.6). In my example I'm using php-imlib to gain an object of type "Unknown". Even though it isn't an official extension, there still is some inconsistency between gettype() returning "resource" and is_resource() returning false. In other words, it's the inconsistency between is_resource() and gettype() I see as the bug. Example is also available at: http://stock.ter.dk/resource_error.php Reproduce code: --- $i = imlib_create_image(100,200); var_dump($i); var_dump(gettype($i)); var_dump(is_resource($i)); Expected result: resource(2) of type (Unknown) string(8) "resource" bool(true) Actual result: -- resource(2) of type (Unknown) string(8) "resource" bool(false) -- Edit this bug report at http://bugs.php.net/?id=28016&edit=1
#28002 [Bgs->Csd]: Soap depends on session
ID: 28002 User updated by: schick at robotbattle dot com Reported By: schick at robotbattle dot com -Status: Bogus +Status: Closed Bug Type: Compile Failure Operating System: Debian GNU/Linux (sarge) PHP Version: 5.0.0RC1 Assigned To: dmitry New Comment: Argg, sorry. make clean did indeed fix the problem. Previous Comments: [2004-04-15 06:29:04] [EMAIL PROTECTED] It works fine. Did you make full rebuild? make clean make [2004-04-15 03:28:11] [EMAIL PROTECTED] Assigning to the maintainer. [2004-04-15 02:10:12] schick at robotbattle dot com Description: Soap extensions seems to depend on session support. Running configure with --disable-session and --enable-soap causes the build to fail with the following: ext/soap/soap.lo(.text+0x3a22): In function `zif_soapserver_handle': /var/src/php-5.0.0RC1/ext/soap/soap.c:1391: undefined reference to `ps_globals' ext/soap/soap.lo(.text+0x3b6a):/var/src/php-5.0.0RC1/ext/soap/soap.c:1342: undefined reference to `ps_globals' ext/soap/soap.lo(.text+0x3bc0):/var/src/php-5.0.0RC1/ext/soap/soap.c:1344: undefined reference to `php_session_start' Reproduce code: --- This is my config: './configure' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-pgsql=/usr/lib/postgresql' \ '--without-sqlite' \ '--disable-session' \ '--enable-soap' \ '--enable-mbstring' \ '--enable-magic-quotes' \ '--enable-memory-limit' \ '--with-zlib-dir=/usr/lib' \ '--enable-force-cgi-redirect' \ '--disable-ipv6' \ '--with-openssl=/usr' \ '--with-mcrypt' \ '--with-imap=/usr' \ '--with-kerberos' \ '--disable-debug' \ '--with-curl=/usr' \ '--with-gd' \ '--with-png-dir=/usr/lib' \ "$@" -- Edit this bug report at http://bugs.php.net/?id=28002&edit=1
#28000 [Bgs]: aolserver critical crash
ID: 28000 User updated by: ustaz99 at catcha dot com Reported By: ustaz99 at catcha dot com Status: Bogus Bug Type: PostgreSQL related Operating System: Linux MDK10.0 PHP Version: 4.3.5 New Comment: erm.. it's okay. probably, I still with aolserver. (it's for openacs, so a compulsary) later i'll give you more information. Previous Comments: [2004-04-15 08:18:53] [EMAIL PROTECTED] >From the sapi/aolserver/README: "Note that there might be thread-safety issues with thread-unsafe libraries/extensions. Test thoroughly before you put anything into production." (this is pretty much impossible to tell what might be going wrong. Just use Apache 1.3.29 and you're fine.) [2004-04-14 22:56:24] ustaz99 at catcha dot com with php-4.3.7dev './configure' '--with-aolserver=/usr/local/aolserver/' '--with-pgsql' '--enable-debug' output console [New Thread 1088641968 (LWP 14525)] [New Thread 1088711600 (LWP 14526)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1088641968 (LWP 14525)] 0x40c138e1 in execute (op_array=0x864b078, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:1266 1266 zend_fetch_var_address(EX(opline), EX(Ts), BP_VAR_W TSRMLS_CC); (gdb) i r eax0x80c76c8135034568 ecx0x810b050135311440 edx0x864b078140816504 ebx0x40c5ce3c 1086705212 esp0x40e25fb0 0x40e25fb0 ebp0x40e30a68 0x40e30a68 esi0x40e5d030 1088802864 edi0x40e5d030 1088802864 eip0x40c138e1 0x40c138e1 eflags 0x210207 2163207 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x40c138e1 in execute (op_array=0x864b078, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:1266 #1 0x40c18d53 in execute (op_array=0x864f258, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:2200 #2 0x40c18d53 in execute (op_array=0x864a0e8, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:2200 #3 0x40c05cf0 in zend_execute_scripts (type=8, tsrm_ls=0x80c76c8, retval=Variable "retval" is not available. ) at /root/php4-STABLE-200404150030/Zend/zend.c:886 #4 0x40bd3204 in php_execute_script (primary_file=0x40e35800, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/main/main.c:1731 #5 0x40c1b609 in php_ns_module_main (tsrm_ls=Variable "tsrm_ls" is not available. ) at /root/php4-STABLE-200404150030/sapi/aolserver/aolserver.c:419 #6 0x40c1b985 in php_ns_request_handler (context=0x80c7698, conn=Variable "conn" is not available. ) at /root/php4-STABLE-200404150030/sapi/aolserver/aolserver.c:503 #7 0x4003a152 in Ns_ConnRunRequest () from /usr/local/aolserver/lib/libnsd.so #8 0x4003b9d6 in ConnRun () from /usr/local/aolserver/lib/libnsd.so #9 0x4003b660 in NsConnThread () from /usr/local/aolserver/lib/libnsd.so #10 0x40067c18 in NsThreadMain () from /usr/local/aolserver/lib/libnsthread.so #11 0x4006914a in ThreadMain () from /usr/local/aolserver/lib/libnsthread.so #12 0x401227d3 in start_thread () from /lib/tls/libpthread.so.0 #13 0x4023ab4a in clone () from /lib/tls/libc.so.6 [2004-04-14 22:28:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip ..and configure PHP with --enable debug and get us a proper backtrace (with GDB command 'bt') [2004-04-14 22:11:27] ustaz99 at catcha dot com Description: entering username=apache password=apache make my aolserver crash with phpPgAdmin-3.3.1 './configure' '--with-aolserver=/usr/local/aolserver/' '--with-pgsql' # aolserver-4.01 # php-4.3.5 Reproduce code: --- entering success login phpPgAdmin-3.3.1 script Expected result: (gdb) r -f -t /usr/local/aolserver/bin/config.tcl -u apache -g apache Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1088555952 (LWP 3368)] 0x40c00d60 in execute (op_array=0x81e33a4, tsrm_ls=0x80c7390) at /root/php-4.3.5/Zend/zend_execute.c:1252 1252 zend_fetch_var_address(EX(opline), EX(Ts), BP_VAR_W TSRMLS_CC); (gdb) i r eax0x80c7390
#28016 [NEW]: is_resource() returns false for resources of type "Unknown"
From: php at ter dot dk Operating system: Linux 2.4.17 PHP version: 4.3.6RC3 PHP Bug Type: Unknown/Other Function Bug description: is_resource() returns false for resources of type "Unknown" Description: (version of PHP is 4.3.6, not 4.3.6RC3, but I wasn't able to select that) If a resource for some reason is of type "Unknown", is_resource() returns false. Though, gettype() still returns "resource" as type, as always. This behaviour in is_resource() has changed between 4.3.5 and 4.3.6. I'm guessing here, but the new behaviour could be related to changes introduced to fix bug 27822 (which was fixed in between 4.3.5 and 4.3.6). In my example I'm using php-imlib to gain an object of type "Unknown". Even though it isn't an official extension, there still is some inconsistency between gettype() returning "resource" and is_resource() returning false. In other words, it's the inconsistency between is_resource() and gettype() I see as the bug. Example is also available at: http://stock.ter.dk/resource_error.php Reproduce code: --- $i = imlib_create_image(100,200); var_dump($i); var_dump(gettype($i)); var_dump(is_resource($i)); Expected result: resource(2) of type (Unknown) string(8) "resource" bool(true) Actual result: -- resource(2) of type (Unknown) string(8) "resource" bool(false) -- Edit bug report at http://bugs.php.net/?id=28016&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28016&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28016&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28016&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28016&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28016&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28016&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28016&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28016&r=support Expected behavior: http://bugs.php.net/fix.php?id=28016&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28016&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28016&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28016&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28016&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28016&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28016&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28016&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28016&r=float
#24426 [Com]: Apache Installation Doesn't Work
ID: 24426 Comment by: callenstc at hotmail dot com Reported By: LouisGreen at pljg dot freeserve dot co dot uk Status: Bogus Bug Type: Apache related Operating System: Windows XP Pro PHP Version: 5.0.0b1 (beta1) New Comment: I had luck by simply changing the top PHP folder to c:\php. then it magically worked!!! so in your case move c:\apache2\PHP5 stuff all to c:\php update everything to match including extensions in php.ini if necessary Previous Comments: [2003-07-06 02:29:25] psycode at adsl dot on dot net I had the exact same problem with both the latest versions of apache (1 and 2) and php 4 and 5. THERE IS A FIX! For some reason, apache cannot find any non-.so files. No idea why, don't know if this was intentional. If you rename the sapi dll to .so, and update the httpd.conf as such, then it will detect it and work fine. I don't know whos fault this is. If this is a permament change in apache, something should be put in the docs for php at least. [2003-07-01 04:56:10] igor at design dot rv dot ua I've been tried to install php_5.0.0 beta1 under Windows XP Pro with Sp1 platform. Apache ver 1.3.6 I recieved one error, I can't fix it : -- Syntax error on line 181 of "..."/apache/conf/httpd.conf Can't locate API module structure 'php4_module' in file "..."/php4apache.dll The filename, directory name, or volume id label syntax is incorrect. -- #181 httpd.conf : LoadModule php4_module "..."/php4apache.dll -- All about path's and need_2_load modules -- okey. [2003-06-30 18:06:28] [EMAIL PROTECTED] If you had bothered to search the bug database, you'd know the answer already. Don't bother reopening, you're just wasting our time. [2003-06-30 18:04:38] LouisGreen at pljg dot freeserve dot co dot uk php4apache2.dll php4apache.dll Is this not bundled as part PHP, because it fuses to work. The bundled instructions are only for PHP 4, not 5. I could spend time going thought dozens of news groups / forums and mailing list, looking for the answer, may even spend days chasing a wide goose. If there is ever likely a chance for a Windows Apache user to try/ debug PHP5, could u or somone please point me to some where more specific where I can get answer. Thanks [2003-06-30 17:53:53] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . 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/24426 -- Edit this bug report at http://bugs.php.net/?id=24426&edit=1
#27693 [Bgs]: imagettftext() coupled with imagecreatetruecolor() displays yellow fonts.
ID: 27693 Updated by: [EMAIL PROTECTED] Reported By: xavier dot blanchet at free dot fr Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 4.3.4 New Comment: "On Linux I cannot try the latest version before my hoster (OVH.com) has migrated :-( But as I have already mentionned the beta version PHP5 (http://240plan.ovh.net/test.beta )returns these same yellow fonts." "FreeType Version 1.3"... just forget it sorry. Then even when they upgrade it (in some servers, as I got one) it was the version "2.0", with which gd has some bugs with rotated text. I used a dedicated server there, so I upgraded myself to a recent version (2.1.7). Everything is fine since. So please keep this bug quiet and ask support questions on the right list (ie, php-install) or beg your ISP to upgrade to a recent freetype. hth pierre Previous Comments: [2004-04-15 20:35:16] cartoonlad at thesnakefarm dot com So for those of us who are muddling around with configuring php for the first time, what does that mean? Use --enable-gd-native-ttf in the configure? [2004-04-05 11:01:35] [EMAIL PROTECTED] ttf = freetype 1, old and buggy freetype = freetype 2, new, not buggy So just compile PHP against the newer version, not a bug -> bogus. [2004-04-05 09:56:18] xavier dot blanchet at free dot fr For me on Windows, it all works fine. On Linux I cannot try the latest version before my hoster (OVH.com) has migrated :-( But as I have already mentionned the beta version PHP5 ( http://240plan.ovh.net/test.beta )returns these same yellow fonts. However I noticed something interessting: each time i met someone in forums, newsgroups... experiencing the same problem, the FreeType Linkage in the phpinfo() was with "TTF Library". "with FreeType" is ok... [2004-04-03 09:51:00] [EMAIL PROTECTED] I can't reproduce either with PHP 4.2.6RC2-dev. I think the problem may be only with Unicode fonts, althought it works for me. [2004-04-01 11:56:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I am still unable to replicate the problem using the Arial ttf font avaliable on my system. Please include your configure line in your reply. 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/27693 -- Edit this bug report at http://bugs.php.net/?id=27693&edit=1
#28008 [Bgs->Opn]: apache 2 and php4 child segfaults when accessing php pages
ID: 28008 User updated by: dzila at tassadar dot physics dot auth dot gr -Summary: apache 2 and php4 child segfauls when accessing php pages Reported By: dzila at tassadar dot physics dot auth dot gr -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Slackware 8 , kernel 2.4.25 PHP Version: 4CVS-2004-04-15 (stable) New Comment: I have installed gdb 6 which provides some more info , not sure if it is of any use gdb ./httpd GNU gdb 6.0 Copyright 2003 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x082e1ca0 in ?? () (gdb) bt #0 0x082e1ca0 in ?? () #1 0x405e9e1e in db_open () from /lib/libnss_db.so.2 #2 0x405e9ed0 in internal_setent () from /lib/libnss_db.so.2 #3 0x405e962e in _nss_db_endservent () from /lib/libnss_db.so.2 #4 0x405e98c3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2 #5 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #6 0x40386771 in getservbyname () from /lib/libc.so.6 #7 0x4056c3bf in mysql_once_init () from /disk2/daemons/mysql/lib/mysql/libmysqlclient.so.12 #8 0x4056eeb4 in mysql_init () from /disk2/daemons/mysql/lib/mysql/libmysqlclient.so.12 #9 0x403fe0a6 in php_mysql_do_connect (ht=3, return_value=0x81c8444, this_ptr=0x0, return_value_used=1, persistent=0) at /disk2/builder/web2/php4-STABLE-200404151230/ext/mysql/php_mysql.c:771 #10 0x403fe3c5 in zif_mysql_connect (ht=3, return_value=0x81c8444, this_ptr=0x0, return_value_used=1) at /disk2/builder/web2/php4-STABLE-200404151230/ext/mysql/php_mysql.c:827 #11 0x405128e2 in execute (op_array=0x82c091c) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1635 #12 0x40512b2c in execute (op_array=0x82b1264) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #13 0x40512b2c in execute (op_array=0x81df2b8) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #14 0x40512b2c in execute (op_array=0x81dda08) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #15 0x40512b2c in execute (op_array=0x81be10c) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend_execute.c:1679 #16 0x404ff484 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /disk2/builder/web2/php4-STABLE-200404151230/Zend/zend.c:886 #17 0x404c310c in php_execute_script (primary_file=0xb61c) at /disk2/builder/web2/php4-STABLE-200404151230/main/main.c:1731 #18 0x4051939c in php_handler (r=0x81b0ef0) at /disk2/builder/web2/php4-STABLE-200404151230/sapi/apache2handler/sapi_apache2.c:561 #19 0x08097929 in ap_run_handler (r=0x81b0ef0) at config.c:151 #20 0x08097e73 in ap_invoke_handler (r=0x81b0ef0) at config.c:358 #21 0x08087a76 in ap_process_request (r=0x81b0ef0) at http_request.c:246 #22 0x0808393a in ap_process_http_connection (c=0x81acec0) at http_core.c:250 #23 0x080a0e88 in ap_run_process_connection (c=0x81acec0) at connection.c:42 #24 0x080a115c in ap_process_connection (c=0x81acec0, csd=0x81acde8) at connection.c:175 #25 0x080965b0 in child_main (child_num_arg=0) at prefork.c:609 #26 0x0809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #27 0x08096761 in startup_children (number_to_start=5) at prefork.c:721 #28 0x08096a63 in ap_mpm_run (_pconf=0x80dc270, plog=0x8114350, s=0x80df138) at prefork.c:940 ---Type to continue, or q to quit--- #29 0x0809c26e in main (argc=2, argv=0xba04) at main.c:617 Previous Comments: [2004-04-15 20:26:36] [EMAIL PROTECTED] Oh...then your slackware 8 system is broken.. [2004-04-15 20:18:22] dzila at tassadar dot physics dot auth dot gr thanks for your reply sniper , can you be a bit more specific ? I have repeated the same process step by step on another system (slackware 9 ) with the same sources , and it works ok there. I have copied the exact same httpd.conf file. thanks for the help again :) [2004-04-15 19:15:54] [EMAIL PROTECTED] You have misconfigured PHP in the httpd.conf. Please ask support questions elsewhere. [2004-04-15 10:43:21] dzila at tassadar dot physics dot auth dot gr Description: I am compiling apache2 and php for the first time
#27693 [Com]: imagettftext() coupled with imagecreatetruecolor() displays yellow fonts.
ID: 27693 Comment by: cartoonlad at thesnakefarm dot com Reported By: xavier dot blanchet at free dot fr Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 4.3.4 New Comment: So for those of us who are muddling around with configuring php for the first time, what does that mean? Use --enable-gd-native-ttf in the configure? Previous Comments: [2004-04-05 11:01:35] [EMAIL PROTECTED] ttf = freetype 1, old and buggy freetype = freetype 2, new, not buggy So just compile PHP against the newer version, not a bug -> bogus. [2004-04-05 09:56:18] xavier dot blanchet at free dot fr For me on Windows, it all works fine. On Linux I cannot try the latest version before my hoster (OVH.com) has migrated :-( But as I have already mentionned the beta version PHP5 ( http://240plan.ovh.net/test.beta )returns these same yellow fonts. However I noticed something interessting: each time i met someone in forums, newsgroups... experiencing the same problem, the FreeType Linkage in the phpinfo() was with "TTF Library". "with FreeType" is ok... [2004-04-03 09:51:00] [EMAIL PROTECTED] I can't reproduce either with PHP 4.2.6RC2-dev. I think the problem may be only with Unicode fonts, althought it works for me. [2004-04-01 11:56:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I am still unable to replicate the problem using the Arial ttf font avaliable on my system. Please include your configure line in your reply. [2004-04-01 07:47:13] xavier dot blanchet at free dot fr I was hoping PHP 4.3.5 would resolve the bug, but as I tried the same script on PHP Version 5.0.0b2 Beta ( http://240plan.ovh.net/test.beta ) and faced the same problem, i did not believe in a PHP version 4.3.5 working fine with ttf fonts... According to Sandeep, I was right :-( 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/27693 -- Edit this bug report at http://bugs.php.net/?id=27693&edit=1
#26608 [Asn]: Sporadic -439 errors on ifx_connect()
ID: 26608 User updated by: gemery at bmihs dot co dot uk Reported By: gemery at bmihs dot co dot uk Status: Assigned Bug Type: Informix related Operating System: RedHat Linux 8 PHP Version: 4.3.3 Assigned To: nobbie New Comment: By the way, if you know anyone that has suffered this problem, get them to vote on it. Maybe it'll get bumped up the priority list :-/ Previous Comments: [2004-04-15 20:29:00] gemery at bmihs dot co dot uk OK... Some new information: I got in contact with Cornelius, the maintainer of the ifx code. He came up with the following (which is a work in progress): -439 error:Description:Each Apache Thread can only have 1 active connection to an informix database, after a -439 occurance. o ifx_close() doesn't close the database connection, possibly leaving it available for other requests - Fixed in PHP-4.3.4 (after RC1) o ifx_close() can't close connections which produced -439 errors - Looks like a bug (or feature) in the ESQL/C or IDS Engine, or incorrect thread usageReproduce bug:o in httpd.conf, set MaxRequestsPerChild to 1o access a php script which runs a massive queryo you'll keep getting -439 errors===TEMPORARY FIX===Because the -439 error causes problems for Apache/PHP to reconnect in each thread, the thread should be closed often to kill the conection which is the problem.This doesn't prevent the problem, but makes it occur less, and not affect as many users when it does.In httpd.conf: o Set MaxRequestsPerChild to a low number (approx: the minimum number of possible connections in a request to your site, maybe times 3) o Set MaxKeepAliveRequests to a low number (see above)---===HACKING INFO===Things to check: o if ifx_close closes connection when -439 is encountered:- NOo why -439 is encountered on new connection attempt, in same apache thread after first -439:- Possible Runaway process - incorrect thread usage o if -439 is encountered immediately from same apache thread, different request, if first request has -439 set:- YESThings to try: o ESQL/C thread safe stuff - Didn't work for me o check error -451, from the release docsfrom /opt/informix/release/en_us/0333/ESQLCREL_9.1:92103 With arrary fetch enabled frontend doesn't recover from-451 error but returns -439 error for all subsequentoperations - Doubtedly, becuase the tests failed without blobs in sight I have also upgraded our apache server to version 2 (2.0.49) and this seems to have made the problem go away entirely (possibly because it handles threading in a proper way - which seems to be the root cause of the 439 issue). Hope this helps. Some more news from the php devs would be appreciated though :) [2004-04-14 13:04:30] p_lc at voila dot fr Same problem for us after Php4 migration two weeks ago. Last version of PHP4, last version of Informix sdk. And same problems in a critical application. Even the rotation of informix users described in #14254 didn't changed anything. Strange, though, because we didn't saw anything similar in php3. Shall we downgrade our server ? Thank you for your help. [2004-04-13 09:35:36] cass at surek dot com dot br We're running into the same problem here, but unfortunatelly we don't have an option of switching to another database as the other fellow did. Can we expect anything regarding this matter? [2004-02-09 05:43:33] gemery at bmihs dot co dot uk I'm afraid that due to excessive downtime we've been forced to move away from php for the next version of our casetracking software :( The boss pulled the plug and insisted we move to jsps instead. A sad day. Thanks for a great product (apart from the unfortunate Informix issue). Maybe if we change db we might move back to php. [2004-01-12 07:04:33] [EMAIL PROTECTED] Assigned to the ext/informix maintainer, Corne'. 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/26608 -- Edit this bug report at http://bugs.php.net/?id=26608&edit=1
#26608 [Asn]: Sporadic -439 errors on ifx_connect()
ID: 26608 User updated by: gemery at bmihs dot co dot uk Reported By: gemery at bmihs dot co dot uk Status: Assigned Bug Type: Informix related Operating System: RedHat Linux 8 PHP Version: 4.3.3 Assigned To: nobbie New Comment: OK... Some new information: I got in contact with Cornelius, the maintainer of the ifx code. He came up with the following (which is a work in progress): -439 error:Description:Each Apache Thread can only have 1 active connection to an informix database, after a -439 occurance. o ifx_close() doesn't close the database connection, possibly leaving it available for other requests - Fixed in PHP-4.3.4 (after RC1) o ifx_close() can't close connections which produced -439 errors - Looks like a bug (or feature) in the ESQL/C or IDS Engine, or incorrect thread usageReproduce bug:o in httpd.conf, set MaxRequestsPerChild to 1o access a php script which runs a massive queryo you'll keep getting -439 errors===TEMPORARY FIX===Because the -439 error causes problems for Apache/PHP to reconnect in each thread, the thread should be closed often to kill the conection which is the problem.This doesn't prevent the problem, but makes it occur less, and not affect as many users when it does.In httpd.conf: o Set MaxRequestsPerChild to a low number (approx: the minimum number of possible connections in a request to your site, maybe times 3) o Set MaxKeepAliveRequests to a low number (see above)---===HACKING INFO===Things to check: o if ifx_close closes connection when -439 is encountered:- NOo why -439 is encountered on new connection attempt, in same apache thread after first -439:- Possible Runaway process - incorrect thread usage o if -439 is encountered immediately from same apache thread, different request, if first request has -439 set:- YESThings to try: o ESQL/C thread safe stuff - Didn't work for me o check error -451, from the release docsfrom /opt/informix/release/en_us/0333/ESQLCREL_9.1:92103 With arrary fetch enabled frontend doesn't recover from-451 error but returns -439 error for all subsequentoperations - Doubtedly, becuase the tests failed without blobs in sight I have also upgraded our apache server to version 2 (2.0.49) and this seems to have made the problem go away entirely (possibly because it handles threading in a proper way - which seems to be the root cause of the 439 issue). Hope this helps. Some more news from the php devs would be appreciated though :) Previous Comments: [2004-04-14 13:04:30] p_lc at voila dot fr Same problem for us after Php4 migration two weeks ago. Last version of PHP4, last version of Informix sdk. And same problems in a critical application. Even the rotation of informix users described in #14254 didn't changed anything. Strange, though, because we didn't saw anything similar in php3. Shall we downgrade our server ? Thank you for your help. [2004-04-13 09:35:36] cass at surek dot com dot br We're running into the same problem here, but unfortunatelly we don't have an option of switching to another database as the other fellow did. Can we expect anything regarding this matter? [2004-02-09 05:43:33] gemery at bmihs dot co dot uk I'm afraid that due to excessive downtime we've been forced to move away from php for the next version of our casetracking software :( The boss pulled the plug and insisted we move to jsps instead. A sad day. Thanks for a great product (apart from the unfortunate Informix issue). Maybe if we change db we might move back to php. [2004-01-12 07:04:33] [EMAIL PROTECTED] Assigned to the ext/informix maintainer, Corne'. [2003-12-17 09:57:25] gemery at bmihs dot co dot uk OK.. Having the installed the new sdk and the snapshot (as suggested), the system ran fine for two days. On the third day, these three errors occurred: [error] PHP Warning: ifx_query(): Set connection connec83 fails (E [SQLSTATE=IX 000 SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0 [error] PHP Warning: ifx_query(): Set connection connec80 fails (E [SQLSTATE=IX 000 SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0 [error] PHP Warning: ifx_query(): Set connection connec1 fails (E [SQLSTATE=IX 000 SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on
#28008 [Opn->Bgs]: apache 2 and php4 child segfauls when accessing php pages
ID: 28008 Updated by: [EMAIL PROTECTED] Reported By: dzila at tassadar dot physics dot auth dot gr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Slackware 8 , kernel 2.4.25 PHP Version: 4CVS-2004-04-15 (stable) New Comment: Oh...then your slackware 8 system is broken.. Previous Comments: [2004-04-15 20:18:22] dzila at tassadar dot physics dot auth dot gr thanks for your reply sniper , can you be a bit more specific ? I have repeated the same process step by step on another system (slackware 9 ) with the same sources , and it works ok there. I have copied the exact same httpd.conf file. thanks for the help again :) [2004-04-15 19:15:54] [EMAIL PROTECTED] You have misconfigured PHP in the httpd.conf. Please ask support questions elsewhere. [2004-04-15 10:43:21] dzila at tassadar dot physics dot auth dot gr Description: I am compiling apache2 and php for the first time. Every time a php page is accessed the apache child segfaults and no php page can be displayed. I tried with 4.3.5 and the latest 4 snap.Non php pages work fine /configure --with-apxs2=/disk2/daemons/www2/bin/apxs --with-openssl --enable-cli --enable-ftp --with-zlib --with-zip --with-mysql=/disk2/daemons/mysql --enable-debug (also tried only with-apxs and no other options , --with-mysql on its on, same results) I am launching apache2 because I want ipv6 enabled web server , I tried binding it to both ipv6 and ipv4 addresses with same results Reproduce code: --- a postnuke site which works ok with apache 1.3 Actual result: -- gdb ./httpd GNU gdb 5.0 Copyright 2000 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/./httpd -X warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x82e3d76 in ?? () (gdb) bt #0 0x82e3d76 in ?? () #1 0x405e9ed0 in ?? () #2 0x405e962e in ?? () #3 0x405e98c3 in ?? () #4 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #5 0x40386771 in getservbyname () from /lib/libc.so.6 #6 0x4056c3bf in ?? () #7 0x4056eeb4 in ?? () #8 0x403fe0a6 in ?? () #9 0x403fe3c5 in ?? () #10 0x405128e2 in ?? () #11 0x40512b2c in ?? () #12 0x40512b2c in ?? () #13 0x40512b2c in ?? () #14 0x40512b2c in ?? () #15 0x404ff484 in ?? () #16 0x404c310c in ?? () #17 0x4051939c in ?? () #18 0x8097929 in ap_run_handler (r=0x81b2f80) at config.c:151 #19 0x8097e73 in ap_invoke_handler (r=0x81b2f80) at config.c:358 #20 0x8087a76 in ap_process_request (r=0x81b2f80) at http_request.c:246 #21 0x808393a in ap_process_http_connection (c=0x81aef50) at http_core.c:250 #22 0x80a0e88 in ap_run_process_connection (c=0x81aef50) at connection.c:42 #23 0x80a115c in ap_process_connection (c=0x81aef50, csd=0x81aee78) at connection.c:175 #24 0x80965b0 in child_main (child_num_arg=0) at prefork.c:609 #25 0x809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #26 0x8096761 in startup_children (number_to_start=5) at prefork.c:721 #27 0x8096a63 in ap_mpm_run (_pconf=0x80dc270,plog=0x8114350, s=0x80df138)at prefork.c:940 #28 0x809c26e in main (argc=2, argv=0xba04) at ain.c:617 #29 0x402c82eb in __libc_start_main () from /lib/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=28008&edit=1
#28008 [Bgs->Opn]: apache 2 and php4 child segfauls when accessing php pages
ID: 28008 User updated by: dzila at tassadar dot physics dot auth dot gr Reported By: dzila at tassadar dot physics dot auth dot gr -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Slackware 8 , kernel 2.4.25 PHP Version: 4CVS-2004-04-15 (stable) New Comment: thanks for your reply sniper , can you be a bit more specific ? I have repeated the same process step by step on another system (slackware 9 ) with the same sources , and it works ok there. I have copied the exact same httpd.conf file. thanks for the help again :) Previous Comments: [2004-04-15 19:15:54] [EMAIL PROTECTED] You have misconfigured PHP in the httpd.conf. Please ask support questions elsewhere. [2004-04-15 10:43:21] dzila at tassadar dot physics dot auth dot gr Description: I am compiling apache2 and php for the first time. Every time a php page is accessed the apache child segfaults and no php page can be displayed. I tried with 4.3.5 and the latest 4 snap.Non php pages work fine /configure --with-apxs2=/disk2/daemons/www2/bin/apxs --with-openssl --enable-cli --enable-ftp --with-zlib --with-zip --with-mysql=/disk2/daemons/mysql --enable-debug (also tried only with-apxs and no other options , --with-mysql on its on, same results) I am launching apache2 because I want ipv6 enabled web server , I tried binding it to both ipv6 and ipv4 addresses with same results Reproduce code: --- a postnuke site which works ok with apache 1.3 Actual result: -- gdb ./httpd GNU gdb 5.0 Copyright 2000 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/./httpd -X warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x82e3d76 in ?? () (gdb) bt #0 0x82e3d76 in ?? () #1 0x405e9ed0 in ?? () #2 0x405e962e in ?? () #3 0x405e98c3 in ?? () #4 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #5 0x40386771 in getservbyname () from /lib/libc.so.6 #6 0x4056c3bf in ?? () #7 0x4056eeb4 in ?? () #8 0x403fe0a6 in ?? () #9 0x403fe3c5 in ?? () #10 0x405128e2 in ?? () #11 0x40512b2c in ?? () #12 0x40512b2c in ?? () #13 0x40512b2c in ?? () #14 0x40512b2c in ?? () #15 0x404ff484 in ?? () #16 0x404c310c in ?? () #17 0x4051939c in ?? () #18 0x8097929 in ap_run_handler (r=0x81b2f80) at config.c:151 #19 0x8097e73 in ap_invoke_handler (r=0x81b2f80) at config.c:358 #20 0x8087a76 in ap_process_request (r=0x81b2f80) at http_request.c:246 #21 0x808393a in ap_process_http_connection (c=0x81aef50) at http_core.c:250 #22 0x80a0e88 in ap_run_process_connection (c=0x81aef50) at connection.c:42 #23 0x80a115c in ap_process_connection (c=0x81aef50, csd=0x81aee78) at connection.c:175 #24 0x80965b0 in child_main (child_num_arg=0) at prefork.c:609 #25 0x809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #26 0x8096761 in startup_children (number_to_start=5) at prefork.c:721 #27 0x8096a63 in ap_mpm_run (_pconf=0x80dc270,plog=0x8114350, s=0x80df138)at prefork.c:940 #28 0x809c26e in main (argc=2, argv=0xba04) at ain.c:617 #29 0x402c82eb in __libc_start_main () from /lib/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=28008&edit=1
#28015 [NEW]: HTTP POST file uploads do not give error when canceled
From: kevin_winahradsky at hotmail dot com
Operating system: Linux 2.4.18
PHP version: 5.0.0RC1
PHP Bug Type: HTTP related
Bug description: HTTP POST file uploads do not give error when canceled
Description:
When doing an HTTP POST upload of a file, if the upload is canceled by
closing the browser, $_FILES['userfile']['error'] will be equal to
UPLOAD_ERR_OK.
Reproduce code:
---
" . $_FILES['userfile']['error']);
error_log("completed!");
}
?>
Expected result:
I would expect $_FILES['userfile']['error'] to be set to
UPLOAD_ERR_PARTIAL.
Actual result:
--
$_FILES['userfile']['error'] is set to UPLOAD_ERR_OK.
--
Edit bug report at http://bugs.php.net/?id=28015&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28015&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28015&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28015&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28015&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28015&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28015&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28015&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28015&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28015&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28015&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28015&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28015&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28015&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28015&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28015&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28015&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28015&r=float
#28014 [Bgs]: attached files are missing bytes
ID: 28014 User updated by: josh at jamisonadvertising dot com Reported By: josh at jamisonadvertising dot com Status: Bogus Bug Type: *Mail Related Operating System: Red Hat PHP Version: 4.3.4 New Comment: OK - well I found the problem. magic_quotes_runtime I'll post something in the mail() function. Previous Comments: [2004-04-15 18:36:25] josh at jamisonadvertising dot com OK - I'll try that. Thank you for a much more helpful suggestion than the last one. [2004-04-15 18:31:15] [EMAIL PROTECTED] I'm sorry you're having problems, but it's really a lot of work to download software and create test cases for bug reports. (It's not like we write those classes and we get lots of bugs each day.) Why don't you report the problem to the authors of the mail class and see if they can reproduce it? If they can, they will be able to generate a PHP bug report that makes it easier for us to fix the problem. [2004-04-15 18:24:40] josh at jamisonadvertising dot com Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit this bug report at http://bugs.php.net/?id=28014&edit=1
#27986 [Opn->Ver]: make errors still persist
ID: 27986 Updated by: [EMAIL PROTECTED] Reported By: sandduneinfo at earthlink dot net -Status: Open +Status: Verified Bug Type: Compile Failure Operating System: AIX 5.1 -PHP Version: 4.3.5 +PHP Version: 4CVS, 5CVS (2004-04-16) New Comment: Nevermind, I'll add the trimmed down paste myself: (note: you don't need to do anything now, we'll let you know when this is fixed) Errors as follows: "/tmp/php4-STABLE-200404150030/ext/standard/array.c", line 1723.64: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/ext/standard/file.c", line 918.100: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/ext/standard/file.c", line 924.114: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/ext/standard/info.c", line 480.122: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/main/safe_mode.c", line 84.31: 1506-280 (W) Function argument assignment between types "unsigned char*" and "const unsigned char*" is not allowed. "/tmp/php4-STABLE-200404150030/main/safe_mode.c", line 125.39: 1506-280 (W) Function argument assignment between types "unsigned char*" and "const unsigned char*" is not allowed. Previous Comments: [2004-04-13 23:39:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Apparently we missed some places..So please try the latest stable snapshot and show us all the errors with current line numbers. [2004-04-13 22:12:06] sandduneinfo at earthlink dot net Description: I was able to install apache 2.0.49 it seems to be working OK. I went to install php 4.3.5 with the apxs and the mysql flags using the AIX Ansi c compiler I listed out much of the error in make below and of course the make install fails big time. I do have mysql version 4.0.17 and I have been accessing it with perl and DBD/DBI. I have run the make cklean and retired, I have also deleted the the php install directory and "retarred" it back. It complained in configure originally about flex and bison missing in configure originally and I added those in on download from IBM website and installed with rpm. So those issues went away. I noticed something about 4.3.5 was supposed to fix unsigned int errors - are their more. I am not a C programmer - which leaves me more in the dark. HELP! Dan Rizzi Expected result: Additional make errors ... cc: 1501-218 file Zend/zend_llist.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_opcode.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_operators.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_ptr_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_variables.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_API.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_extensions.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_hash.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_list.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_indent.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_builtin_functions.lo contains an incorrect file suff ix Actual result: -- "/tmp/php/php-4.3.5/ext/standard/array.c", line 1723.64: 1506-280 (W) Function a rgument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 918.100: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 924.114: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2308.13: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2373.29: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/info.c", line 480.122: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 84.31: 1506-
#27741 [Com]: IIS down while request .php file
ID: 27741 Comment by: jeronimo at solus dot com dot ar Reported By: yjt at 5kg dot net Status: Closed Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.5 New Comment: got the same problem, it seemed to dissapear when i turn off error messaging and activated the log file (not the event viewer) didn't install any patch (im running 4.3.5 release) Previous Comments: [2004-04-08 08:18:06] tom at cliksoftware dot com I got this error again, using IIS/Win2k Server/PHP (ISAPI) 4.3.6RC3_dev - are you sure its completely fixed? [2004-04-08 05:16:29] cash at ourupgrade dot dot net I have the same problem, it makes IIS down, and all website can not be accessed. Now I use 4.3.6 rc3, it fix this problem. [2004-04-04 15:24:42] [EMAIL PROTECTED] 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. [2004-04-04 15:19:22] robert at shilston dot com I downloaded the 4.3.5 zip package for windows, and am running as ISAPI on Windows XP Pro sp1. Every few page loads, "Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0" (page itself is ""). [2004-04-04 00:36:13] jaw959 at new dot rr dot com I'm getting this bug... I was upgrading PHP from 4.3.4 to 4.3.5. I'm not loading any additional extensions, and I used the same .ini file as with 4.3.4. I completely wiped out the C:\PHP files, and then loaded in the new ones (and made a new copy of php4ts.dll to system32). Now, all of a sudden, I get Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0. Warning: Unknown list entry type in request shutdown (2) in C:\Inetpub\wwwroot\index.php on line 2 Then, dllhost gets a memory error, and all .php scripts on my website give this error: "The remote procedure call failed and did not execute." Shortly after, it works again, and then shortly after that I get the warnings again, and then it continues in the cycle of normal operation, warnings, and RPC failing. If you have any ideas, please let me know. 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/27741 -- Edit this bug report at http://bugs.php.net/?id=27741&edit=1
#28006 [Opn->Fbk]: referencing an unset global produces a segfault
ID: 28006
Updated by: [EMAIL PROTECTED]
Reported By: per at computer dot org
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.24
PHP Version: 4.3.4
New Comment:
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 ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Previous Comments:
[2004-04-15 10:43:38] per at computer dot org
Here's the backtrace when doing the same thing with
php4-STABLE-200404151030
(gdb) run -X -f /etc/httpd/httpd.conf
Starting program: /usr/bin/httpd -X -f /etc/httpd/
httpd.conf
[New Thread 16384 (LWP 18823)]
[Thu Apr 15 16:35:42 2004] [warn] module php4_module is
already loaded, skipping
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 18823)]
0x40578b32 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute_API.c:271
271 return active_opline->lineno;
(gdb) bt
#0 0x40578b32 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute_API.c:271
#1 0x405811bd in zend_error (type=8, format=0x40709bff
"Undefined index: %s") at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/Zend/zend.c:733
#2 0x40593a80 in zend_fetch_dimension_address_inner
(ht=0x81d2d2c, op2=0x8226540, Ts=0xbfffaa7c, type=0) at /
usr/src/packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute.c:645
#3 0x4058cba0 in zend_fetch_dimension_address
(result=0x8226520, op1=0x82061bc, op2=0x8226540,
Ts=0xbfffaa7c, type=0) at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/Zend/zend_execute.c:801
#4 0x40591dbe in execute (op_array=0x81e932c) at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute.c:1297
#5 0x4058130b in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/Zend/zend.c:886
#6 0x40554fcf in php_execute_script
(primary_file=0xb3f0) at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/main/main.c:1731
#7 0x40594ae4 in php_handler (r=0x81c17e8) at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/sapi/
apache2handler/sapi_apache2.c:561
#8 0x08092d85 in ap_run_handler (r=0x81c17e8) at
config.c:151
#9 0x08093390 in ap_invoke_handler (r=0x81c17e8) at
config.c:358
#10 0x08076edb in ap_process_request (r=0x81c17e8) at
http_request.c:246
#11 0x0807239d in ap_process_http_connection (c=0x81b4fd8)
at http_core.c:250
#12 0x0809de25 in ap_run_process_connection (c=0x81b4fd8)
at connection.c:42
#13 0x08091384 in child_main (child_num_arg=148) at
prefork.c:609
#14 0x0809159b in make_child (s=0x0, slot=0) at
prefork.c:649
#15 0x080915f8 in startup_children (number_to_start=5) at
prefork.c:721
#16 0x08091e6a in ap_mpm_run (_pconf=0x80d6310,
plog=0x8116410, s=0x80d9dd0) at prefork.c:940
#17 0x080983bd in main (argc=4, argv=0xb764) at
main.c:617
[2004-04-15 07:44:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-04-15 07:36:22] per at computer dot org
Description:
Hi,
I've got a situation where a seemingly innocent statement
produces a
segfault. I've tried reducing it to a single reproducable
testcase, but
without
success. The problem is however solidly reproducable in the
context in which it occurs.
I'm certain it is caused by a mistake in my code, but I
feel it isn't
exactly appropriate for php to segfault because of a user
error?
Very briefly, this is an excerpt where the segfault occurs:
";
$result=mysql_query( $q ) or die("mysql:".mysql_error());
$main_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$billing_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$technical_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$editmain=strcasecmp($_REQUEST['contact'],"main")==0;
//
$editbilling=strcasecmp($_REQUEST['contact'],"billing")==0;
//
$edittechnical=strcasecmp($_REQUEST['con
#28012 [Csd]: spprintf() output inconsistent for %p (fix included)
ID: 28012 User updated by: php-lists at nomeaning dot net Reported By: php-lists at nomeaning dot net Status: Closed Bug Type: Output Control Operating System: * PHP Version: 5.0.0RC2RC1 New Comment: Happy to help. Re: The security risk. I guess I failed to convey that my "patch" to var.c was merely to make reproducing the bug earlier for you. By no means was I suggesting putting it in CVS! (though the idea of printing pointers in var_dump() for --enable-debug mode is a good one) Previous Comments: [2004-04-15 19:09:55] [EMAIL PROTECTED] Thanks for noticing. But printing the pointers through var.c is a nice thing for debugging but is a security risk for non debug mode. [2004-04-15 19:08:11] [EMAIL PROTECTED] 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. [2004-04-15 17:23:23] php-lists at nomeaning dot net Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to [EMAIL PROTECTED] Sorry for the confusion. [2004-04-15 17:15:56] php-lists at nomeaning dot net H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28007 [Opn->Asn]: FreeTDS support will not compile
ID: 28007 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Linux PHP Version: 4.3.6RC3 -Assigned To: +Assigned To: fmk New Comment: Assigned to Frank who added the line in question in rev 1.84 of php_mssql.c Previous Comments: [2004-04-15 10:27:22] [EMAIL PROTECTED] Description: See bug #21544 -- I was asked to open a new report. ./configure --with-mssql ... works, but a make of the same fails with: (see actual result). FreeTDS version: (debian unstable) 0.53-7 Sniper mentioned that he thinks it's my FreeTDS install. Could be. The attached patch seems to completely fix the problem, though. As mentioned in the other bug: I'm not a C guy, so I could be way wrong on this. All I know is that after patching, --with-mssql compiles and the library seems to work (as) well (as mssql on linux has ever worked). S --- Index: ext/mssql/php_mssql.c === RCS file: /repository/php-src/ext/mssql/php_mssql.c,v retrieving revision 1.86.2.31 diff -u -r1.86.2.31 php_mssql.c --- ext/mssql/php_mssql.c 30 Mar 2004 17:54:38 - 1.86.2.31 +++ ext/mssql/php_mssql.c 14 Apr 2004 15:18:18 - @@ -336,7 +336,7 @@ dbsetlogintime(MS_SQL_G(connect_timeout)); if (MS_SQL_G(timeout) < 0) MS_SQL_G(timeout) = 60; dbsettime(MS_SQL_G(timeout)); - dbsetmaxprocs((SHORT)MS_SQL_G(max_procs)); + dbsetmaxprocs((int)MS_SQL_G(max_procs)); return SUCCESS; } Reproduce code: --- n/a Expected result: compile Actual result: -- ext/mssql/php_mssql.c: In function `zm_activate_mssql': ext/mssql/php_mssql.c:339: `SHORT' undeclared (first use in this function) ext/mssql/php_mssql.c:339: (Each undeclared identifier is reported only once ext/mssql/php_mssql.c:339: for each function it appears in.) make: *** [ext/mssql/php_mssql.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=28007&edit=1
#28008 [Opn->Bgs]: apache 2 and php4 child segfauls when accessing php pages
ID: 28008 Updated by: [EMAIL PROTECTED] Reported By: dzila at tassadar dot physics dot auth dot gr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Slackware 8 , kernel 2.4.25 PHP Version: 4CVS-2004-04-15 (stable) New Comment: You have misconfigured PHP in the httpd.conf. Please ask support questions elsewhere. Previous Comments: [2004-04-15 10:43:21] dzila at tassadar dot physics dot auth dot gr Description: I am compiling apache2 and php for the first time. Every time a php page is accessed the apache child segfaults and no php page can be displayed. I tried with 4.3.5 and the latest 4 snap.Non php pages work fine /configure --with-apxs2=/disk2/daemons/www2/bin/apxs --with-openssl --enable-cli --enable-ftp --with-zlib --with-zip --with-mysql=/disk2/daemons/mysql --enable-debug (also tried only with-apxs and no other options , --with-mysql on its on, same results) I am launching apache2 because I want ipv6 enabled web server , I tried binding it to both ipv6 and ipv4 addresses with same results Reproduce code: --- a postnuke site which works ok with apache 1.3 Actual result: -- gdb ./httpd GNU gdb 5.0 Copyright 2000 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/./httpd -X warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x82e3d76 in ?? () (gdb) bt #0 0x82e3d76 in ?? () #1 0x405e9ed0 in ?? () #2 0x405e962e in ?? () #3 0x405e98c3 in ?? () #4 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #5 0x40386771 in getservbyname () from /lib/libc.so.6 #6 0x4056c3bf in ?? () #7 0x4056eeb4 in ?? () #8 0x403fe0a6 in ?? () #9 0x403fe3c5 in ?? () #10 0x405128e2 in ?? () #11 0x40512b2c in ?? () #12 0x40512b2c in ?? () #13 0x40512b2c in ?? () #14 0x40512b2c in ?? () #15 0x404ff484 in ?? () #16 0x404c310c in ?? () #17 0x4051939c in ?? () #18 0x8097929 in ap_run_handler (r=0x81b2f80) at config.c:151 #19 0x8097e73 in ap_invoke_handler (r=0x81b2f80) at config.c:358 #20 0x8087a76 in ap_process_request (r=0x81b2f80) at http_request.c:246 #21 0x808393a in ap_process_http_connection (c=0x81aef50) at http_core.c:250 #22 0x80a0e88 in ap_run_process_connection (c=0x81aef50) at connection.c:42 #23 0x80a115c in ap_process_connection (c=0x81aef50, csd=0x81aee78) at connection.c:175 #24 0x80965b0 in child_main (child_num_arg=0) at prefork.c:609 #25 0x809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #26 0x8096761 in startup_children (number_to_start=5) at prefork.c:721 #27 0x8096a63 in ap_mpm_run (_pconf=0x80dc270,plog=0x8114350, s=0x80df138)at prefork.c:940 #28 0x809c26e in main (argc=2, argv=0xba04) at ain.c:617 #29 0x402c82eb in __libc_start_main () from /lib/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=28008&edit=1
#28009 [Opn->Bgs]: "make test" got hung
ID: 28009 Updated by: [EMAIL PROTECTED] Reported By: dhananjaya dot eadala at oracle dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 4.3.6RC3 New Comment: There is some bug in your system. (Not enough information given to say exactly what is wrong but I bet it's buggy glibc..) Previous Comments: [2004-04-15 11:11:10] dhananjaya dot eadala at oracle dot com when I remove the bug21523.phpt from test suite, "make test" went on fine. [2004-04-15 10:51:00] dhananjaya dot eadala at oracle dot com Description: php cli and .so was built successfully. after when I issue "make test" command, it is getting hung at running the test for ext/standard/tests/math/bug21523.phpt test. assuming it is problem with make, I ran the same test manually using php cli. still I ran to same problem of getting hung. Is there any work around for this. -- Edit this bug report at http://bugs.php.net/?id=28009&edit=1
#28013 [Opn->Bgs]: using java get*() in a switch statement
ID: 28013
Updated by: [EMAIL PROTECTED]
Reported By: pcarmody at c-spanarchives dot org
-Status: Open
+Status: Bogus
Bug Type: Java related
Operating System: Solaris 8
PHP Version: 4.3.4
New Comment:
See the other Java related bugs. (This extension is not supported
anymore)
Previous Comments:
[2004-04-15 17:35:59] pcarmody at c-spanarchives dot org
Description:
When using the auto-JavaBean style access to member variables in a
switch statement causes a core dump. Specifying the method name
directly avoids this problem.
Reproduce code:
---
Java class:
public class Blah {
private int blah;
public Blah() {
this.blah = 1;
}
public int getBlah() {
return this.blah;
}
}
PHP call:
blah ) {
case 1:
break;
}
?>
Expected result:
Exits normally.
Actual result:
--
A core dump.
If you replace $blah->blah with $blah->getBlah() the code will work
correctly.
--
Edit this bug report at http://bugs.php.net/?id=28013&edit=1
#28012 [Csd]: spprintf() output inconsistent for %p (fix included)
ID: 28012 Updated by: [EMAIL PROTECTED] Reported By: php-lists at nomeaning dot net Status: Closed Bug Type: Output Control -Operating System: linux RH 9 +Operating System: * -PHP Version: 5CVS-2004-04-15 (dev) +PHP Version: 5.0.0RC2RC1 New Comment: Thanks for noticing. But printing the pointers through var.c is a nice thing for debugging but is a security risk for non debug mode. Previous Comments: [2004-04-15 19:08:11] [EMAIL PROTECTED] 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. [2004-04-15 17:23:23] php-lists at nomeaning dot net Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to [EMAIL PROTECTED] Sorry for the confusion. [2004-04-15 17:15:56] php-lists at nomeaning dot net H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28012 [Opn->Csd]: spprintf() output inconsistent for %p (fix included)
ID: 28012 Updated by: [EMAIL PROTECTED] Reported By: php-lists at nomeaning dot net -Status: Open +Status: Closed Bug Type: Output Control Operating System: linux RH 9 PHP Version: 5CVS-2004-04-15 (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: [2004-04-15 17:23:23] php-lists at nomeaning dot net Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to [EMAIL PROTECTED] Sorry for the confusion. [2004-04-15 17:15:56] php-lists at nomeaning dot net H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28014 [Bgs]: attached files are missing bytes
ID: 28014 User updated by: josh at jamisonadvertising dot com Reported By: josh at jamisonadvertising dot com Status: Bogus Bug Type: *Mail Related Operating System: Red Hat PHP Version: 4.3.4 New Comment: OK - I'll try that. Thank you for a much more helpful suggestion than the last one. Previous Comments: [2004-04-15 18:31:15] [EMAIL PROTECTED] I'm sorry you're having problems, but it's really a lot of work to download software and create test cases for bug reports. (It's not like we write those classes and we get lots of bugs each day.) Why don't you report the problem to the authors of the mail class and see if they can reproduce it? If they can, they will be able to generate a PHP bug report that makes it easier for us to fix the problem. [2004-04-15 18:24:40] josh at jamisonadvertising dot com Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit this bug report at http://bugs.php.net/?id=28014&edit=1
#28014 [Opn->Bgs]: attached files are missing bytes
ID: 28014 Updated by: [EMAIL PROTECTED] Reported By: josh at jamisonadvertising dot com -Status: Open +Status: Bogus Bug Type: *Mail Related Operating System: Red Hat PHP Version: 4.3.4 New Comment: I'm sorry you're having problems, but it's really a lot of work to download software and create test cases for bug reports. (It's not like we write those classes and we get lots of bugs each day.) Why don't you report the problem to the authors of the mail class and see if they can reproduce it? If they can, they will be able to generate a PHP bug report that makes it easier for us to fix the problem. Previous Comments: [2004-04-15 18:24:40] josh at jamisonadvertising dot com Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit this bug report at http://bugs.php.net/?id=28014&edit=1
#28014 [NEW]: attached files are missing bytes
From: josh at jamisonadvertising dot com Operating system: Red Hat PHP version: 4.3.4 PHP Bug Type: *Mail Related Bug description: attached files are missing bytes Description: I reported this bug before, only to have one of your developers dissmiss it as bogus and an issue for PHP support which is pretty damned insulting. I would appreciate it if someone could try the referenced class file and see if they aren't able to reproduce the error. Mail sent using mail() with attached files sends the mail, but the attached file arrives with bytes missing. I believe this to be a bug because the identical code (note the usage of the word IDENTITICAL) works on a box running 4.2.3 This particular installation of PHP was compiled with: './configure' '--with-apache=../apache_1.3.29' '--with- mysql=/usr/local/mysql' '--enable-memory-limit=yes' '-- enable-debug=no' '-with-mcrypt' '--enable-ftp' '-- enable-exif' '--enable-bcmath' '--with-xml' '--with- pspell' '--with-pgsql' '--with-mhash' '--with-ming' '-- with-curl' '--with-gd' '--enable-gd-native-ttf' '-- enable-gd-imgstrttf' '--with-jpeg-dir=/usr/local/lib' '--with-png' '--with-zlib' '--with-freetype-dir=/usr/ local/include/freetype2' '--with-ttf' '--with-pdflib' '--with-tiff-dir=/usr/local/lib' Reproduce code: --- This is the second of two mail class files that produces the error on 4.3.4 or greater: http://phpmailer.sourceforge.net/ Expected result: On 4.2.3, mail will arrive with an intact attachment. On 4.3.4 or greater, the mail will arrive with an attachment with bytes missing. -- Edit bug report at http://bugs.php.net/?id=28014&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28014&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28014&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28014&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28014&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28014&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28014&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28014&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28014&r=support Expected behavior: http://bugs.php.net/fix.php?id=28014&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28014&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28014&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28014&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28014&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28014&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28014&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28014&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28014&r=float
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810
Comment by: danu at drydog dot com
Reported By: renato at galle dot com dot br
Status: Closed
Bug Type: Apache2 related
Operating System: FreeBSD-5.2.1-RELEASE-p4
PHP Version: 4.3.5
New Comment:
Here's the diffs between the old (working) version of PCRE and the new
(broken) version of PCRE. Note changes in memory allocation code, which
I believe is causing the problem:
Note: 4.3.4 works (1.29.2.3, 1.132.2.10)
Note: 4.3.5 is broken (1.29.2.5, 1.132.2.16)
diff pcre.4.3.4/config.m4 pcre.4.3.5/config.m4
2c2
< dnl $Id: config.m4,v 1.29.2.3 2003/06/29 00:08:29 andrei Exp $
---
> dnl $Id: config.m4,v 1.29.2.5 2003/12/16 22:14:55 andrei Exp $
Only in pcre.4.3.4: pcrelib
diff pcre.4.3.4/php_pcre.c pcre.4.3.5/php_pcre.c
19c19
< /* $Id: php_pcre.c,v 1.132.2.10 2003/09/12 01:32:38 sniper Exp $ */
---
> /* $Id: php_pcre.c,v 1.132.2.16 2004/02/01 19:56:16 moriyoshi Exp $
*/
108a109,117
>
> pcre_malloc = php_pcre_malloc;
> pcre_free = php_pcre_free;
>
> #ifdef NO_RECURSE
> pcre_stack_malloc = php_pcre_malloc;
> pcre_stack_free = php_pcre_free;
> #endif
>
124,133d132
< /* {{{ PHP_RINIT_FUNCTION(pcre) */
< static PHP_RINIT_FUNCTION(pcre)
< {
< pcre_malloc = php_pcre_malloc;
< pcre_free = php_pcre_free;
<
< return SUCCESS;
< }
< /* }}} */
<
177c176
< while (isspace((int)*p)) p++;
---
> while (isspace((int)*(unsigned char *)p)) p++;
186c185
< if (isalnum((int)delimiter) || delimiter == '\\') {
---
> if (isalnum((int)*(unsigned char *)&delimiter) || delimiter == '\\')
{
351c350
< int flags; /* Match
control flags */
---
> long flags; /* Match
> control flags */
365c364
< int start_offset = 0; /* Where the new
search starts */
---
> long start_offset = 0; /* Where the new
> search starts */
432c431
< int name_cnt, name_size, ni = 0;
---
> int name_cnt = 0, name_size, ni = 0;
1394a1394,1398
> case '\0':
> *q++ = '\\';
> *q++ = '0';
> break;
>
1526c1530
< PHP_RINIT(pcre),
---
> NULL
Previous Comments:
[2004-04-15 16:10:22] danu at drydog dot com
NOT fixed with php-4.3.6
I just tried this and it isn't fixed with PHP 4.3.6 either.
[2004-04-13 19:28:27] loki at arete dot cc
I also tried the latest php4 snapshot, as well as the
latest php4 release candidate, and CVS HEAD for both
php4-STABLE and php5.
None of them worked. This bug is not fixed in CVS, in
snaps, or anywhere. It's not documented as being fixed,
and the problem is still there.
I finally got fed up and took ext/pcre from php-4.3.4
and used that instead of what you shipped with php
-5.0.0rc1, and that works fine.
[2004-04-12 02:55:30] loki at arete dot cc
I just tried the latest php5 snapshot. Problem still
present.
Is it only fixed in php4 cvs?
Can you tell us what the problem actually is? There's
still no documentation of it in Changelog or in NEWS.
[2004-04-11 13:45:25] tomdkat at comcast dot net
I'm seeing this same (or similar) problem with Apache 2.0.49 and
PHP-4.3.6RC3 on Linux. I'm trying to test mod_perl-1.99-13 with Apache
2.0.49 and PHP-4.3.6RC3 and I get this:
t/perl/hash_attack..ok
t/perl/ithreads.ok
t/perl/ithreads2ok
t/preconnection/noteok
t/protocol/echo.ok
t/protocol/echo_filter..ok
t/vhost/config..ok
All tests successful, 4 tests skipped.
Files=174, Tests=1076, 277 wallclock secs (158.69 cusr + 18.64 csys =
177.33 CPU)
[warning] server linux:8529 shutdown
[warning] port 8529 still in use...
..done
[ error] oh golly, server dumped core
[ error] for stacktrace, run: gdb /usr/local/apache-2.0.49/bin/httpd
-core /home/tom/mod_perl-1.99_13/t/core.17388
So, I run the gdb command above and get this backtrace:
(gdb) bt
#0 0x40300860 in ?? ()
#1 0x08071601 in regex_cleanup (preg=0x864c9c8) at util.c:258
#2 0x4011da0d in run_cleanups (cref=0x80a2f28)
#28013 [NEW]: using java get*() in a switch statement
From: pcarmody at c-spanarchives dot org
Operating system: Solaris 8
PHP version: 4.3.4
PHP Bug Type: Java related
Bug description: using java get*() in a switch statement
Description:
When using the auto-JavaBean style access to member variables in a switch
statement causes a core dump. Specifying the method name directly avoids
this problem.
Reproduce code:
---
Java class:
public class Blah {
private int blah;
public Blah() {
this.blah = 1;
}
public int getBlah() {
return this.blah;
}
}
PHP call:
blah ) {
case 1:
break;
}
?>
Expected result:
Exits normally.
Actual result:
--
A core dump.
If you replace $blah->blah with $blah->getBlah() the code will work
correctly.
--
Edit bug report at http://bugs.php.net/?id=28013&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28013&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28013&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28013&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28013&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28013&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28013&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28013&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28013&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28013&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28013&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28013&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28013&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28013&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28013&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28013&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28013&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28013&r=float
#28012 [Opn]: spprintf() output inconsistent for %p (fix included)
ID: 28012 User updated by: php-lists at nomeaning dot net Reported By: php-lists at nomeaning dot net Status: Open Bug Type: Output Control Operating System: linux RH 9 PHP Version: 5CVS-2004-04-15 (dev) New Comment: Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to [EMAIL PROTECTED] Sorry for the confusion. Previous Comments: [2004-04-15 17:15:56] php-lists at nomeaning dot net H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28012 [Opn]: spprintf() output inconsistent for %p (fix included)
ID: 28012 User updated by: php-lists at nomeaning dot net Reported By: php-lists at nomeaning dot net Status: Open Bug Type: Output Control Operating System: linux RH 9 PHP Version: 5CVS-2004-04-15 (dev) New Comment: H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! Previous Comments: [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28012 [NEW]: spprintf() output inconsistent for %p (fix included)
From: php-lists at nomeaning dot net Operating system: linux RH 9 PHP version: 5CVS-2004-04-15 (dev) PHP Bug Type: Output Control Bug description: spprintf() output inconsistent for %p (fix included) Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit bug report at http://bugs.php.net/?id=28012&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28012&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28012&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28012&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28012&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28012&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28012&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28012&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28012&r=support Expected behavior: http://bugs.php.net/fix.php?id=28012&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28012&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28012&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28012&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28012&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28012&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28012&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28012&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28012&r=float
#27681 [Csd]: soap extension fails without HAVE_TM_GMTOFF
ID: 27681
User updated by: jwm at horde dot net
Reported By: jwm at horde dot net
Status: Closed
Bug Type: SOAP related
Operating System: Solaris 8
PHP Version: 5.0.0RC1
Assigned To: dmitry
New Comment:
The soap extension builds successfully under Solaris
now. Thanks, Dmitry.
Previous Comments:
[2004-04-15 06:30:27] [EMAIL PROTECTED]
Fixed in 5.0.0RC2-dev CVS.
Please, verify me on Solaris.
[2004-04-07 11:16:01] [EMAIL PROTECTED]
Assigned to the maintainer.
[2004-03-24 16:43:05] jwm at horde dot net
Description:
The soap extension fails to build (undefined variables)
on Solaris 8 because the !HAVE_TM_GMTOFF case requires
tzone, which is not defined. This (perhaps naive) patch
fixes the build, but I haven't tested it:
--- ext/soap/php_encoding.c~2004-03-20 17:10:
22.646093000 -0500
+++ ext/soap/php_encoding.c 2004-03-20 17:10:
22.656085000 -0500
@@ -2119,6 +2119,7 @@
size_t buf_len=64, real_len;
char *buf;
char tzbuf[6];
+ long tzone;
xmlNodePtr xmlParam;
@@ -2130,7 +2131,13 @@
timestamp = Z_LVAL_P(data);
ta = php_localtime_r(×tamp,
&tmbuf);
/*ta = php_gmtime_r(×tamp, &tmbuf);
*/
-
+#if !HAVE_TM_GMTOFF
+#ifdef __CYGWIN__
+ tzone = _timezone;
+#else
+ tzone = timezone;
+#endif
+#endif
buf = (char *) emalloc(buf_len);
while ((real_len = strftime(buf,
buf_len, format, ta)) == buf_len || real_len == 0) {
buf_len *= 2;
--
Edit this bug report at http://bugs.php.net/?id=27681&edit=1
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810 Comment by: danu at drydog dot com Reported By: renato at galle dot com dot br Status: Closed Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment: NOT fixed with php-4.3.6 I just tried this and it isn't fixed with PHP 4.3.6 either. Previous Comments: [2004-04-13 19:28:27] loki at arete dot cc I also tried the latest php4 snapshot, as well as the latest php4 release candidate, and CVS HEAD for both php4-STABLE and php5. None of them worked. This bug is not fixed in CVS, in snaps, or anywhere. It's not documented as being fixed, and the problem is still there. I finally got fed up and took ext/pcre from php-4.3.4 and used that instead of what you shipped with php -5.0.0rc1, and that works fine. [2004-04-12 02:55:30] loki at arete dot cc I just tried the latest php5 snapshot. Problem still present. Is it only fixed in php4 cvs? Can you tell us what the problem actually is? There's still no documentation of it in Changelog or in NEWS. [2004-04-11 13:45:25] tomdkat at comcast dot net I'm seeing this same (or similar) problem with Apache 2.0.49 and PHP-4.3.6RC3 on Linux. I'm trying to test mod_perl-1.99-13 with Apache 2.0.49 and PHP-4.3.6RC3 and I get this: t/perl/hash_attack..ok t/perl/ithreads.ok t/perl/ithreads2ok t/preconnection/noteok t/protocol/echo.ok t/protocol/echo_filter..ok t/vhost/config..ok All tests successful, 4 tests skipped. Files=174, Tests=1076, 277 wallclock secs (158.69 cusr + 18.64 csys = 177.33 CPU) [warning] server linux:8529 shutdown [warning] port 8529 still in use... ..done [ error] oh golly, server dumped core [ error] for stacktrace, run: gdb /usr/local/apache-2.0.49/bin/httpd -core /home/tom/mod_perl-1.99_13/t/core.17388 So, I run the gdb command above and get this backtrace: (gdb) bt #0 0x40300860 in ?? () #1 0x08071601 in regex_cleanup (preg=0x864c9c8) at util.c:258 #2 0x4011da0d in run_cleanups (cref=0x80a2f28) at apr_pools.c:1951 #3 0x4011d14d in apr_pool_destroy (pool=0x80a2f18) at apr_pools.c:730 #4 0x4011d208 in apr_pool_destroy (pool=0x80a0f10) at apr_pools.c:727 #5 0x0806efc3 in destroy_and_exit_process (process=0x864c9c8, process_exit_value=140822984) at main.c:208 #6 0x0806fc33 in main (argc=9, argv=0xbfffdb44) at main.c:624 #7 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) If I remove the loading of the PHP module in Apache 2.0.49, the mod_perl_1.99-13 test runs cleanly and no core files get generated. :( Peace... [2004-04-11 12:12:05] tomdkat at comcast dot net I'm running Apache/2.0.48 (Unix) mod_perl/1.99_13 Perl/v5.8.2 PHP/4.3.5 and I get this same crash when I try to restart Apache gracefully. My PCRE info: PCRE Library Version4.5 01-December-2003 Is everyone else using mod_perl? Peace... [2004-04-10 21:21:05] sdfsdhfkg at hotmail dot com I experience the exact same problem under FreeBSD 5.2.1 and also under Windows XP (just testing my scripts on this platform, I don't use Windows as a server). Why don't the developers give details on exactly how this bug was fixed in CVS? (If it was really fixed at all. Some people suggest that it was not.) First they labeled this bug as 'bogus' when in fact it was not. Now they say it has been fixed but don't give out any deatils. Is this the way open source projects work?? If it's going to be like this, then I must say open source developers are no better than Microsoft!! Maybe they are just ashamed of a lame bug in their source and trying to keep this as a secret? What's happening here?? 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/27810 -- Edit this bug report at http://bugs.php.net/?id=27810&edit=1
#27986 [Opn]: make errors still persist
ID: 27986 User updated by: sandduneinfo at earthlink dot net Reported By: sandduneinfo at earthlink dot net Status: Open Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.5 New Comment: I am sorry if I misunderstood your previous responses, the latest link sent earlier today is that fixing the items I submitted this morning - or are you still working on them?? Previous Comments: [2004-04-15 10:23:57] sandduneinfo at earthlink dot net You make a good point about which compiler, but when I orignally integated perl , mysql and the dbd/dbi modules, I had problems with mixed ansi and gcc compiles used for the various software and when I tried to compile them in gcc, I got dozens of errors. So I went back to ansi. Since I compiled apache with ansi amd mysql with the ansi, I did not want to raise any incompatibility issues with php and mysql and or apache. So the last "latest" has the lines are already corrected in from my ealrlier this AM email??? THANK YOU for all yuo help by the way. Regards, Dan Rizzi Sand Duneinformation Services [2004-04-15 09:52:23] [EMAIL PROTECTED] They're likely caused by the compile errors. And including them is pointless anyway, it's a libtool issue.. btw. You'd propably be running PHP already if you used GCC.. [2004-04-15 09:50:09] sandduneinfo at earthlink dot net are the repairs already made??? AND are the file errors a result of these earlier errors in the make process or are these another issue entirely, that I should be able to resolve without code corrections??, is that why you are asking me not to include them??? [2004-04-15 09:45:47] [EMAIL PROTECTED] Paste ONLY the compile errors, do NOT put those "..contains an incorrect file suffix" errors in the paste. [2004-04-13 23:39:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Apparently we missed some places..So please try the latest stable snapshot and show us all the errors with current line numbers. 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/27986 -- Edit this bug report at http://bugs.php.net/?id=27986&edit=1
#27992 [Bgs]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: Ah, now that you point that out, it's clear. Thank you. This is why I posted to internals@, first. Agreed. Bogus. S Previous Comments: [2004-04-15 10:34:13] [EMAIL PROTECTED] Hi. This isn't a bug. In your constructor, you stick a reference to $this in $_PEAR_destructor_object_list. This gives the object a refcount of 2, so it isn't destructed when it falls out of scope. This is expected behavior here. [2004-04-15 10:15:26] [EMAIL PROTECTED] Segfault: understandable My real concern is that it seems resources are not being released in this context. 65k is a big number (segfault). 1k not so much (warning; unable to open resource). S [2004-04-15 10:05:43] [EMAIL PROTECTED] The segfault is a known (and I believe wont-be-fixed-in -4) bug in the reference counting implementation. [2004-04-15 10:02:33] [EMAIL PROTECTED] First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? 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/27992 -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#28009 [Opn]: "make test" got hung
ID: 28009 User updated by: dhananjaya dot eadala at oracle dot com Reported By: dhananjaya dot eadala at oracle dot com Status: Open Bug Type: Math related Operating System: Linux PHP Version: 4.3.6RC3 New Comment: when I remove the bug21523.phpt from test suite, "make test" went on fine. Previous Comments: [2004-04-15 10:51:00] dhananjaya dot eadala at oracle dot com Description: php cli and .so was built successfully. after when I issue "make test" command, it is getting hung at running the test for ext/standard/tests/math/bug21523.phpt test. assuming it is problem with make, I ran the same test manually using php cli. still I ran to same problem of getting hung. Is there any work around for this. -- Edit this bug report at http://bugs.php.net/?id=28009&edit=1
#28010 [Opn->Bgs]: zip_open doesn't work with HTTP wrapper
ID: 28010 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: ZZiplib Related Operating System: Windows PHP Version: 4CVS-2004-04-15 (stable) New Comment: This is a limitation of the zzip library and not something we can fix. Previous Comments: [2004-04-15 11:02:27] [EMAIL PROTECTED] Description: zip_open doesn't work with HTTP wrapper (at least) Reproduce code: --- http://snaps.php.net/win32/php4-win32-STABLE-200404151230.zip";); ?> Expected result: (nothing) Actual result: -- Warning: zip_open() Cannot open zip archive ... -- Edit this bug report at http://bugs.php.net/?id=28010&edit=1
#28010 [NEW]: zip_open doesn't work with HTTP wrapper
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4CVS-2004-04-15 (stable) PHP Bug Type: ZZiplib Related Bug description: zip_open doesn't work with HTTP wrapper Description: zip_open doesn't work with HTTP wrapper (at least) Reproduce code: --- http://snaps.php.net/win32/php4-win32-STABLE-200404151230.zip";); ?> Expected result: (nothing) Actual result: -- Warning: zip_open() Cannot open zip archive ... -- Edit bug report at http://bugs.php.net/?id=28010&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28010&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28010&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28010&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28010&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28010&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28010&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28010&r=support Expected behavior: http://bugs.php.net/fix.php?id=28010&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28010&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28010&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28010&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28010&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28010&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28010&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28010&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28010&r=float
#28009 [NEW]: "make test" got hung
From: dhananjaya dot eadala at oracle dot com Operating system: Linux PHP version: 4.3.6RC3 PHP Bug Type: Math related Bug description: "make test" got hung Description: php cli and .so was built successfully. after when I issue "make test" command, it is getting hung at running the test for ext/standard/tests/math/bug21523.phpt test. assuming it is problem with make, I ran the same test manually using php cli. still I ran to same problem of getting hung. Is there any work around for this. -- Edit bug report at http://bugs.php.net/?id=28009&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28009&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28009&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28009&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28009&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28009&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28009&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28009&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28009&r=support Expected behavior: http://bugs.php.net/fix.php?id=28009&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28009&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28009&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28009&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28009&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28009&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28009&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28009&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28009&r=float
#28006 [Fbk->Opn]: referencing an unset global produces a segfault
ID: 28006
User updated by: per at computer dot org
Reported By: per at computer dot org
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.24
PHP Version: 4.3.4
New Comment:
Here's the backtrace when doing the same thing with
php4-STABLE-200404151030
(gdb) run -X -f /etc/httpd/httpd.conf
Starting program: /usr/bin/httpd -X -f /etc/httpd/
httpd.conf
[New Thread 16384 (LWP 18823)]
[Thu Apr 15 16:35:42 2004] [warn] module php4_module is
already loaded, skipping
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 18823)]
0x40578b32 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute_API.c:271
271 return active_opline->lineno;
(gdb) bt
#0 0x40578b32 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute_API.c:271
#1 0x405811bd in zend_error (type=8, format=0x40709bff
"Undefined index: %s") at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/Zend/zend.c:733
#2 0x40593a80 in zend_fetch_dimension_address_inner
(ht=0x81d2d2c, op2=0x8226540, Ts=0xbfffaa7c, type=0) at /
usr/src/packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute.c:645
#3 0x4058cba0 in zend_fetch_dimension_address
(result=0x8226520, op1=0x82061bc, op2=0x8226540,
Ts=0xbfffaa7c, type=0) at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/Zend/zend_execute.c:801
#4 0x40591dbe in execute (op_array=0x81e932c) at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/Zend/
zend_execute.c:1297
#5 0x4058130b in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/Zend/zend.c:886
#6 0x40554fcf in php_execute_script
(primary_file=0xb3f0) at /usr/src/packages/SOURCES/
php4-STABLE-200404151030/main/main.c:1731
#7 0x40594ae4 in php_handler (r=0x81c17e8) at /usr/src/
packages/SOURCES/php4-STABLE-200404151030/sapi/
apache2handler/sapi_apache2.c:561
#8 0x08092d85 in ap_run_handler (r=0x81c17e8) at
config.c:151
#9 0x08093390 in ap_invoke_handler (r=0x81c17e8) at
config.c:358
#10 0x08076edb in ap_process_request (r=0x81c17e8) at
http_request.c:246
#11 0x0807239d in ap_process_http_connection (c=0x81b4fd8)
at http_core.c:250
#12 0x0809de25 in ap_run_process_connection (c=0x81b4fd8)
at connection.c:42
#13 0x08091384 in child_main (child_num_arg=148) at
prefork.c:609
#14 0x0809159b in make_child (s=0x0, slot=0) at
prefork.c:649
#15 0x080915f8 in startup_children (number_to_start=5) at
prefork.c:721
#16 0x08091e6a in ap_mpm_run (_pconf=0x80d6310,
plog=0x8116410, s=0x80d9dd0) at prefork.c:940
#17 0x080983bd in main (argc=4, argv=0xb764) at
main.c:617
Previous Comments:
[2004-04-15 07:44:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-04-15 07:36:22] per at computer dot org
Description:
Hi,
I've got a situation where a seemingly innocent statement
produces a
segfault. I've tried reducing it to a single reproducable
testcase, but
without
success. The problem is however solidly reproducable in the
context in which it occurs.
I'm certain it is caused by a mistake in my code, but I
feel it isn't
exactly appropriate for php to segfault because of a user
error?
Very briefly, this is an excerpt where the segfault occurs:
";
$result=mysql_query( $q ) or die("mysql:".mysql_error());
$main_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$billing_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$technical_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$editmain=strcasecmp($_REQUEST['contact'],"main")==0;
//
$editbilling=strcasecmp($_REQUEST['contact'],"billing")==0;
//
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0;
?>
If I uncomment either of the last 2 commented-out
statements, I get a segfault.
I'm using php 4.3.4 and apache 2.0.49 on linux 2.4.24.
mysql is 4.0.15.
---
OK,
I've now guarded the above with :
if ( isset($_REQUEST['contact']) )
{
$editmain=strcmp($_REQUEST['contact'],"main")==0;
$editbilling=strcmp($_REQUEST['contact'],"billing")==0;
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0;
}
and the segfault is
gone. Still, a se
#28008 [NEW]: apache 2 and php4 child segfauls when accessing php pages
From: dzila at tassadar dot physics dot auth dot gr Operating system: Slackware 8 , kernel 2.4.25 PHP version: 4CVS-2004-04-15 (stable) PHP Bug Type: Apache2 related Bug description: apache 2 and php4 child segfauls when accessing php pages Description: I am compiling apache2 and php for the first time. Every time a php page is accessed the apache child segfaults and no php page can be displayed. I tried with 4.3.5 and the latest 4 snap.Non php pages work fine /configure --with-apxs2=/disk2/daemons/www2/bin/apxs --with-openssl --enable-cli --enable-ftp --with-zlib --with-zip --with-mysql=/disk2/daemons/mysql --enable-debug (also tried only with-apxs and no other options , --with-mysql on its on, same results) I am launching apache2 because I want ipv6 enabled web server , I tried binding it to both ipv6 and ipv4 addresses with same results Reproduce code: --- a postnuke site which works ok with apache 1.3 Actual result: -- gdb ./httpd GNU gdb 5.0 Copyright 2000 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 "i386-slackware-linux"... (gdb) run -X Starting program: /disk2/daemons/www2/bin/./httpd -X warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x82e3d76 in ?? () (gdb) bt #0 0x82e3d76 in ?? () #1 0x405e9ed0 in ?? () #2 0x405e962e in ?? () #3 0x405e98c3 in ?? () #4 0x403868c3 in getservbyname_r () from /lib/libc.so.6 #5 0x40386771 in getservbyname () from /lib/libc.so.6 #6 0x4056c3bf in ?? () #7 0x4056eeb4 in ?? () #8 0x403fe0a6 in ?? () #9 0x403fe3c5 in ?? () #10 0x405128e2 in ?? () #11 0x40512b2c in ?? () #12 0x40512b2c in ?? () #13 0x40512b2c in ?? () #14 0x40512b2c in ?? () #15 0x404ff484 in ?? () #16 0x404c310c in ?? () #17 0x4051939c in ?? () #18 0x8097929 in ap_run_handler (r=0x81b2f80) at config.c:151 #19 0x8097e73 in ap_invoke_handler (r=0x81b2f80) at config.c:358 #20 0x8087a76 in ap_process_request (r=0x81b2f80) at http_request.c:246 #21 0x808393a in ap_process_http_connection (c=0x81aef50) at http_core.c:250 #22 0x80a0e88 in ap_run_process_connection (c=0x81aef50) at connection.c:42 #23 0x80a115c in ap_process_connection (c=0x81aef50, csd=0x81aee78) at connection.c:175 #24 0x80965b0 in child_main (child_num_arg=0) at prefork.c:609 #25 0x809666c in make_child (s=0x80df138, slot=0) at prefork.c:649 #26 0x8096761 in startup_children (number_to_start=5) at prefork.c:721 #27 0x8096a63 in ap_mpm_run (_pconf=0x80dc270,plog=0x8114350, s=0x80df138) at prefork.c:940 #28 0x809c26e in main (argc=2, argv=0xba04) at ain.c:617 #29 0x402c82eb in __libc_start_main () from /lib/libc.so.6 -- Edit bug report at http://bugs.php.net/?id=28008&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28008&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28008&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28008&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28008&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28008&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28008&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28008&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28008&r=support Expected behavior: http://bugs.php.net/fix.php?id=28008&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28008&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28008&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28008&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28008&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28008&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28008&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28008&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28008&r=float
#27992 [Fbk->Bgs]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: Hi. This isn't a bug. In your constructor, you stick a reference to $this in $_PEAR_destructor_object_list. This gives the object a refcount of 2, so it isn't destructed when it falls out of scope. This is expected behavior here. Previous Comments: [2004-04-15 10:15:26] [EMAIL PROTECTED] Segfault: understandable My real concern is that it seems resources are not being released in this context. 65k is a big number (segfault). 1k not so much (warning; unable to open resource). S [2004-04-15 10:05:43] [EMAIL PROTECTED] The segfault is a known (and I believe wont-be-fixed-in -4) bug in the reference counting implementation. [2004-04-15 10:02:33] [EMAIL PROTECTED] First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? [2004-04-14 11:41:00] [EMAIL PROTECTED] Description: See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket. Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources. Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51 ERROR: 24 - Too many open files This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail. Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent. The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such. Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). ** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.** This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so. Reproduce code: --- http://sean.caedmon.net/php/crashing_resources.phps Expected result: (see description) Actual result: -- (see description) -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#28007 [NEW]: FreeTDS support will not compile
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.6RC3 PHP Bug Type: MSSQL related Bug description: FreeTDS support will not compile Description: See bug #21544 -- I was asked to open a new report. ./configure --with-mssql ... works, but a make of the same fails with: (see actual result). FreeTDS version: (debian unstable) 0.53-7 Sniper mentioned that he thinks it's my FreeTDS install. Could be. The attached patch seems to completely fix the problem, though. As mentioned in the other bug: I'm not a C guy, so I could be way wrong on this. All I know is that after patching, --with-mssql compiles and the library seems to work (as) well (as mssql on linux has ever worked). S --- Index: ext/mssql/php_mssql.c === RCS file: /repository/php-src/ext/mssql/php_mssql.c,v retrieving revision 1.86.2.31 diff -u -r1.86.2.31 php_mssql.c --- ext/mssql/php_mssql.c 30 Mar 2004 17:54:38 - 1.86.2.31 +++ ext/mssql/php_mssql.c 14 Apr 2004 15:18:18 - @@ -336,7 +336,7 @@ dbsetlogintime(MS_SQL_G(connect_timeout)); if (MS_SQL_G(timeout) < 0) MS_SQL_G(timeout) = 60; dbsettime(MS_SQL_G(timeout)); - dbsetmaxprocs((SHORT)MS_SQL_G(max_procs)); + dbsetmaxprocs((int)MS_SQL_G(max_procs)); return SUCCESS; } Reproduce code: --- n/a Expected result: compile Actual result: -- ext/mssql/php_mssql.c: In function `zm_activate_mssql': ext/mssql/php_mssql.c:339: `SHORT' undeclared (first use in this function) ext/mssql/php_mssql.c:339: (Each undeclared identifier is reported only once ext/mssql/php_mssql.c:339: for each function it appears in.) make: *** [ext/mssql/php_mssql.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=28007&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28007&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28007&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28007&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28007&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28007&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28007&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28007&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28007&r=support Expected behavior: http://bugs.php.net/fix.php?id=28007&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28007&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28007&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28007&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28007&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28007&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28007&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28007&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28007&r=float
#27986 [Fbk->Opn]: make errors still persist
ID: 27986 User updated by: sandduneinfo at earthlink dot net Reported By: sandduneinfo at earthlink dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.5 New Comment: You make a good point about which compiler, but when I orignally integated perl , mysql and the dbd/dbi modules, I had problems with mixed ansi and gcc compiles used for the various software and when I tried to compile them in gcc, I got dozens of errors. So I went back to ansi. Since I compiled apache with ansi amd mysql with the ansi, I did not want to raise any incompatibility issues with php and mysql and or apache. So the last "latest" has the lines are already corrected in from my ealrlier this AM email??? THANK YOU for all yuo help by the way. Regards, Dan Rizzi Sand Duneinformation Services Previous Comments: [2004-04-15 09:52:23] [EMAIL PROTECTED] They're likely caused by the compile errors. And including them is pointless anyway, it's a libtool issue.. btw. You'd propably be running PHP already if you used GCC.. [2004-04-15 09:50:09] sandduneinfo at earthlink dot net are the repairs already made??? AND are the file errors a result of these earlier errors in the make process or are these another issue entirely, that I should be able to resolve without code corrections??, is that why you are asking me not to include them??? [2004-04-15 09:45:47] [EMAIL PROTECTED] Paste ONLY the compile errors, do NOT put those "..contains an incorrect file suffix" errors in the paste. [2004-04-13 23:39:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Apparently we missed some places..So please try the latest stable snapshot and show us all the errors with current line numbers. [2004-04-13 22:12:06] sandduneinfo at earthlink dot net Description: I was able to install apache 2.0.49 it seems to be working OK. I went to install php 4.3.5 with the apxs and the mysql flags using the AIX Ansi c compiler I listed out much of the error in make below and of course the make install fails big time. I do have mysql version 4.0.17 and I have been accessing it with perl and DBD/DBI. I have run the make cklean and retired, I have also deleted the the php install directory and "retarred" it back. It complained in configure originally about flex and bison missing in configure originally and I added those in on download from IBM website and installed with rpm. So those issues went away. I noticed something about 4.3.5 was supposed to fix unsigned int errors - are their more. I am not a C programmer - which leaves me more in the dark. HELP! Dan Rizzi Expected result: Additional make errors ... cc: 1501-218 file Zend/zend_llist.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_opcode.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_operators.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_ptr_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_variables.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_API.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_extensions.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_hash.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_list.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_indent.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_builtin_functions.lo contains an incorrect file suff ix Actual result: -- "/tmp/php/php-4.3.5/ext/standard/array.c", line 1723.64: 1506-280 (W) Function a rgument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 918.100: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 924.114: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2308.13: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2373.29: 1506-280 (W) Function ar g
#27992 [Fbk]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: Segfault: understandable My real concern is that it seems resources are not being released in this context. 65k is a big number (segfault). 1k not so much (warning; unable to open resource). S Previous Comments: [2004-04-15 10:05:43] [EMAIL PROTECTED] The segfault is a known (and I believe wont-be-fixed-in -4) bug in the reference counting implementation. [2004-04-15 10:02:33] [EMAIL PROTECTED] First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? [2004-04-14 11:41:00] [EMAIL PROTECTED] Description: See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket. Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources. Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51 ERROR: 24 - Too many open files This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail. Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent. The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such. Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). ** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.** This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so. Reproduce code: --- http://sean.caedmon.net/php/crashing_resources.phps Expected result: (see description) Actual result: -- (see description) -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#27992 [Fbk]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: The segfault is a known (and I believe wont-be-fixed-in -4) bug in the reference counting implementation. Previous Comments: [2004-04-15 10:02:33] [EMAIL PROTECTED] First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? [2004-04-14 11:41:00] [EMAIL PROTECTED] Description: See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket. Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources. Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51 ERROR: 24 - Too many open files This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail. Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent. The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such. Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). ** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.** This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so. Reproduce code: --- http://sean.caedmon.net/php/crashing_resources.phps Expected result: (see description) Actual result: -- (see description) -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#27992 [Fbk]: Resource Leak
ID: 27992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Class/Object related Operating System: Linux (any) PHP Version: 4.3.6RC3 New Comment: First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope. Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose. While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue). S Previous Comments: [2004-04-14 22:34:20] [EMAIL PROTECTED] Why woudln't it run out of file handles when you never CLOSE the socket..? [2004-04-14 11:41:00] [EMAIL PROTECTED] Description: See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket. Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources. Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51 ERROR: 24 - Too many open files This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail. Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent. The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such. Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). ** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.** This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so. Reproduce code: --- http://sean.caedmon.net/php/crashing_resources.phps Expected result: (see description) Actual result: -- (see description) -- Edit this bug report at http://bugs.php.net/?id=27992&edit=1
#28005 [Opn->Bgs]: use of per class constants
ID: 28005 Updated by: [EMAIL PROTECTED] Reported By: e dot vandeoudeweetering at marcanti dot esprit-sg dot -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: windows2000 (5.00.2195) sp4 PHP Version: 5.0.0RC1 New Comment: 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 . Previous Comments: [2004-04-15 07:28:44] e dot vandeoudeweetering at marcanti dot esprit-sg dot Description: This bug is related to: Bug #27523 It is not possible to use a class constant, without a reference to its OWN class! see reproduce code: Another problem is that the function returns the name of the constant instead of it's value! Reproduce code: --- printConst(); ?> Expected result: The following output should be printed: const Test::TEMP = hi const TEMP = hi Actual result: -- const Test::TEMP = hi PHP Notice: Use of undefined constant TEMP - assumed 'TEMP' in C:\Temp\test.php on line 8 const TEMP = TEMP -- Edit this bug report at http://bugs.php.net/?id=28005&edit=1
#27986 [Opn->Fbk]: make errors still persist
ID: 27986 Updated by: [EMAIL PROTECTED] Reported By: sandduneinfo at earthlink dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.5 New Comment: They're likely caused by the compile errors. And including them is pointless anyway, it's a libtool issue.. btw. You'd propably be running PHP already if you used GCC.. Previous Comments: [2004-04-15 09:50:09] sandduneinfo at earthlink dot net are the repairs already made??? AND are the file errors a result of these earlier errors in the make process or are these another issue entirely, that I should be able to resolve without code corrections??, is that why you are asking me not to include them??? [2004-04-15 09:45:47] [EMAIL PROTECTED] Paste ONLY the compile errors, do NOT put those "..contains an incorrect file suffix" errors in the paste. [2004-04-13 23:39:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Apparently we missed some places..So please try the latest stable snapshot and show us all the errors with current line numbers. [2004-04-13 22:12:06] sandduneinfo at earthlink dot net Description: I was able to install apache 2.0.49 it seems to be working OK. I went to install php 4.3.5 with the apxs and the mysql flags using the AIX Ansi c compiler I listed out much of the error in make below and of course the make install fails big time. I do have mysql version 4.0.17 and I have been accessing it with perl and DBD/DBI. I have run the make cklean and retired, I have also deleted the the php install directory and "retarred" it back. It complained in configure originally about flex and bison missing in configure originally and I added those in on download from IBM website and installed with rpm. So those issues went away. I noticed something about 4.3.5 was supposed to fix unsigned int errors - are their more. I am not a C programmer - which leaves me more in the dark. HELP! Dan Rizzi Expected result: Additional make errors ... cc: 1501-218 file Zend/zend_llist.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_opcode.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_operators.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_ptr_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_variables.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_API.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_extensions.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_hash.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_list.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_indent.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_builtin_functions.lo contains an incorrect file suff ix Actual result: -- "/tmp/php/php-4.3.5/ext/standard/array.c", line 1723.64: 1506-280 (W) Function a rgument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 918.100: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 924.114: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2308.13: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2373.29: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/info.c", line 480.122: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 84.31: 1506-280 (W) Function argumen t assignment between types "unsigned char*" and "const unsigned char*" is not al lowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 125.39: 1506-280 (W) Function argume nt assignment between types "unsigned char*" and "const unsigned char*" is not a llowed. ---
#27986 [Fbk->Opn]: make errors still persist
ID: 27986 User updated by: sandduneinfo at earthlink dot net Reported By: sandduneinfo at earthlink dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.5 New Comment: are the repairs already made??? AND are the file errors a result of these earlier errors in the make process or are these another issue entirely, that I should be able to resolve without code corrections??, is that why you are asking me not to include them??? Previous Comments: [2004-04-15 09:45:47] [EMAIL PROTECTED] Paste ONLY the compile errors, do NOT put those "..contains an incorrect file suffix" errors in the paste. [2004-04-13 23:39:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Apparently we missed some places..So please try the latest stable snapshot and show us all the errors with current line numbers. [2004-04-13 22:12:06] sandduneinfo at earthlink dot net Description: I was able to install apache 2.0.49 it seems to be working OK. I went to install php 4.3.5 with the apxs and the mysql flags using the AIX Ansi c compiler I listed out much of the error in make below and of course the make install fails big time. I do have mysql version 4.0.17 and I have been accessing it with perl and DBD/DBI. I have run the make cklean and retired, I have also deleted the the php install directory and "retarred" it back. It complained in configure originally about flex and bison missing in configure originally and I added those in on download from IBM website and installed with rpm. So those issues went away. I noticed something about 4.3.5 was supposed to fix unsigned int errors - are their more. I am not a C programmer - which leaves me more in the dark. HELP! Dan Rizzi Expected result: Additional make errors ... cc: 1501-218 file Zend/zend_llist.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_opcode.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_operators.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_ptr_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_variables.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_API.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_extensions.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_hash.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_list.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_indent.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_builtin_functions.lo contains an incorrect file suff ix Actual result: -- "/tmp/php/php-4.3.5/ext/standard/array.c", line 1723.64: 1506-280 (W) Function a rgument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 918.100: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 924.114: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2308.13: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2373.29: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/info.c", line 480.122: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 84.31: 1506-280 (W) Function argumen t assignment between types "unsigned char*" and "const unsigned char*" is not al lowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 125.39: 1506-280 (W) Function argume nt assignment between types "unsigned char*" and "const unsigned char*" is not a llowed. -- Edit this bug report at http://bugs.php.net/?id=27986&edit=1
#27986 [Opn->Fbk]: make errors still persist
ID: 27986 Updated by: [EMAIL PROTECTED] Reported By: sandduneinfo at earthlink dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.5 New Comment: Paste ONLY the compile errors, do NOT put those "..contains an incorrect file suffix" errors in the paste. Previous Comments: [2004-04-13 23:39:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Apparently we missed some places..So please try the latest stable snapshot and show us all the errors with current line numbers. [2004-04-13 22:12:06] sandduneinfo at earthlink dot net Description: I was able to install apache 2.0.49 it seems to be working OK. I went to install php 4.3.5 with the apxs and the mysql flags using the AIX Ansi c compiler I listed out much of the error in make below and of course the make install fails big time. I do have mysql version 4.0.17 and I have been accessing it with perl and DBD/DBI. I have run the make cklean and retired, I have also deleted the the php install directory and "retarred" it back. It complained in configure originally about flex and bison missing in configure originally and I added those in on download from IBM website and installed with rpm. So those issues went away. I noticed something about 4.3.5 was supposed to fix unsigned int errors - are their more. I am not a C programmer - which leaves me more in the dark. HELP! Dan Rizzi Expected result: Additional make errors ... cc: 1501-218 file Zend/zend_llist.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_opcode.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_operators.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_ptr_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_stack.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_variables.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_API.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_extensions.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_hash.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_list.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_indent.lo contains an incorrect file suffix cc: 1501-218 file Zend/zend_builtin_functions.lo contains an incorrect file suff ix Actual result: -- "/tmp/php/php-4.3.5/ext/standard/array.c", line 1723.64: 1506-280 (W) Function a rgument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 918.100: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 924.114: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2308.13: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/file.c", line 2373.29: 1506-280 (W) Function ar gument assignment between types "unsigned long*" and "int*" is not allowed. "/tmp/php/php-4.3.5/ext/standard/info.c", line 480.122: 1506-280 (W) Function ar gument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 84.31: 1506-280 (W) Function argumen t assignment between types "unsigned char*" and "const unsigned char*" is not al lowed. "/tmp/php/php-4.3.5/main/safe_mode.c", line 125.39: 1506-280 (W) Function argume nt assignment between types "unsigned char*" and "const unsigned char*" is not a llowed. -- Edit this bug report at http://bugs.php.net/?id=27986&edit=1
#28004 [Opn->Bgs]: Post data weirdly disappearing when stored in a session
ID: 28004
Updated by: [EMAIL PROTECTED]
Reported By: kevin at cayenne dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Gentoo Linux
PHP Version: 4.3.6RC3
New Comment:
Improper HTML / CSS causes all kinds of weird things. Still not PHP
bug.
Previous Comments:
[2004-04-15 08:30:05] kevin at cayenne dot co dot uk
I don't think that it's anything to do with cookies etc; all other
session stuff works fine (I can add other session variables, initiate a
different session) and if I delete the file from /tmp/ and/or the
cookie from my browser then a new session gets started properly.
The main reason why I think it's a scripting engine bug is that the
behaviour of the script changes depending upon the @import line. This
shouldn't have anything to do with PHP, it's an instruction to my
browser, yet the PHP behaves differently for these two lines:
@import url(); (PHP session does not work properly)
@import url("nothing.css"); (PHP session works)
These lines are not in a PHP tag, or a PHP { } block, and the weird
behaviour still exists whether I have output buffering on or not. The
session output being printed to my browser is different to what's being
written to the /tmp/ file; surely that's a bug?
[2004-04-15 08:15:25] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Yes, any "outside" stuff can and will affect this since it can disable
sending some cookie, etc. Ask further support questions elsewhere.
[2004-04-15 06:57:27] kevin at cayenne dot co dot uk
I forgot to mention, due to limitations at my work I have only tested
this on 4.3.6RC2 but there was no option for that on the drop-down. I
have also experienced this bug on 4.2.3 at another site.
[2004-04-15 06:54:17] kevin at cayenne dot co dot uk
Description:
Provided is the source for 3 files: bug0.html submits a form to
bug1.html, which then stores the post'd data in a session. A form in
bug1.html submits to bug2.html (with no post variables), but the
session data is blank where it should have contained the post data from
bug0.html (this is more clear if you read the source code). If the
session is inspected in bug1.html, it is as expected, however the file
written to /tmp/ is not.
The weird thing is this: there is a style tag in bug1.html which
contains a line "@import url()". This is outside the PHP, and
shouldn't affect anything to do with the PHP parsing / running. If the
@import line is removed, the session data gets written properly.
If a better explanation / demo is needed, please feel free to ask.
Reproduce code:
---
bug0.html:
bug1.html:
@import url();
";print_r($_SESSION);echo "";
?>
bug2.html:
";print_r($_SESSION);exit;
?>
Expected result:
In bug1.html:
Array
(
[blah1] => baa baa black sheep
[blah2] => Look at this: baa baa black sheep
)
In bug2.html:
Array
(
[blah1] => baa baa black sheep
[blah2] => Look at this: baa baa black sheep
)
Actual result:
--
In bug1.html:
Array
(
[blah1] => baa baa black sheep
[blah2] => Look at this: baa baa black sheep
)
In bug2.html:
Array
(
[blah1] =>
[blah2] => Look at this:
)
--
Edit this bug report at http://bugs.php.net/?id=28004&edit=1
#27986 [Fbk->Opn]: make errors still persist
ID: 27986 User updated by: sandduneinfo at earthlink dot net -Summary: make errors Reported By: sandduneinfo at earthlink dot net -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.5 New Comment: Even wthe the "lastest" the make failed. Errors as follows: "/tmp/php4-STABLE-200404150030/ext/standard/array.c", line 1723.64: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/ext/standard/file.c", line 918.100: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/ext/standard/file.c", line 924.114: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/ext/standard/info.c", line 480.122: 1506-280 (W) Function argument assignment between types "unsigned int*" and "int*" is not allowed. "/tmp/php4-STABLE-200404150030/main/safe_mode.c", line 84.31: 1506-280 (W) Function argument assignment between types "unsigned char*" and "const unsigned char*" is not allowed. "/tmp/php4-STABLE-200404150030/main/safe_mode.c", line 125.39: 1506-280 (W) Function argument assignment between types "unsigned char*" and "const unsigned char*" is not allowed. cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix cc: 1501-218 file ext/mysql/php_mysql.lo contains an incorrect file suffix cc: 1501-218 file ext/overload/overload.lo contains an incorrect file suffix cc: 1501-218 file ext/pcre/pcrelib/maketables.lo contains an incorrect file suffix cc: 1501-218 file ext/pcre/pcrelib/get.lo contains an incorrect file suffix cc: 1501-218 file ext/pcre/pcrelib/study.lo contains an incorrect file suffix cc: 1501-218 file ext/pcre/pcrelib/pcre.lo contains an incorrect file suffix cc: 1501-218 file ext/pcre/php_pcre.lo contains an incorrect file suffix cc: 1501-218 file ext/posix/posix.lo contains an incorrect file suffix cc: 1501-218 file ext/session/session.lo contains an incorrect file suffix cc: 1501-218 file ext/session/mod_files.lo contains an incorrect file suffix cc: 1501-218 file ext/session/mod_mm.lo contains an incorrect file suffix cc: 1501-218 file ext/session/mod_user.lo contains an incorrect file suffix cc: 1501-218 file regex/regcomp.lo contains an incorrect file suffix cc: 1501-218 file regex/regexec.lo contains an incorrect file suffix cc: 1501-218 file regex/regerror.lo contains an incorrect file suffix cc: 1501-218 file regex/regfree.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/array.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/base64.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/basic_functions.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/browscap.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/crc32.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/crypt.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/cyr_convert.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/datetime.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/dir.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/dl.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/dns.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/exec.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/file.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/filestat.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/flock_compat.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/formatted_print.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/fsock.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/head.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/html.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/image.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/info.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/iptc.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/lcg.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/link.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/mail.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/math.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/md5.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/metaphone.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/microtime.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/pack.lo contains an incorrect file suffix cc: 1501-218 file ext/st
#27994 [Opn->Asn]: segfault with Soapserver when WSDL-Cache is enabled
ID: 27994
Updated by: [EMAIL PROTECTED]
Reported By: waechter at avalus dot de
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: linux 2.4.18
PHP Version: 5.0.0RC1
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2004-04-15 08:40:48] waechter at avalus dot de
okay, I found somewhat interesting:
the segfault happens, when i try to use an unknown datatype inside the
wsdl. in my case, i used xsd:base64binary instead of xsd:base64Binary
(case-sensitiv)...
do you still need the sourcecode?
and those extra empty lines in the BT... sorry, i don't know where
these came from!?
[2004-04-15 06:34:24] [EMAIL PROTECTED]
I need full example (including wsdl file) to reproduce the BUG.
[2004-04-14 22:25:04] [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
..and why did you add those extra empty lines in the backtrace?!?!?!
[2004-04-14 12:10:23] waechter at avalus dot de
Description:
when wsdl-cache is enabled, the first call to soapserver works fine,
but when the cached wsdl is beeing used (eg when it has not been
written or ttl has reached), it will produce a segfault
Reproduce code:
---
configure line:
/configure
--with-apxs2filter=/usr/local/apache2/bin/apxs
--with-libxml-dir=../libxml2-2.6.7
--enable-soap
--enable-debug
php.ini:
soap.wsdl_cache_dir = /path/to/wsdl/cache
soap.wsdl_cache_enabled = 1
soap.wsdl_cache_ttl = 120
server-script:
addFunction("someFunction");
$server->handle();
?>
client-script:
http://url/to/wsdl.de";);
$client->someFunction(array(
"param1" => "value1",
"param2" => "value")
);
?>
Expected result:
no segfault ;-)
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 31697)]
sdl_guess_convert_xml (enc=0x408d09c0, data=0x408e6858, style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2417
2417switch(type->kind) {
(gdb) bt
#0 sdl_guess_convert_xml (enc=0x408d09c0, data=0x408e6858, style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2417
#1 0x4035a1cc in master_to_xml (encode=0x408d09c0, data=0x408e6858,
style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#2 0x4035c024 in model_to_xml_object (node=0x83ac150,
model=0x408d7530,
prop=0x408e56c0, style=1, strict=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1045
#3 0x4035c13d in model_to_xml_object (node=0x83ac150,
model=0x408d6ec8,
prop=0x408e56c0, style=1, strict=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1074
#4 0x4035c714 in to_xml_object (type=0x408d0a28, data=0x408e6810,
style=1,
parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1244
#5 0x403612ff in sdl_guess_convert_xml (enc=0x408d0a28,
data=0x408e6810,
style=1, parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2439
#6 0x4035a1cc in master_to_xml (encode=0x408d0a28, data=0x408e6810,
style=1,
parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#7 0x4035ce38 in add_xml_array_elements (xmlParam=0x83ac058, type=0x0,
enc=0x408d0a28, ns=0x83a9038, dimension=1, dims=0x408e3f00,
data=0x408e4418, style=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1454
#8 0x4035eed6 in to_xml_array (type=0x408d0958, data=0x408e4418,
style=1,
parent=0x83ab710)
#27994 [Fbk->Opn]: segfault with Soapserver when WSDL-Cache is enabled
ID: 27994
User updated by: waechter at avalus dot de
Reported By: waechter at avalus dot de
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: linux 2.4.18
PHP Version: 5.0.0RC1
New Comment:
okay, I found somewhat interesting:
the segfault happens, when i try to use an unknown datatype inside the
wsdl. in my case, i used xsd:base64binary instead of xsd:base64Binary
(case-sensitiv)...
do you still need the sourcecode?
and those extra empty lines in the BT... sorry, i don't know where
these came from!?
Previous Comments:
[2004-04-15 06:34:24] [EMAIL PROTECTED]
I need full example (including wsdl file) to reproduce the BUG.
[2004-04-14 22:25:04] [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
..and why did you add those extra empty lines in the backtrace?!?!?!
[2004-04-14 12:10:23] waechter at avalus dot de
Description:
when wsdl-cache is enabled, the first call to soapserver works fine,
but when the cached wsdl is beeing used (eg when it has not been
written or ttl has reached), it will produce a segfault
Reproduce code:
---
configure line:
/configure
--with-apxs2filter=/usr/local/apache2/bin/apxs
--with-libxml-dir=../libxml2-2.6.7
--enable-soap
--enable-debug
php.ini:
soap.wsdl_cache_dir = /path/to/wsdl/cache
soap.wsdl_cache_enabled = 1
soap.wsdl_cache_ttl = 120
server-script:
addFunction("someFunction");
$server->handle();
?>
client-script:
http://url/to/wsdl.de";);
$client->someFunction(array(
"param1" => "value1",
"param2" => "value")
);
?>
Expected result:
no segfault ;-)
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 31697)]
sdl_guess_convert_xml (enc=0x408d09c0, data=0x408e6858, style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2417
2417switch(type->kind) {
(gdb) bt
#0 sdl_guess_convert_xml (enc=0x408d09c0, data=0x408e6858, style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2417
#1 0x4035a1cc in master_to_xml (encode=0x408d09c0, data=0x408e6858,
style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#2 0x4035c024 in model_to_xml_object (node=0x83ac150,
model=0x408d7530,
prop=0x408e56c0, style=1, strict=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1045
#3 0x4035c13d in model_to_xml_object (node=0x83ac150,
model=0x408d6ec8,
prop=0x408e56c0, style=1, strict=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1074
#4 0x4035c714 in to_xml_object (type=0x408d0a28, data=0x408e6810,
style=1,
parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1244
#5 0x403612ff in sdl_guess_convert_xml (enc=0x408d0a28,
data=0x408e6810,
style=1, parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2439
#6 0x4035a1cc in master_to_xml (encode=0x408d0a28, data=0x408e6810,
style=1,
parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#7 0x4035ce38 in add_xml_array_elements (xmlParam=0x83ac058, type=0x0,
enc=0x408d0a28, ns=0x83a9038, dimension=1, dims=0x408e3f00,
data=0x408e4418, style=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1454
#8 0x4035eed6 in to_xml_array (type=0x408d0958, data=0x408e4418,
style=1,
parent=0x83ab710)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1688
#9 0x403612ea in sdl_guess_convert_xml (enc=0x408d0958,
data=0x40
#28004 [Bgs->Opn]: Post data weirdly disappearing when stored in a session
ID: 28004
User updated by: kevin at cayenne dot co dot uk
Reported By: kevin at cayenne dot co dot uk
-Status: Bogus
+Status: Open
Bug Type: Session related
Operating System: Gentoo Linux
PHP Version: 4.3.6RC3
New Comment:
I don't think that it's anything to do with cookies etc; all other
session stuff works fine (I can add other session variables, initiate a
different session) and if I delete the file from /tmp/ and/or the
cookie from my browser then a new session gets started properly.
The main reason why I think it's a scripting engine bug is that the
behaviour of the script changes depending upon the @import line. This
shouldn't have anything to do with PHP, it's an instruction to my
browser, yet the PHP behaves differently for these two lines:
@import url(); (PHP session does not work properly)
@import url("nothing.css"); (PHP session works)
These lines are not in a PHP tag, or a PHP { } block, and the weird
behaviour still exists whether I have output buffering on or not. The
session output being printed to my browser is different to what's being
written to the /tmp/ file; surely that's a bug?
Previous Comments:
[2004-04-15 08:15:25] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Yes, any "outside" stuff can and will affect this since it can disable
sending some cookie, etc. Ask further support questions elsewhere.
[2004-04-15 06:57:27] kevin at cayenne dot co dot uk
I forgot to mention, due to limitations at my work I have only tested
this on 4.3.6RC2 but there was no option for that on the drop-down. I
have also experienced this bug on 4.2.3 at another site.
[2004-04-15 06:54:17] kevin at cayenne dot co dot uk
Description:
Provided is the source for 3 files: bug0.html submits a form to
bug1.html, which then stores the post'd data in a session. A form in
bug1.html submits to bug2.html (with no post variables), but the
session data is blank where it should have contained the post data from
bug0.html (this is more clear if you read the source code). If the
session is inspected in bug1.html, it is as expected, however the file
written to /tmp/ is not.
The weird thing is this: there is a style tag in bug1.html which
contains a line "@import url()". This is outside the PHP, and
shouldn't affect anything to do with the PHP parsing / running. If the
@import line is removed, the session data gets written properly.
If a better explanation / demo is needed, please feel free to ask.
Reproduce code:
---
bug0.html:
bug1.html:
@import url();
";print_r($_SESSION);echo "";
?>
bug2.html:
";print_r($_SESSION);exit;
?>
Expected result:
In bug1.html:
Array
(
[blah1] => baa baa black sheep
[blah2] => Look at this: baa baa black sheep
)
In bug2.html:
Array
(
[blah1] => baa baa black sheep
[blah2] => Look at this: baa baa black sheep
)
Actual result:
--
In bug1.html:
Array
(
[blah1] => baa baa black sheep
[blah2] => Look at this: baa baa black sheep
)
In bug2.html:
Array
(
[blah1] =>
[blah2] => Look at this:
)
--
Edit this bug report at http://bugs.php.net/?id=28004&edit=1
#28000 [Opn->Bgs]: aolserver critical crash
ID: 28000 Updated by: [EMAIL PROTECTED] Reported By: ustaz99 at catcha dot com -Status: Open +Status: Bogus Bug Type: PostgreSQL related Operating System: Linux MDK10.0 PHP Version: 4.3.5 New Comment: >From the sapi/aolserver/README: "Note that there might be thread-safety issues with thread-unsafe libraries/extensions. Test thoroughly before you put anything into production." (this is pretty much impossible to tell what might be going wrong. Just use Apache 1.3.29 and you're fine.) Previous Comments: [2004-04-14 22:56:24] ustaz99 at catcha dot com with php-4.3.7dev './configure' '--with-aolserver=/usr/local/aolserver/' '--with-pgsql' '--enable-debug' output console [New Thread 1088641968 (LWP 14525)] [New Thread 1088711600 (LWP 14526)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1088641968 (LWP 14525)] 0x40c138e1 in execute (op_array=0x864b078, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:1266 1266 zend_fetch_var_address(EX(opline), EX(Ts), BP_VAR_W TSRMLS_CC); (gdb) i r eax0x80c76c8135034568 ecx0x810b050135311440 edx0x864b078140816504 ebx0x40c5ce3c 1086705212 esp0x40e25fb0 0x40e25fb0 ebp0x40e30a68 0x40e30a68 esi0x40e5d030 1088802864 edi0x40e5d030 1088802864 eip0x40c138e1 0x40c138e1 eflags 0x210207 2163207 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x40c138e1 in execute (op_array=0x864b078, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:1266 #1 0x40c18d53 in execute (op_array=0x864f258, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:2200 #2 0x40c18d53 in execute (op_array=0x864a0e8, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/Zend/zend_execute.c:2200 #3 0x40c05cf0 in zend_execute_scripts (type=8, tsrm_ls=0x80c76c8, retval=Variable "retval" is not available. ) at /root/php4-STABLE-200404150030/Zend/zend.c:886 #4 0x40bd3204 in php_execute_script (primary_file=0x40e35800, tsrm_ls=0x80c76c8) at /root/php4-STABLE-200404150030/main/main.c:1731 #5 0x40c1b609 in php_ns_module_main (tsrm_ls=Variable "tsrm_ls" is not available. ) at /root/php4-STABLE-200404150030/sapi/aolserver/aolserver.c:419 #6 0x40c1b985 in php_ns_request_handler (context=0x80c7698, conn=Variable "conn" is not available. ) at /root/php4-STABLE-200404150030/sapi/aolserver/aolserver.c:503 #7 0x4003a152 in Ns_ConnRunRequest () from /usr/local/aolserver/lib/libnsd.so #8 0x4003b9d6 in ConnRun () from /usr/local/aolserver/lib/libnsd.so #9 0x4003b660 in NsConnThread () from /usr/local/aolserver/lib/libnsd.so #10 0x40067c18 in NsThreadMain () from /usr/local/aolserver/lib/libnsthread.so #11 0x4006914a in ThreadMain () from /usr/local/aolserver/lib/libnsthread.so #12 0x401227d3 in start_thread () from /lib/tls/libpthread.so.0 #13 0x4023ab4a in clone () from /lib/tls/libc.so.6 [2004-04-14 22:28:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip ..and configure PHP with --enable debug and get us a proper backtrace (with GDB command 'bt') [2004-04-14 22:11:27] ustaz99 at catcha dot com Description: entering username=apache password=apache make my aolserver crash with phpPgAdmin-3.3.1 './configure' '--with-aolserver=/usr/local/aolserver/' '--with-pgsql' # aolserver-4.01 # php-4.3.5 Reproduce code: --- entering success login phpPgAdmin-3.3.1 script Expected result: (gdb) r -f -t /usr/local/aolserver/bin/config.tcl -u apache -g apache Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1088555952 (LWP 3368)] 0x40c00d60 in execute (op_array=0x81e33a4, tsrm_ls=0x80c7390) at /root/php-4.3.5/Zend/zend_execute.c:1252 1252 zend_fetch_var_address(EX(opline), EX(Ts), BP_VAR_W TSRMLS_CC); (gdb) i r eax0x80c7390135033744 ecx0x82040cc136331468 edx0x40e1b9d4 1088534996 ebx0x40c47f1c 1086619420 esp0x40e10f50 0x40e10f50 ebp0x40e1ba28 0x40e
#28004 [Opn->Bgs]: Post data weirdly disappearing when stored in a session
ID: 28004 Updated by: [EMAIL PROTECTED] Reported By: kevin at cayenne dot co dot uk -Status: Open +Status: Bogus -Bug Type: Scripting Engine problem +Bug Type: Session related Operating System: Gentoo Linux PHP Version: 4.3.6RC3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Yes, any "outside" stuff can and will affect this since it can disable sending some cookie, etc. Ask further support questions elsewhere. Previous Comments: [2004-04-15 06:57:27] kevin at cayenne dot co dot uk I forgot to mention, due to limitations at my work I have only tested this on 4.3.6RC2 but there was no option for that on the drop-down. I have also experienced this bug on 4.2.3 at another site. [2004-04-15 06:54:17] kevin at cayenne dot co dot uk Description: Provided is the source for 3 files: bug0.html submits a form to bug1.html, which then stores the post'd data in a session. A form in bug1.html submits to bug2.html (with no post variables), but the session data is blank where it should have contained the post data from bug0.html (this is more clear if you read the source code). If the session is inspected in bug1.html, it is as expected, however the file written to /tmp/ is not. The weird thing is this: there is a style tag in bug1.html which contains a line "@import url()". This is outside the PHP, and shouldn't affect anything to do with the PHP parsing / running. If the @import line is removed, the session data gets written properly. If a better explanation / demo is needed, please feel free to ask. Reproduce code: --- bug0.html: bug1.html: @import url(); ";print_r($_SESSION);echo ""; ?> bug2.html: ";print_r($_SESSION);exit; ?> Expected result: In bug1.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) In bug2.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) Actual result: -- In bug1.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) In bug2.html: Array ( [blah1] => [blah2] => Look at this: ) -- Edit this bug report at http://bugs.php.net/?id=28004&edit=1
#28006 [Opn->Fbk]: referencing an unset global produces a segfault
ID: 28006
Updated by: [EMAIL PROTECTED]
Reported By: per at computer dot org
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: linux, kernel 2.4.24
PHP Version: 4.3.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2004-04-15 07:36:22] per at computer dot org
Description:
Hi,
I've got a situation where a seemingly innocent statement
produces a
segfault. I've tried reducing it to a single reproducable
testcase, but
without
success. The problem is however solidly reproducable in the
context in which it occurs.
I'm certain it is caused by a mistake in my code, but I
feel it isn't
exactly appropriate for php to segfault because of a user
error?
Very briefly, this is an excerpt where the segfault occurs:
";
$result=mysql_query( $q ) or die("mysql:".mysql_error());
$main_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$billing_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$technical_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$editmain=strcasecmp($_REQUEST['contact'],"main")==0;
//
$editbilling=strcasecmp($_REQUEST['contact'],"billing")==0;
//
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0;
?>
If I uncomment either of the last 2 commented-out
statements, I get a segfault.
I'm using php 4.3.4 and apache 2.0.49 on linux 2.4.24.
mysql is 4.0.15.
---
OK,
I've now guarded the above with :
if ( isset($_REQUEST['contact']) )
{
$editmain=strcmp($_REQUEST['contact'],"main")==0;
$editbilling=strcmp($_REQUEST['contact'],"billing")==0;
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0;
}
and the segfault is
gone. Still, a segfault just because I'm using an unset
global? And why only on the 2nd or later statement?
Actual result:
--
(gdb) run -X -f /etc/httpd/httpd.conf
Starting program: /usr/bin/httpd -X -f /etc/httpd/
httpd.conf
[New Thread 16384 (LWP 9121)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9121)]
0x40576622 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute_API.c:271
271 return active_opline->lineno;
(gdb) bt
#0 0x40576622 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute_API.c:271
#1 0x4057ec6d in zend_error (type=8, format=0x40706ea3
"Undefined index: %s") at /usr/src/packages/SOURCES/
php-4.3.4/Zend/zend.c:731
#2 0x405914a0 in zend_fetch_dimension_address_inner
(ht=0x81d4bf4, op2=0x821ed34, Ts=0xbfffb34c, type=0) at /
usr/src/packages/SOURCES/php-4.3.4/Zend/zend_execute.c:636
#3 0x4058a5f0 in zend_fetch_dimension_address
(result=0x821ed14, op1=0x81d4bd4, op2=0x821ed34,
Ts=0xbfffb34c, type=0) at /usr/src/packages/SOURCES/
php-4.3.4/Zend/zend_execute.c:787
#4 0x4058f7fe in execute (op_array=0x81d4f2c) at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute.c:1283
#5 0x4057edbb in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/packages/SOURCES/php-4.3.4/Zend/
zend.c:884
#6 0x40552f3f in php_execute_script
(primary_file=0xb3d0) at /usr/src/packages/SOURCES/
php-4.3.4/main/main.c:1729
#7 0x405923b8 in php_handler (r=0x81ef8f8) at /usr/src/
packages/SOURCES/php-4.3.4/sapi/apache2handler/
sapi_apache2.c:537
#8 0x08092d85 in ap_run_handler (r=0x81ef8f8) at
config.c:151
#9 0x08093390 in ap_invoke_handler (r=0x81ef8f8) at
config.c:358
#10 0x08076edb in ap_process_request (r=0x81ef8f8) at
http_request.c:246
#11 0x0807239d in ap_process_http_connection (c=0x81b5000)
at http_core.c:250
#12 0x0809de25 in ap_run_process_connection (c=0x81b5000)
at connection.c:42
#13 0x08091384 in child_main (child_num_arg=0) at
prefork.c:609
#14 0x0809159b in make_child (s=0x0, slot=0) at
prefork.c:649
#15 0x080915f8 in startup_children (number_to_start=5) at
prefork.c:721
#16 0x08091e6a in ap_mpm_run (_pconf=0x80d6310,
plog=0x8116410, s=0x80d9dd0) at prefork.c:940
#17 0x080983bd in main (argc=4, argv=0xb744) at
main.c:617
--
Edit this bug report at http://bugs.php.net/?id=28006&edit=1
#28006 [NEW]: referencing an unset global produces a segfault
From: per at computer dot org
Operating system: linux, kernel 2.4.24
PHP version: 4.3.4
PHP Bug Type: Reproducible crash
Bug description: referencing an unset global produces a segfault
Description:
Hi,
I've got a situation where a seemingly innocent statement
produces a
segfault. I've tried reducing it to a single reproducable
testcase, but
without
success. The problem is however solidly reproducable in the
context in which it occurs.
I'm certain it is caused by a mistake in my code, but I
feel it isn't
exactly appropriate for php to segfault because of a user
error?
Very briefly, this is an excerpt where the segfault occurs:
";
$result=mysql_query( $q ) or die("mysql:".mysql_error());
$main_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$billing_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$q="";
$result=mysql_query( $q ) or die(mysql_error());
$technical_address=mysql_fetch_array( $result, MYSQL_ASSOC );
$editmain=strcasecmp($_REQUEST['contact'],"main")==0;
//
$editbilling=strcasecmp($_REQUEST['contact'],"billing")==0;
//
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0;
?>
If I uncomment either of the last 2 commented-out
statements, I get a segfault.
I'm using php 4.3.4 and apache 2.0.49 on linux 2.4.24.
mysql is 4.0.15.
---
OK,
I've now guarded the above with :
if ( isset($_REQUEST['contact']) )
{
$editmain=strcmp($_REQUEST['contact'],"main")==0;
$editbilling=strcmp($_REQUEST['contact'],"billing")==0;
$edittechnical=strcasecmp($_REQUEST['contact'],"technical")==0;
}
and the segfault is
gone. Still, a segfault just because I'm using an unset
global? And why only on the 2nd or later statement?
Actual result:
--
(gdb) run -X -f /etc/httpd/httpd.conf
Starting program: /usr/bin/httpd -X -f /etc/httpd/
httpd.conf
[New Thread 16384 (LWP 9121)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9121)]
0x40576622 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute_API.c:271
271 return active_opline->lineno;
(gdb) bt
#0 0x40576622 in zend_get_executed_lineno () at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute_API.c:271
#1 0x4057ec6d in zend_error (type=8, format=0x40706ea3
"Undefined index: %s") at /usr/src/packages/SOURCES/
php-4.3.4/Zend/zend.c:731
#2 0x405914a0 in zend_fetch_dimension_address_inner
(ht=0x81d4bf4, op2=0x821ed34, Ts=0xbfffb34c, type=0) at /
usr/src/packages/SOURCES/php-4.3.4/Zend/zend_execute.c:636
#3 0x4058a5f0 in zend_fetch_dimension_address
(result=0x821ed14, op1=0x81d4bd4, op2=0x821ed34,
Ts=0xbfffb34c, type=0) at /usr/src/packages/SOURCES/
php-4.3.4/Zend/zend_execute.c:787
#4 0x4058f7fe in execute (op_array=0x81d4f2c) at /usr/src/
packages/SOURCES/php-4.3.4/Zend/zend_execute.c:1283
#5 0x4057edbb in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/packages/SOURCES/php-4.3.4/Zend/
zend.c:884
#6 0x40552f3f in php_execute_script
(primary_file=0xb3d0) at /usr/src/packages/SOURCES/
php-4.3.4/main/main.c:1729
#7 0x405923b8 in php_handler (r=0x81ef8f8) at /usr/src/
packages/SOURCES/php-4.3.4/sapi/apache2handler/
sapi_apache2.c:537
#8 0x08092d85 in ap_run_handler (r=0x81ef8f8) at
config.c:151
#9 0x08093390 in ap_invoke_handler (r=0x81ef8f8) at
config.c:358
#10 0x08076edb in ap_process_request (r=0x81ef8f8) at
http_request.c:246
#11 0x0807239d in ap_process_http_connection (c=0x81b5000)
at http_core.c:250
#12 0x0809de25 in ap_run_process_connection (c=0x81b5000)
at connection.c:42
#13 0x08091384 in child_main (child_num_arg=0) at
prefork.c:609
#14 0x0809159b in make_child (s=0x0, slot=0) at
prefork.c:649
#15 0x080915f8 in startup_children (number_to_start=5) at
prefork.c:721
#16 0x08091e6a in ap_mpm_run (_pconf=0x80d6310,
plog=0x8116410, s=0x80d9dd0) at prefork.c:940
#17 0x080983bd in main (argc=4, argv=0xb744) at
main.c:617
--
Edit bug report at http://bugs.php.net/?id=28006&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28006&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28006&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28006&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28006&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28006&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28006&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28006&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28006&
#28005 [NEW]: use of per class constants
From: e dot vandeoudeweetering at marcanti dot esprit-sg dot nl Operating system: windows2000 (5.00.2195) sp4 PHP version: 5.0.0RC1 PHP Bug Type: Class/Object related Bug description: use of per class constants Description: This bug is related to: Bug #27523 It is not possible to use a class constant, without a reference to its OWN class! see reproduce code: Another problem is that the function returns the name of the constant instead of it's value! Reproduce code: --- printConst(); ?> Expected result: The following output should be printed: const Test::TEMP = hi const TEMP = hi Actual result: -- const Test::TEMP = hi PHP Notice: Use of undefined constant TEMP - assumed 'TEMP' in C:\Temp\test.php on line 8 const TEMP = TEMP -- Edit bug report at http://bugs.php.net/?id=28005&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28005&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28005&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28005&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28005&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28005&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28005&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28005&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28005&r=support Expected behavior: http://bugs.php.net/fix.php?id=28005&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28005&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28005&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28005&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28005&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28005&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28005&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28005&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28005&r=float
#28004 [Opn]: Post data weirdly disappearing when stored in a session
ID: 28004 User updated by: kevin at cayenne dot co dot uk Reported By: kevin at cayenne dot co dot uk Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.3.6RC3 New Comment: I forgot to mention, due to limitations at my work I have only tested this on 4.3.6RC2 but there was no option for that on the drop-down. I have also experienced this bug on 4.2.3 at another site. Previous Comments: [2004-04-15 06:54:17] kevin at cayenne dot co dot uk Description: Provided is the source for 3 files: bug0.html submits a form to bug1.html, which then stores the post'd data in a session. A form in bug1.html submits to bug2.html (with no post variables), but the session data is blank where it should have contained the post data from bug0.html (this is more clear if you read the source code). If the session is inspected in bug1.html, it is as expected, however the file written to /tmp/ is not. The weird thing is this: there is a style tag in bug1.html which contains a line "@import url()". This is outside the PHP, and shouldn't affect anything to do with the PHP parsing / running. If the @import line is removed, the session data gets written properly. If a better explanation / demo is needed, please feel free to ask. Reproduce code: --- bug0.html: bug1.html: @import url(); ";print_r($_SESSION);echo ""; ?> bug2.html: ";print_r($_SESSION);exit; ?> Expected result: In bug1.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) In bug2.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) Actual result: -- In bug1.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) In bug2.html: Array ( [blah1] => [blah2] => Look at this: ) -- Edit this bug report at http://bugs.php.net/?id=28004&edit=1
#28004 [NEW]: Post data weirdly disappearing when stored in a session
From: kevin at cayenne dot co dot uk Operating system: Gentoo Linux PHP version: 4.3.6RC3 PHP Bug Type: Scripting Engine problem Bug description: Post data weirdly disappearing when stored in a session Description: Provided is the source for 3 files: bug0.html submits a form to bug1.html, which then stores the post'd data in a session. A form in bug1.html submits to bug2.html (with no post variables), but the session data is blank where it should have contained the post data from bug0.html (this is more clear if you read the source code). If the session is inspected in bug1.html, it is as expected, however the file written to /tmp/ is not. The weird thing is this: there is a style tag in bug1.html which contains a line "@import url()". This is outside the PHP, and shouldn't affect anything to do with the PHP parsing / running. If the @import line is removed, the session data gets written properly. If a better explanation / demo is needed, please feel free to ask. Reproduce code: --- bug0.html: bug1.html: @import url(); ";print_r($_SESSION);echo ""; ?> bug2.html: ";print_r($_SESSION);exit; ?> Expected result: In bug1.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) In bug2.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) Actual result: -- In bug1.html: Array ( [blah1] => baa baa black sheep [blah2] => Look at this: baa baa black sheep ) In bug2.html: Array ( [blah1] => [blah2] => Look at this: ) -- Edit bug report at http://bugs.php.net/?id=28004&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28004&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28004&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28004&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28004&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28004&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28004&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28004&r=support Expected behavior: http://bugs.php.net/fix.php?id=28004&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28004&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28004&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28004&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28004&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28004&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28004&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28004&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28004&r=float
#27994 [Fbk]: segfault with Soapserver when WSDL-Cache is enabled
ID: 27994
Updated by: [EMAIL PROTECTED]
Reported By: waechter at avalus dot de
Status: Feedback
Bug Type: SOAP related
Operating System: linux 2.4.18
PHP Version: 5.0.0RC1
New Comment:
I need full example (including wsdl file) to reproduce the BUG.
Previous Comments:
[2004-04-14 22:25:04] [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
..and why did you add those extra empty lines in the backtrace?!?!?!
[2004-04-14 12:10:23] waechter at avalus dot de
Description:
when wsdl-cache is enabled, the first call to soapserver works fine,
but when the cached wsdl is beeing used (eg when it has not been
written or ttl has reached), it will produce a segfault
Reproduce code:
---
configure line:
/configure
--with-apxs2filter=/usr/local/apache2/bin/apxs
--with-libxml-dir=../libxml2-2.6.7
--enable-soap
--enable-debug
php.ini:
soap.wsdl_cache_dir = /path/to/wsdl/cache
soap.wsdl_cache_enabled = 1
soap.wsdl_cache_ttl = 120
server-script:
addFunction("someFunction");
$server->handle();
?>
client-script:
http://url/to/wsdl.de";);
$client->someFunction(array(
"param1" => "value1",
"param2" => "value")
);
?>
Expected result:
no segfault ;-)
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 31697)]
sdl_guess_convert_xml (enc=0x408d09c0, data=0x408e6858, style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2417
2417switch(type->kind) {
(gdb) bt
#0 sdl_guess_convert_xml (enc=0x408d09c0, data=0x408e6858, style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2417
#1 0x4035a1cc in master_to_xml (encode=0x408d09c0, data=0x408e6858,
style=1,
parent=0x83ac150)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#2 0x4035c024 in model_to_xml_object (node=0x83ac150,
model=0x408d7530,
prop=0x408e56c0, style=1, strict=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1045
#3 0x4035c13d in model_to_xml_object (node=0x83ac150,
model=0x408d6ec8,
prop=0x408e56c0, style=1, strict=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1074
#4 0x4035c714 in to_xml_object (type=0x408d0a28, data=0x408e6810,
style=1,
parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1244
#5 0x403612ff in sdl_guess_convert_xml (enc=0x408d0a28,
data=0x408e6810,
style=1, parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2439
#6 0x4035a1cc in master_to_xml (encode=0x408d0a28, data=0x408e6810,
style=1,
parent=0x83ac058)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#7 0x4035ce38 in add_xml_array_elements (xmlParam=0x83ac058, type=0x0,
enc=0x408d0a28, ns=0x83a9038, dimension=1, dims=0x408e3f00,
data=0x408e4418, style=1)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1454
#8 0x4035eed6 in to_xml_array (type=0x408d0958, data=0x408e4418,
style=1,
parent=0x83ab710)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:1688
#9 0x403612ea in sdl_guess_convert_xml (enc=0x408d0958,
data=0x408e4418,
style=1, parent=0x83ab710)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:2437
#10 0x4035a1cc in master_to_xml (encode=0x408d0958, data=0x408e4418,
style=1,
parent=0x83ab710)
at /home/lbr/serverSoft/php-5.0.0RC1/ext/soap/php_encoding.c:304
#11 0x4035c024 in model_to_xml_object (node=0x83ab710,
mod
#27681 [Asn->Csd]: soap extension fails without HAVE_TM_GMTOFF
ID: 27681
Updated by: [EMAIL PROTECTED]
Reported By: jwm at horde dot net
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: Solaris 8
PHP Version: 5.0.0RC1
Assigned To: dmitry
New Comment:
Fixed in 5.0.0RC2-dev CVS.
Please, verify me on Solaris.
Previous Comments:
[2004-04-07 11:16:01] [EMAIL PROTECTED]
Assigned to the maintainer.
[2004-03-24 16:43:05] jwm at horde dot net
Description:
The soap extension fails to build (undefined variables)
on Solaris 8 because the !HAVE_TM_GMTOFF case requires
tzone, which is not defined. This (perhaps naive) patch
fixes the build, but I haven't tested it:
--- ext/soap/php_encoding.c~2004-03-20 17:10:
22.646093000 -0500
+++ ext/soap/php_encoding.c 2004-03-20 17:10:
22.656085000 -0500
@@ -2119,6 +2119,7 @@
size_t buf_len=64, real_len;
char *buf;
char tzbuf[6];
+ long tzone;
xmlNodePtr xmlParam;
@@ -2130,7 +2131,13 @@
timestamp = Z_LVAL_P(data);
ta = php_localtime_r(×tamp,
&tmbuf);
/*ta = php_gmtime_r(×tamp, &tmbuf);
*/
-
+#if !HAVE_TM_GMTOFF
+#ifdef __CYGWIN__
+ tzone = _timezone;
+#else
+ tzone = timezone;
+#endif
+#endif
buf = (char *) emalloc(buf_len);
while ((real_len = strftime(buf,
buf_len, format, ta)) == buf_len || real_len == 0) {
buf_len *= 2;
--
Edit this bug report at http://bugs.php.net/?id=27681&edit=1
#28002 [Asn->Bgs]: Soap depends on session
ID: 28002 Updated by: [EMAIL PROTECTED] Reported By: schick at robotbattle dot com -Status: Assigned +Status: Bogus Bug Type: Compile Failure Operating System: Debian GNU/Linux (sarge) PHP Version: 5.0.0RC1 Assigned To: dmitry New Comment: It works fine. Did you make full rebuild? make clean make Previous Comments: [2004-04-15 03:28:11] [EMAIL PROTECTED] Assigning to the maintainer. [2004-04-15 02:10:12] schick at robotbattle dot com Description: Soap extensions seems to depend on session support. Running configure with --disable-session and --enable-soap causes the build to fail with the following: ext/soap/soap.lo(.text+0x3a22): In function `zif_soapserver_handle': /var/src/php-5.0.0RC1/ext/soap/soap.c:1391: undefined reference to `ps_globals' ext/soap/soap.lo(.text+0x3b6a):/var/src/php-5.0.0RC1/ext/soap/soap.c:1342: undefined reference to `ps_globals' ext/soap/soap.lo(.text+0x3bc0):/var/src/php-5.0.0RC1/ext/soap/soap.c:1344: undefined reference to `php_session_start' Reproduce code: --- This is my config: './configure' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-pgsql=/usr/lib/postgresql' \ '--without-sqlite' \ '--disable-session' \ '--enable-soap' \ '--enable-mbstring' \ '--enable-magic-quotes' \ '--enable-memory-limit' \ '--with-zlib-dir=/usr/lib' \ '--enable-force-cgi-redirect' \ '--disable-ipv6' \ '--with-openssl=/usr' \ '--with-mcrypt' \ '--with-imap=/usr' \ '--with-kerberos' \ '--disable-debug' \ '--with-curl=/usr' \ '--with-gd' \ '--with-png-dir=/usr/lib' \ "$@" -- Edit this bug report at http://bugs.php.net/?id=28002&edit=1
#18169 [Com]: Driver cannot deliver UCS-2 unicode to SQL Server
ID: 18169
Comment by: samlinxp at msn dot com
Reported By: joesterg at hotmail dot com
Status: No Feedback
Bug Type: MSSQL related
Operating System: Windows 2000 Server
PHP Version: 4.1.2
New Comment:
I have the same problem.
My setup is:
Windows XP Server, with Apache 2.0.47/PHP 4.3.6RC3 and Microsoft SQL
Server 2000
Hope this problem can be solved soon. This is quite important
especially at Asia Pacific's regions (CHN, HK, TW, JP, KR.. etc)
Previous Comments:
[2003-06-29 21:33:00] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2002-12-18 18:18:47] fvu at wanadoo dot nl
If you're using PHP on a Windows platform you can use the PHP COM
extension to communicate with SQL Server via ADO. The PHP COM
extension is capable of translating UTF-8 to UCS-2 and back if you
specify so as the third parameter:
$oDb = new COM('ADODB.Connection', NULL, CP_UTF8);
This way you can use Unicode UTF-8 within PHP and Unicode UCS-2 within
SQL Server with all the translations done for you automatically.
HTH, Freddy Vulto
[2002-07-06 07:08:48] joesterg at hotmail dot com
Thanks Marko
-I guess this means that if you are to use binary (ie. unicode) data,
then COM/ADO is your only option, if SQL Server is the database of your
choice.
>From yohgaki's answer, I guess also the multibyte encoding
functionality lacks proper Unicode support -am I correct in assuming
that we will have to move to PHP4.2.x and do our own encoding/decoding
through the Win32 API then?
[2002-07-05 05:34:22] [EMAIL PROTECTED]
PHP's mssql extension uses the Microsoft SQL Server's C
API, the "DB-Library for C". Specifically, SQL queries are
sent to the server using the dbcmd() function. This
function is not binary safe, so inserting UCS2 text or
images or any binary data is likely to fail.
The DB-Library for C has separate, binary-safe APIs for
entering text and images, but they are complicated and
difficult to seamlessly integrate to the current mssql
extension. Look up the documentation for dbwritetext() if
you feel like implementing this change.
UTF-8 and UTF-7 are, IIRC, the only Unicode encoding that
are guaranteed not to include null characters. They are,
therefore, the only encodings that can be reliably used
with PHP's mssql extension at this time.
[2002-07-05 04:21:52] joesterg at hotmail dot com
You are probably right. However, Unicode is central to making
world-wide web applications, and all major database vendors have this
posibility.
I find it to be a hindrance to wider deployment of large-scale,
worldwide php applications.
Does anyone know if it is only the MSSQL module? -are there any plans
to look into this issue?
What are the future directions for PHP and Unicode support?
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/18169
--
Edit this bug report at http://bugs.php.net/?id=18169&edit=1
#27987 [Asn->WFx]: mysqli prepared statements crash mysqld on second execution
ID: 27987 Updated by: [EMAIL PROTECTED] Reported By: laura at cs dot rmit dot edu dot au -Status: Assigned +Status: Wont fix Bug Type: MySQL related Operating System: windows xp PHP Version: 5CVS-2004-04-15 Assigned To: edink New Comment: Sorry we are not able to upgrade the libs since mysql ab does not provide them. Previous Comments: [2004-04-14 22:25:55] [EMAIL PROTECTED] Edin, can you see if you can update the used mysql libs? (for mysqli..) [2004-04-14 13:05:23] laura at cs dot rmit dot edu dot au Installed snapshot, tested, still have same bug. [2004-04-14 10:14:01] [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 [2004-04-13 23:57:52] laura at cs dot rmit dot edu dot au Description: When using a mysqli prepared statement, first execution works. Second execution crashes the MySQL server. This is using PHP5RC1 and MySQL 5.0.0 alpha max and the sample code given at http://www.php.net/manual/en/function.mysqli-prepare.php (Example 1, OO style) I suspect the problem is caused by a bug in older versions of the MySQL library, as documented here: http://bugs.mysql.com/bug.php?id=2099 and here: http://bugs.mysql.com/bug.php?id=1663 This bug has been fixed in newer versions of the library from MySQL but I would guess the PHP5 version is based on an older (pre January) version of the library. Reproduce code: --- http://www.php.net/manual/en/function.mysqli-prepare.php Expected result: Output as specified in the manual Actual result: -- MySQL server crash. -- Edit this bug report at http://bugs.php.net/?id=27987&edit=1
#23312 [Opn->WFx]: using objects as primitives (new magic function)
ID: 23312
Updated by: [EMAIL PROTECTED]
Reported By: webmaster at s0nix dot de
-Status: Open
+Status: Wont fix
Bug Type:Feature/Change Request
PHP Version: 5CVS-2003-04-23 (dev)
New Comment:
No more magic, please.
Previous Comments:
[2004-04-14 22:55:11] jevon at jevon dot org
Doesn't __toString() do this already? (Although __toString()) is broken
at the moment.)
But along the same lines, how about a __toNumber() for arithmetic?
[2003-04-23 02:18:15] webmaster at s0nix dot de
http://www.zend.com/phorum/read.php?num=6&id=668&loc=0&thread=668
[quote]
First, object representation in different contexts. Currently, if we
write:
echo $object;
PHP produce not much of information about instance: 'object'. I have
read many articles about new PHP5 features where I found note that we
will be able to use an object in a 'foreach' instruction, like an
array, if this object implement container interface. This is great - I
think about an another usage of this concept - using an object as a
string. For example, if class provide an specific method (magic
function?):
class TSerializable {
function __value() {
return $this->toXML();
}
}
we will be able to use it like a simple value - an object will be
automatically converted (with a method defined by the user) to a
'primitive' representation:
echo ''.$object.'';
or
This will be very useful - e.g. in serialization, debugging and
PHP-based templates because we will be able to use general syntax to
streaming simple and complex data.
[/quote]
--
Edit this bug report at http://bugs.php.net/?id=23312&edit=1
#25772 [Opn->WFx]: Custom comparison of objects: __equals method
ID: 25772
Updated by: [EMAIL PROTECTED]
Reported By: dmitrijsl at swh-t dot lv
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.0b1 (beta1)
New Comment:
We're not going to have more magic then there already is; those things
are going to be to complicated and confusing (See the __string())
issue.
Previous Comments:
[2004-04-14 22:58:21] jevon at jevon dot org
Would love this feature! Java implements this through:
class Object {
boolean equals(Object o);
}
So you could either make all user-defined objects include a simple
equals() function [and similarly, identical()].
Or perhaps, develop the aforementioned magic __equals() [and
__identical()] functions. (As well as __less())
[2003-10-07 05:21:33] [EMAIL PROTECTED]
If at all then we should be able to do all comparisons directly by
__compare($other, $operator) where operator is one of {<,<=,==,!=,>,>=}
or by another method __less() which performs a < test so that __less()
and __equals() can be used to emulate all other tests.
[2003-10-07 04:05:43] dmitrijsl at swh-t dot lv
Description:
If a class defines a __equals($other) function, invoke that function on
object comparison. Example:
==
class MyClass {
public function __construct($value) {
$this->value = $value;
}
/**
* This function should be invoked on object
* comparison with == or != operators.
*/
public function __equals($other) {
if ($other instanceof MyClass) {
return ((int)$this->value
== (int)$other->value);
} else {
return false;
}
}
private $value;
}
$a = new MyClass(3.14);
$b = new MyClass(3.13);
if ($a == $b) {
echo '$a equals $b';
}
==
The comparison of $a and $b should result in the invokation of __equals
function of MyClass. The same should apply to the != (not equals)
operator.
--
Edit this bug report at http://bugs.php.net/?id=25772&edit=1
#28001 [Opn->WFx]: More informative class hinting errors
ID: 28001 Updated by: [EMAIL PROTECTED] Reported By: jevon at jevon dot org -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: XP SP1 PHP Version: 5.0.0RC1 New Comment: If you want this, write your own error handler and use debug_get_backtrace(). Previous Comments: [2004-04-14 23:05:33] jevon at jevon dot org Description: It would be nice for the object type hinting mechanism in PHP5 to, instead of failing with the expected class and line number of the definition, but failing with the expected and actual classes, and the line numbers of the definition AND the call. Reproduce code: --- zod(new Baz()); ?> Expected result: Fatal error: Argument 1 must be an object of class Bar (not Baz) in file.php on line 4, called in Foo::zod() by file.php on line 11 Actual result: -- Fatal error: Argument 1 must be an object of class Bar in file.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=28001&edit=1
#28002 [Opn->Asn]: Soap depends on session
ID: 28002 Updated by: [EMAIL PROTECTED] Reported By: schick at robotbattle dot com -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Debian GNU/Linux (sarge) PHP Version: 5.0.0RC1 -Assigned To: +Assigned To: dmitry New Comment: Assigning to the maintainer. Previous Comments: [2004-04-15 02:10:12] schick at robotbattle dot com Description: Soap extensions seems to depend on session support. Running configure with --disable-session and --enable-soap causes the build to fail with the following: ext/soap/soap.lo(.text+0x3a22): In function `zif_soapserver_handle': /var/src/php-5.0.0RC1/ext/soap/soap.c:1391: undefined reference to `ps_globals' ext/soap/soap.lo(.text+0x3b6a):/var/src/php-5.0.0RC1/ext/soap/soap.c:1342: undefined reference to `ps_globals' ext/soap/soap.lo(.text+0x3bc0):/var/src/php-5.0.0RC1/ext/soap/soap.c:1344: undefined reference to `php_session_start' Reproduce code: --- This is my config: './configure' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-pgsql=/usr/lib/postgresql' \ '--without-sqlite' \ '--disable-session' \ '--enable-soap' \ '--enable-mbstring' \ '--enable-magic-quotes' \ '--enable-memory-limit' \ '--with-zlib-dir=/usr/lib' \ '--enable-force-cgi-redirect' \ '--disable-ipv6' \ '--with-openssl=/usr' \ '--with-mcrypt' \ '--with-imap=/usr' \ '--with-kerberos' \ '--disable-debug' \ '--with-curl=/usr' \ '--with-gd' \ '--with-png-dir=/usr/lib' \ "$@" -- Edit this bug report at http://bugs.php.net/?id=28002&edit=1
#28003 [Opn->Bgs]: Won't work...
ID: 28003 Updated by: [EMAIL PROTECTED] Reported By: ken dot sparby at nes-ak dot no -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.5 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You're just really something doing wrong. Previous Comments: [2004-04-15 02:57:07] ken dot sparby at nes-ak dot no Description: My PHP just won't work... You can see for yourself here: http://www.legazy.com/dritt/apachestuk.jpg You see that my PHP-code is correct, path is correct and I have Apache running. I've tried the "Install PHP"-guide several times now, still not working. So if you could give me some hints or advice of what is wrong, that would be great :) - Slangen | 15.04.2004 Reproduce code: --- Expected result: It'll write "Hello World!" in my browser... Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=28003&edit=1
