5.0.5RC1 rolled

php.internals

Zeev Suraski

21 years ago
www.php.net/~zeev/php-5.0.5RC1.tar.gz www.php.net/~zeev/php-5.0.5RC1.tar.bz2 If there are no stoppers I'd like to release it towards the end of the week. Zeev

Sebastian Bergmann

21 years ago
Zeev Suraski schrieb:
> If there are no stoppers I'd like to release it towards the end of the > week.
Maybe the bundled PCRE should be updated: http://www.securitytracker.com/alerts/2005/Aug/1014744.html
-- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Rasmus Lerdorf

21 years ago
Sebastian Bergmann wrote:
> Zeev Suraski schrieb: > >>If there are no stoppers I'd like to release it towards the end of the >>week. > > > Maybe the bundled PCRE should be updated: > http://www.securitytracker.com/alerts/2005/Aug/1014744.html
Yes, and the whole reason for this release is to stop distributing a vulnerable version of XML_RPC. The version in the tarball is 1.3.1 and we want 1.4.0. -Rasmus

Greg Beaver

21 years ago
Rasmus Lerdorf wrote:
> Sebastian Bergmann wrote: > >>Zeev Suraski schrieb: >> >> >>>If there are no stoppers I'd like to release it towards the end of the >>>week. >> >> >> Maybe the bundled PCRE should be updated: >> http://www.securitytracker.com/alerts/2005/Aug/1014744.html > > > Yes, and the whole reason for this release is to stop distributing a > vulnerable version of XML_RPC. The version in the tarball is 1.3.1 and > we want 1.4.0.
We didn't update PHP_5_0 with the changes to PEAR 1.3.6, I will probably have time to do this later today, otherwise tomorrow. Greg P.S. if anyone else has the time now, they should simply sync package-PEAR.xml, go-pear-list.php, and XML_RPC-1.4.0.tar from the PHP_5_1 branch and it should be good to go. Don't forget to remove XML_RPC-1.3.1.tar Greg

Pierre-Alain Joye

21 years ago
On Mon, 22 Aug 2005 11:04:33 -0500 cellog@php.net (Greg Beaver) wrote:
> P.S. if anyone else has the time now, they should simply sync > package-PEAR.xml, go-pear-list.php, and XML_RPC-1.4.0.tar from the > PHP_5_1 branch and it should be good to go. Don't forget to remove > XML_RPC-1.3.1.tar
Please do it. I cannot do it that soon. --Pierre

Zeev Suraski

21 years ago
At 18:45 22/08/2005, Rasmus Lerdorf wrote:
>Sebastian Bergmann wrote: > > Zeev Suraski schrieb: > > > >>If there are no stoppers I'd like to release it towards the end of the > >>week. > > > > > > Maybe the bundled PCRE should be updated: > > http://www.securitytracker.com/alerts/2005/Aug/1014744.html > >Yes, and the whole reason for this release is to stop distributing a >vulnerable version of XML_RPC.
It's one of the reasons, there are tons of other bug fixes as well. It should definitely be fixed though. Anybody volunteering to handle the XML_RPC update? Zeev

Wez Furlong

21 years ago
I think I saw a configure related problem with the sqlite extension recently. I won't be able to check on this until thursday, maybe wednesday if things go well during the week. If someone else has time before I do, can they try building sqlite as a shared extension to verify if there was a problem? --Wez. On 8/22/05, Zeev Suraski <zeev@zend.com> wrote:

Mike Robinson

21 years ago
On my woody box, configure finished fine but with... Generating files updating cache ./config.cache creating ./config.status creating php5.spec creating main/build-defs.h creating scripts/phpize creating scripts/man1/phpize.1 sed: can't read ./scripts/man1/phpize.1.in: No such file or directory creating scripts/php-config creating scripts/man1/php-config.1 sed: can't read ./scripts/man1/php-config.1.in: No such file or directory creating sapi/cli/php.1 creating main/php_config.h creating main/internal_functions.c creating main/internal_functions_cli.c ... then during make: In file included from /usr/local/src/php-5.0.5RC1/ext/sqlite/libsqlite/src/sqliteInt.h:16, from parse.y:34: /usr/local/src/php-5.0.5RC1/ext/sqlite/libsqlite/src/config.h:1: /usr/local/src/php-5.0.5RC1/config.h: No such file or directory make: *** [ext/sqlite/libsqlite/src/parse.lo] Error 1 This by adding 'with-sqlite=shared' to the config line. Without this option it builds fine. Mike Wez Furlong wrote:

Wez Furlong

21 years ago
Thanks for checking; I'm working on a fix now. --Wez. On 8/26/05, Mike Robinson <mike@fiddy8.com> wrote:

Wez Furlong

21 years ago
Fixed in CVS. (just noticed that I could have just merged the config.m4 back from head rather than re-investigating it, oh well.) --Wez. On 8/28/05, Wez Furlong <kingwez@gmail.com> wrote:

steve roussey

21 years ago
I get this error in the error log, on every page view in this release: PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0 It seems to happen after the page is complete, since from the webpage it renders fine. I found a bug reference about throwing exceptions in __destroy, but that is not it. So I went to debug php, but alas, there isn't any info on php.net on how to do it (I tried --with-debug, but that gave me an error). Anyone have a reasonable quick way I can get either the PHP-code backtrace or the C backtrace of PHP itself on this fatal error? I have some limited knowledge of gdb... -steve-- On 8/22/05, Zeev Suraski <zeev@zend.com> wrote:

Marcus Börger

21 years ago
Hello steve, for a c backtrace set a breakpoint on function zend_throw_exception_internal. regards marcus Monday, August 29, 2005, 11:24:16 PM, you wrote:

steve roussey

21 years ago
Thats what I was looking for, thanks. I used that and no exception was thrown in 5.0.4, but there is one in 5.0.5RC2. It is in a shutdown function, which is why I couldn't figure out where it was happening. Not to mention, it was in an AJAX call. The shutdown function is defined in JPSpan (http://sourceforge.net/projects/jpspan), which is not that uncommon. I'll try and see if I can get a PHP debugger installed correctly on Windows with 5.0.5 and see what happens there. We develop on Windows and Mac and deploy on Linux, so I'll see if there is a platform element involved as well (I doubt). Anyway, anyone that wants to check it out themselves can get the JPSpan and run the hello world sample I suppose.??? Breakpoint 1, zend_throw_exception_internal (exception=0xac25a14) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_exceptions.c:38 38 if (exception != NULL) { (gdb) bt #0 zend_throw_exception_internal (exception=0xac25a14) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_exceptions.c:38 #1 0x081f33c7 in zend_throw_handler (execute_data=0xbfff6be0, opline=0xa7fde34, op_array=0xa5007e8) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2994 #2 0x081f0366 in execute (op_array=0xa5007e8) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #3 0x081f2c72 in zend_do_fcall_common_helper (execute_data=0xbfff7690, opline=0xa702e48, op_array=0xa58c5dc) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2789 #4 0x081f0366 in execute (op_array=0xa58c5dc) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #5 0x081f2c72 in zend_do_fcall_common_helper (execute_data=0xbfff86f0, opline=0xa825fec, op_array=0xa58c50c) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2789 #6 0x081f0366 in execute (op_array=0xa58c50c) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #7 0x081f2c72 in zend_do_fcall_common_helper (execute_data=0xbfff8b20, opline=0xa72027c, op_array=0xa58d7dc) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2789 #8 0x081f0366 in execute (op_array=0xa58d7dc) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #9 0x081cd609 in zend_call_function (fci=0xbfff8c60, fci_cache=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:873 #10 0x081ccec4 in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:559 #11 0x0815867e in zif_call_user_func_array (ht=2, return_value=0xab5a67c, this_ptr=0x0, return_value_used=1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/ext/standard/basic_functions.c:1976 #12 0x081f2e5a in zend_do_fcall_common_helper (execute_data=0xbfff9160, opline=0xa7ec7ac, op_array=0xa7e13c4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2760 #13 0x081f0366 in execute (op_array=0xa7e13c4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #14 0x081cd609 in zend_call_function (fci=0xbfff92a0, fci_cache=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:873 #15 0x081ccec4 in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:559 #16 0x081e53eb in zend_std_call_user_call (ht=2, return_value=0xab5a584, this_ptr=0xa5da6a4, return_value_used=1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_object_handlers.c:609 #17 0x081f2e5a in zend_do_fcall_common_helper (execute_data=0xbfff96f0, opline=0xa6ee900, op_array=0xa6e65f4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2760 #18 0x081f0366 in execute (op_array=0xa6e65f4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #19 0x081f2c72 in zend_do_fcall_common_helper (execute_data=0xbfff9970, opline=0xa6cb00c, op_array=0xa6c884c) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2789 #20 0x081f0366 in execute (op_array=0xa6c884c) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #21 0x081f2c72 in zend_do_fcall_common_helper (execute_data=0xbfff9a90, opline=0xa6cefa4, op_array=0xa6cdf98) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:2789 #22 0x081f0366 in execute (op_array=0xa6cdf98) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute.c:1437 #23 0x081cd609 in zend_call_function (fci=0xbfff9bd0, fci_cache=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:873 #24 0x081ccec4 in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:559 #25 0x081ccdf7 in call_user_function (function_table=0xa432240, object_pp=0x0, function_name=0xa6be23c, retval_ptr=0xbfff9c80, param_count=0, params=0xa6f4f40) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:534 #26 0x08158e41 in user_shutdown_function_call (shutdown_function_entry=0xbfff9c80) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/ext/standard/basic_functions.c:2101 #27 0x081dad50 in zend_hash_apply (ht=0xa619e94, apply_func=0x8158dc8 <user_shutdown_function_call>) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_hash.c:664 #28 0x0815905c in php_call_shutdown_functions () at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/ext/standard/basic_functions.c:2181 #29 0x081a76bd in php_request_shutdown (dummy=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/main/main.c:1202 #30 0x081fdb2c in main (argc=1, argv=0xbfffa6e4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/sapi/cgi/cgi_main.c:1640 On 8/29/05, Marcus Boerger <helly@php.net> wrote:

Marcus Börger

21 years ago
Hello steve, #15 0x081ccec4 in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_execute_API.c:559 #16 0x081e53eb in zend_std_call_user_call (ht=2, return_value=0xab5a584, this_ptr=0xa5da6a4, return_value_used=1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.0.5RC2/Zend/zend_object_handlers.c:609 in 15 you see that all parameters are bork! can you try valgrind to look for memory corruption or check why 15 is not able to pass the required parameters corectly. Or maybe the problem is that this_ptr is already invalid. marcus Tuesday, August 30, 2005, 9:32:07 PM, you wrote:

steve roussey

21 years ago
:) Can valgrind attach to a process like gdb? I somehow doubt it... In that case, I must admit, I've never used valgrind before. How can I set up valgrind to check a fast-cgi process? I tried changing the php5.fcgi file to php505.fcgi and created this as php5.fcgi: #/bin/bash /usr/bin/valgrind --tool=memcheck --trace-children=yes --log-file=/usr/local/apache2/logs/valgrind /usr/local/apache2/fastcgi-bin/php505.fcgi but that didn't work... On 8/30/05, Marcus Boerger <helly@php.net> wrote:

Marcus Börger

21 years ago
Hello steve, Tuesday, August 30, 2005, 11:32:33 PM, you wrote:
> :)
> Can valgrind attach to a process like gdb? I somehow doubt it... In > that case, I must admit, I've never used valgrind before. How can I > set up valgrind to check a fast-cgi process?
> I tried changing the php5.fcgi file to php505.fcgi and created this as > php5.fcgi:
> #/bin/bash
that's missing the '!'
> /usr/bin/valgrind --tool=memcheck --trace-children=yes > --log-file=/usr/local/apache2/logs/valgrind > /usr/local/apache2/fastcgi-bin/php505.fcgi
you don't pass the parameters here or aren't you passing any? besides those comments i don't know of a way to attach to a running process. marcus

steve roussey

21 years ago
Yea, I noticed that too... #!/bin/bash export PHPRC export PHP_FCGI_CHILDREN exec /usr/bin/valgrind --tool=memcheck --trace-children=yes \ --log-file=/usr/local/apache2/fastcgi-bin/log /usr/local/apache2/fastcgi-bin/php505.fcgi $@ This one works. :) However... it didn't seem to find much.

steve roussey

21 years ago
This was with: /usr/bin/valgrind --tool=memcheck --leak-check=yes -v --trace-children=yes And it didn't seem to add anything while the errorlog was being written. # more log.pid17870 ==17870== Memcheck, a memory error detector for x86-linux. ==17870== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==17870== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==17870== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==17870== ==17870== My PID = 17870, parent PID = 17869. Prog and args are: ==17870== /usr/local/apache2/fastcgi-bin/php505.fcgi ==17870== ==17870== Valgrind library directory: /usr/lib/valgrind ==17870== Command line ==17870== /usr/local/apache2/fastcgi-bin/php505.fcgi ==17870== Startup, with flags: ==17870== --tool=memcheck ==17870== --leak-check=yes ==17870== -v ==17870== --trace-children=yes ==17870== --log-file=/usr/local/apache2/fastcgi-bin/log ==17870== Contents of /proc/version: ==17870== Linux version 2.6.9-11.106.unsupportedsmp (buildcentos@x8664-build) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Wed Jun 8 22:05:04 CDT 2005 ==17870== Reading syms from /usr/local/apache2/fastcgi-bin/php505.fcgi (0x8048000) ==17870== Reading syms from /lib/ld-2.3.4.so (0x1B8E4000) ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/valgrind/stage2 (0xB0000000) ==17870== Reading syms from /lib/ld-2.3.4.so (0xB1000000) ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so (0xB7C9D000) ==17870== Reading syms from /lib/tls/libc-2.3.4.so (0xB7EC6000) ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libdl-2.3.4.so (0xB7FF0000) ==17870== object doesn't have any debug info ==17870== Reading suppressions file: /usr/lib/valgrind/default.supp ==17870== REDIRECT soname:libc.so.6(__GI___errno_location) to soname:libpthread.so.0(__errno_location) ==17870== REDIRECT soname:libc.so.6(__errno_location) to soname:libpthread.so.0(__errno_location) ==17870== REDIRECT soname:libc.so.6(__GI___h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==17870== REDIRECT soname:libc.so.6(__h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==17870== REDIRECT soname:libc.so.6(__GI___res_state) to soname:libpthread.so.0(__res_state) ==17870== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0(__res_state) ==17870== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==17870== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen) ==17870== REDIRECT soname:ld-linux.so.2(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==17870== REDIRECT soname:ld-linux.so.2(strchr) to *vgpreload_memcheck.so*(strchr) ==17870== ==17870== Reading syms from /usr/lib/valgrind/vg_inject.so (0x1B8FC000) ==17870== Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x1B901000) ==17870== TRANSLATE: 0x1B8F5EE0 redirected to 0x1B904100 ==17870== Reading syms from /lib/libcrypt-2.3.4.so (0xB3D000) ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/libpng12.so.0.1.2.7 (0xAFD000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/libz.so.1.2.1.2 (0xB97000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libresolv-2.3.4.so (0x79D000) ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/tls/libm-2.3.4.so (0x5D8000) ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libdl-2.3.4.so (0x5D2000) ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libnsl-2.3.4.so (0x982000) ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libssl.so.0.9.7a (0xBA9000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libcrypto.so.0.9.7a (0x139000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/libgssapi_krb5.so.2.2 (0x9D5000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/libkrb5.so.3.2 (0x908000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /lib/libcom_err.so.2.1 (0x7B2000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/libk5crypto.so.3.0 (0x7FA000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/libxml2.so.2.6.16 (0x224000) ==17870== object doesn't have a symbol table ==17870== object doesn't have any debug info ==17870== Reading syms from /usr/lib/valgrind/libpthread.so (0x1B919000) ==17870== Reading syms from /lib/tls/libc-2.3.4.so (0x4A7000) ==17870== object doesn't have any debug info ==17870== TRANSLATE: 0x50AE80 redirected to 0x1B9048F8 ==17870== TRANSLATE: 0x50ABA0 redirected to 0x1B905274 ==17870== TRANSLATE: 0x1B8E47A0 redirected to 0x52BFF040 ==17870== TRANSLATE: 0x508DB0 redirected to 0x1B904E24 ==17870== TRANSLATE: 0x50B4C0 redirected to 0x1B905326 ==17870== TRANSLATE: 0x511090 redirected to 0x1B9046F4 ==17995== Reading syms from /lib/libnss_files-2.3.4.so (0x1C154000) ==17995== object doesn't have any debug info ==17995== Conditional jump or move depends on uninitialised value(s) ==17995== at 0xB9B1C7: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9C06F: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9A505: deflate (in /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9881A: compress2 (in /usr/lib/libz.so.1.2.1.2) ==17995== ==17995== Conditional jump or move depends on uninitialised value(s) ==17995== at 0xB9B18E: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9C06F: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9A505: deflate (in /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9881A: compress2 (in /usr/lib/libz.so.1.2.1.2) ==17995== ==17995== Process terminating with default action of signal 15 (SIGTERM) ==17995== at 0x56EA41: accept (in /lib/tls/libc-2.3.4.so) ==17995== by 0x821AAEC: OS_Accept (os_unix.c:1146) ==17995== by 0x8219C81: FCGX_Accept_r (fcgiapp.c:2210) ==17995== by 0x821BAA9: main (cgi_main.c:1662) ==17995== ==17995== ERROR SUMMARY: 66 errors from 2 contexts (suppressed: 30 from 2) ==17995== ==17995== 6 errors in context 1 of 2: ==17995== Conditional jump or move depends on uninitialised value(s) ==17995== at 0xB9B1C7: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9C06F: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9A505: deflate (in /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9881A: compress2 (in /usr/lib/libz.so.1.2.1.2) ==17995== ==17995== 60 errors in context 2 of 2: ==17995== Conditional jump or move depends on uninitialised value(s) ==17995== at 0xB9B18E: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9C06F: (within /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9A505: deflate (in /usr/lib/libz.so.1.2.1.2) ==17995== by 0xB9881A: compress2 (in /usr/lib/libz.so.1.2.1.2) --17995-- --17995-- supp: 2 _dl_relocate_object/dl_open_worker --17995-- supp: 28 dl_relocate_object/dl_main ==17995== ==17995== IN SUMMARY: 66 errors from 2 contexts (suppressed: 30 from 2) ==17995== ==17995== malloc/free: in use at exit: 570156 bytes in 9647 blocks. ==17995== malloc/free: 794941 allocs, 785294 frees, 213330079 bytes allocated. ==17995== ==17995== searching for pointers to 9647 not-freed blocks. ==17870== ==17870== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 1) --17870-- --17870-- supp: 28 dl_relocate_object/dl_main ==17870== malloc/free: in use at exit: 522130 bytes in 9485 blocks. ==17870== malloc/free: 10131 allocs, 646 frees, 585888 bytes allocated. ==17870== ==17870== searching for pointers to 9485 not-freed blocks. got signal 15 in LWP 17870 (17870) valgrind: vg_signals.c:1997 (vg_async_signalhandler): Assertion `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed. ==17870== at 0xB002C005: vgPlain_skin_assert_fail (vg_mylibc.c:1137) ==17870== by 0xB002C004: assert_fail (vg_mylibc.c:1133) ==17870== by 0xB002C042: vgPlain_core_assert_fail (vg_mylibc.c:1144) ==17870== by 0xB0031F59: vg_async_signalhandler (vg_signals.c:1997) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==17870== at 0x1B8FC9EA: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:119) ==17870== by 0x5314F3: __GI__exit (in /lib/tls/libc-2.3.4.so) ==17870== by 0x821B48C: fastcgi_cleanup (cgi_main.c:935) ==17870== by 0x52BFEFFF: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ==17995== checked 10519468 bytes. ==17995== ==17995== LEAK SUMMARY: ==17995== definitely lost: 0 bytes in 0 blocks. ==17995== possibly lost: 0 bytes in 0 blocks. ==17995== still reachable: 569956 bytes in 9646 blocks. ==17995== suppressed: 200 bytes in 1 blocks. ==17995== Reachable blocks (those to which a pointer was found) are not shown. ==17995== To see them, rerun with: --show-reachable=yes --17995-- TT/TC: 0 tc sectors discarded. --17995-- 164887 tt_fast misses. --17995-- translate: new 27502 (463623 -> 6555839; ratio 141:10) --17995-- discard 2 (59 -> 840; ratio 142:10). --17995-- chainings: 25350 chainings, 3 unchainings. --17995-- dispatch: 379000000 jumps (bb entries); of them 57255834 (15%) unchained. --17995-- 17488/1949962 major/minor sched events. --17995-- reg-alloc: 4848 t-req-spill, 1208465+34207 orig+spill uis, --17995-- 142099 total-reg-rank --17995-- sanity: 12745 cheap, 510 expensive checks. --17995-- ccalls: 138175 C calls, 55% saves+restores avoided (454052 bytes) --17995-- 185964 args, avg 0.88 setup instrs each (43568 bytes) --17995-- 0% clear the stack (414075 bytes) --17995-- 43264 retvals, 30% of reg-reg movs avoided (25174 bytes)

steve roussey

21 years ago
On 8/30/05, Marcus Boerger <helly@php.net> wrote:
> in 15 you see that all parameters are bork!
If that is true, then 10, 15, and 24 (all call_user_function_ex) are borked. 24 would be the earliest. Maybe something is being cleaned up at the start of shutdown but before the user shutdown function is called that shouldn't be just yet. I know it uses classes, class method static variables, etc. Anything like this sound like a changeset from 5.0.4 to 5.0.5?

steve roussey

21 years ago
This also happens in 5.1.0RC1, btw: Breakpoint 1, zend_throw_exception_internal (exception=0xa19baa4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_exceptions.c:39 39 if (exception != NULL) { (gdb) bt #0 zend_throw_exception_internal (exception=0xa19baa4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_exceptions.c:39 #1 0x0827b695 in ZEND_THROW_SPEC_VAR_HANDLER (execute_data=0xbfe94b70) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:7034 #2 0x082679d9 in execute (op_array=0xa2f92a0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #3 0x08267bcb in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe95200) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:219 #4 0x082679d9 in execute (op_array=0xa361d7c) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #5 0x08267bcb in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe95a10) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:219 #6 0x082679d9 in execute (op_array=0xa361c9c) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #7 0x08267bcb in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe95c80) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:219 #8 0x082679d9 in execute (op_array=0xa3630fc) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #9 0x0823dead in zend_call_function (fci=0xbfe95d90, fci_cache=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_execute_API.c:871 #10 0x0823e95c in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_execute_API.c:571 #11 0x081bfe4a in zif_call_user_func_array (ht=2, return_value=0xa188d94, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/ext/standard/basic_functions.c:2115 #12 0x08267f67 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe96160) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:184 #13 0x082679d9 in execute (op_array=0xa2bfac4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #14 0x0823dead in zend_call_function (fci=0xbfe962a0, fci_cache=0xbfe96280) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_execute_API.c:871 #15 0x08255b28 in zend_call_method (object_pp=0xbfe9636c, obj_ce=0xa28ea6c, fn_proxy=0xa28eb4c, function_name=0x8467732 "__call", function_name_len=6, retval_ptr_ptr=0xbfe96348, param_count=1, arg1=0xa3749d4, arg2=0xa3749b4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_interfaces.c:87 #16 0x0825acf8 in zend_std_call_user_call (ht=2, return_value=0xa37492c, return_value_ptr=0x0, this_ptr=0xa266d14, return_value_used=1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_object_handlers.c:599 #17 0x08267f67 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe96570) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:184 #18 0x082679d9 in execute (op_array=0xa4418b4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #19 0x08267bcb in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe967c0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:219 #20 0x082679d9 in execute (op_array=0xa4220cc) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #21 0x08267bcb in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe96910) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:219 #22 0x082679d9 in execute (op_array=0xa427510) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_vm_execute.h:87 #23 0x0823dead in zend_call_function (fci=0xbfe96a20, fci_cache=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_execute_API.c:871 #24 0x0823e95c in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_execute_API.c:571 #25 0x0823e998 in call_user_function (function_table=0xa0a2350, object_pp=0x0, function_name=0xa43f80c, retval_ptr=0xbfe96ad0, param_count=0, params=0xa448280) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_execute_API.c:544 #26 0x081c06bd in user_shutdown_function_call (shutdown_function_entry=0xbfe96ad0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/ext/standard/basic_functions.c:2242 #27 0x0824f4c0 in zend_hash_apply (ht=0xa447cf4, apply_func=0x81c0654 <user_shutdown_function_call>) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/Zend/zend_hash.c:664 #28 0x081c099a in php_call_shutdown_functions () at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/ext/standard/basic_functions.c:2322 #29 0x08214c6f in php_request_shutdown (dummy=0x0) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/main/main.c:1207 #30 0x082ca4b5 in main (argc=1, argv=0xbfe975e4) at /root/webserver_software_tmp_fastcgi_apache2/php-5.1.0RC1/sapi/cgi/cgi_main.c:1632

steve roussey

21 years ago
I was a little early in posting the bt -- it seems that that there must be an exception tree, or multiple exceptions -- I have several successive cont for which I got a bt. This is all from a single request. Sometimes, between call_user_function and call_user_function_ex the parameters like function_table are valid (function_table=0xa0a2350) and sometimes they are not (function_table=0x0 or function_table=0x1). I'm trying to attach the multiple bt for this, hopefully the list will allow... -steve--