#23942 [Bgs->Opn]: php 4.3.x causes apache2+mod_ssl to sigsev on client authentication
ID: 23942 User updated by: alextxm at tin dot it Reported By: alextxm at tin dot it -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: sniper: I think there still is something related to PHP itself. On both the three machine using the same version of mysql (with openssl support enabled), openssl and php with apache 1.3.x have no problem at all. Also, both apache1 and apache2 without php work fine with mysql+ssl. Problem is somehow related to the apache2 sapi in php...maybe it is not php own fault but there is a weird relation between them. let me know if I can help with more tests and/or providing more info. alessandro Previous Comments: [2003-06-15 16:51:37] [EMAIL PROTECTED] Yes, just what I expected. It's not really our problem, most likely mysql does some fancy init stuff with openssl, or you just mix two different openssl versions. Try compiling everything from sources with debug symbols, I guess mysql and openssl have some --enable-debug switch too. Then you'll get better GDB backtrace. [2003-06-15 14:14:22] alextxm at tin dot it more news: i've jsut tried recompiling mysql without openssl support on both the gentoo platforms (as of RH9, cfr ldd output in my previous comment) and php now work as expected with --with-mysql=/usr. So the whole things seems to be related to openssl support in MySQL. Is still the whole thing pertinent to php or should I ask mysql people ? alessandro [2003-06-15 13:56:18] alextxm at tin dot it output of ldd libmysqlclient.so for each platform (cfr. my previous comment) : rh9) libz.so.1 => /usr/lib/libz.so.1 (0x40053000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40061000) libnsl.so.1 => /lib/libnsl.so.1 (0x4008e000) libm.so.6 => /lib/tls/libm.so.6 (0x400a4000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.2) libz.so.1 => /usr/lib/libz.so.1 (0x40047000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40055000) libnsl.so.1 => /lib/libnsl.so.1 (0x40082000) libm.so.6 => /lib/libm.so.6 (0x40097000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400b8000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x400e6000) libc.so.6 => /lib/libc.so.6 (0x401d9000) libdl.so.2 => /lib/libdl.so.2 (0x402fc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.4) libz.so.1 => /usr/lib/libz.so.1 (0x40052000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4006) libnsl.so.1 => /lib/libnsl.so.1 (0x4008d000) libm.so.6 => /lib/libm.so.6 (0x400a1000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x400c3000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400f1000) libc.so.6 => /lib/libc.so.6 (0x401b1000) libdl.so.2 => /lib/libdl.so.2 (0x402da000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) i'm also investigating more things... let me know if you need to me to test some specific items alessandro [2003-06-14 17:19:25] [EMAIL PROTECTED] That sounds odd. And as you're not running Apache2 as threaded (worker, or whatever that MPM was again), it shouldn't be thread-safety issue either. Could you check what libmysqlclient.so is linked with on those systems? Output of: # ldd libmysqlclient.so And FYI: the bundled mysql library is far from obsolete. (it works, doesn't it? :) [2003-06-14 15:40:21] alextxm at tin dot it finally, i've found the problem: compiling php 4.3.2 with --with-mysql=/path-to-mysql staically linked is the culprit. The problem can be avoided using --with-mysql and so using PHP's built-in (but obsolete) mysql interface or using: --with-mysql=shared,/path-to-mysql and then enabling php_mysql.so in php.ini Tests had been accomplished on three machines: a) gentoo linux 1.2: glibc 2.2.5, php 4.3.2, apache 2.0.45/46, mysql 4.0.12, openssl 0.9.6j b) gentoo linux 1.4rc4: glibc 2.3.1, php 4.3.2, apache 2.0.46, mysql 4.0.13, openssl 0.9.7b c) redhat 9: php 4.2.2, apache 2.0.40, openssl 0.9.7a, mysql-4.0.10 alessandro 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/23942 -- Edit this bug report at http://bugs.php.net/?id=23942&edit=1
#23691 [Bgs]: Mail Funktion doesn't work
ID: 23691 Updated by: [EMAIL PROTECTED] Reported By: ruta at teltec dot de Status: Bogus Bug Type: *Mail Related Operating System: Win 2000 Server PHP Version: 4.3.2RC3 New Comment: > after this you just need configure the WIN virtual SMTP > with a anonymus open relay to solve the MAIL > problem(carefully) ;-) What is your IP address so I can block it? Open relaying is BAD BAD BAD BAD... the main source of spam. Previous Comments: [2003-06-16 01:33:05] ruta at teltec dot de Finaly It WORKS! I figured out how to run apache and php as module! In previouse versions I coudn't load the php_mod4 dll in apache. Try http://www.apache.de/dist/httpd/binaries/win32/apache_2.0.46-win32-x86-no_src.msi";>apache 2.0.46 and the http://www.php.net/get/php-4.3.2-Win32.zip/from/a/mirror";>PHP 4.3.2! after this you just need configure the WIN virtual SMTP with a anonymus open relay to solve the MAIL problem(carefully) ;-) Thanks Thomas Ruta [2003-05-19 02:01:20] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Already reported, and already pointed to the support channels. [2003-05-19 00:59:59] ruta at teltec dot de Mail funktion reports Error 501. Can't connect to Smtp Server... PHP Version 4.2.3 works but as updating to 4.3.x the Mail funktion doesn't work even disabling the servers Firewall. Thanks for your support. Best regards. Thomas Ruta -- Edit this bug report at http://bugs.php.net/?id=23691&edit=1
#24198 [NEW]: array_merge_recurcive
From: camka at email dot ee
Operating system: win 2000
PHP version: 4.3.2
PHP Bug Type: *General Issues
Bug description: array_merge_recurcive
Description:
When var_dumping $f it appears a notice message, saying
Warning: array_merge_recursive(): recursion detected in ...
It is kind of strange because as far as I expect it is supposed to be the
same result as in the line where $e is being var_dumped. var_dump($e)
gives correct result:
array
'a' =>
array
0 => 'aa'
1 => 'aa'
'b' =>
array
0 => 'bb'
1 => 'bb'
and var_dump($f) gives notece message and result is
array
'a' => 'aa'
'b' => 'bb'
problem appears in 4.3.1 too, but not in 4.2.2
Reproduce code:
---
'aa','b' => 'bb');
$d=array('a' => 'aa','b' => 'bb');
$a=$c;
$b=$c;
$f=array_merge_recursive($a,$b);
var_dump($f);
$e=array_merge_recursive($c,$d);
var_dump($e);
?>
Expected result:
array
'a' =>
array
0 => 'aa'
1 => 'aa'
'b' =>
array
0 => 'bb'
1 => 'bb'
array
'a' =>
array
0 => 'aa'
1 => 'aa'
'b' =>
array
0 => 'bb'
1 => 'bb'
Actual result:
--
Warning: array_merge_recursive(): recursion detected in
c:\servak\www\tests\array_merge_recursive.php on line 9
array
'a' => 'aa'
'b' => 'bb'
array
'a' =>
array
0 => 'aa'
1 => 'aa'
'b' =>
array
0 => 'bb'
1 => 'bb'
--
Edit bug report at http://bugs.php.net/?id=24198&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24198&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24198&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24198&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24198&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24198&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24198&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24198&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24198&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24198&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24198&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24198&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24198&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24198&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24198&r=gnused
#23691 [Bgs]: Mail Funktion doesn't work
ID: 23691 User updated by: ruta at teltec dot de Reported By: ruta at teltec dot de Status: Bogus Bug Type: *Mail Related Operating System: Win 2000 Server PHP Version: 4.3.2RC3 New Comment: Finaly It WORKS! I figured out how to run apache and php as module! In previouse versions I coudn't load the php_mod4 dll in apache. Try http://www.apache.de/dist/httpd/binaries/win32/apache_2.0.46-win32-x86-no_src.msi";>apache 2.0.46 and the http://www.php.net/get/php-4.3.2-Win32.zip/from/a/mirror";>PHP 4.3.2! after this you just need configure the WIN virtual SMTP with a anonymus open relay to solve the MAIL problem(carefully) ;-) Thanks Thomas Ruta Previous Comments: [2003-05-19 02:01:20] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Already reported, and already pointed to the support channels. [2003-05-19 00:59:59] ruta at teltec dot de Mail funktion reports Error 501. Can't connect to Smtp Server... PHP Version 4.2.3 works but as updating to 4.3.x the Mail funktion doesn't work even disabling the servers Firewall. Thanks for your support. Best regards. Thomas Ruta -- Edit this bug report at http://bugs.php.net/?id=23691&edit=1
#24196 [Opn]: Serialize segfaults in a rare instance
ID: 24196 User updated by: ramato at squiz dot net Reported By: ramato at squiz dot net Status: Open Bug Type: Reproducible crash Operating System: Redhat 7.3 PHP Version: 4.3.2 New Comment: I forgot to include the actual seg fault message in the report. (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x4024b352 in php_var_serialize_class_name (buf=0xbffd9fec, struc=0x86829d0) at /root/apache+php/php4-STABLE-200306160330/ext/standard/var.c:416 416 PHP_SET_CLASS_ATTRIBUTES(*struc); Previous Comments: [2003-06-15 23:59:34] ramato at squiz dot net Snapshot still crashes. Backtrace looks esentially identical. I will see if I can get a simple test script but I have tried a few times in the past to make one and havn't been able to. I have a bunch of core files that I can work on and I can reproduce it every time, however I couldn't work out enough about the internals to figure out how to get gdb to print out the var that is getting passed to it (which I suspect to be the problem). I tried asking on the dev list if anyone has any ideas about this and they suggested recompiling with gcc 2.95 but that didn't make any difference. [2003-06-15 22:19:35] [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 if that crashes too, please try to provide a short example script.. [2003-06-15 19:27:22] ramato at squiz dot net Description: I'm trying to track down a segfault to do with serializing an object. I can't reproduce it with a small script so I'm not sure where to go from here. Any suggestions, tips, helpful hints greatly appreciated. It's part of a largish CMS which uses lots of circular references so pasting an example isn't easy. I know that circular references are a source of a lot of problems however all the circular references are being removed in the __sleep function so this shouldn't be an issue. Expected result: Normal execution Actual result: -- (gdb) bt #0 0x4023d67e in php_var_serialize_class_name (buf=0xbffddf20, struc=0x8bd961c) at /usr/src/php-4.3.2/ext/standard/var.c:416 #1 0x4023c899 in php_var_serialize_class (buf=0xbffddf20, struc=0x8bd961c, retval_ptr=0x8b43dec, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:430 #2 0x4023cdf5 in php_var_serialize_intern (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:549 #3 0x4023d05b in php_var_serialize (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:623 #4 0x4023d108 in zif_serialize (ht=1, return_value=0x88340d4, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.2/ext/standard/var.c:646 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 (gdb) frame 5 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 1606 ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x4030831b "serialize" -- Edit this bug report at http://bugs.php.net/?id=24196&edit=1
#24196 [Fbk->Opn]: Serialize segfaults in a rare instance
ID: 24196 User updated by: ramato at squiz dot net Reported By: ramato at squiz dot net -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Redhat 7.3 PHP Version: 4.3.2 New Comment: Snapshot still crashes. Backtrace looks esentially identical. I will see if I can get a simple test script but I have tried a few times in the past to make one and havn't been able to. I have a bunch of core files that I can work on and I can reproduce it every time, however I couldn't work out enough about the internals to figure out how to get gdb to print out the var that is getting passed to it (which I suspect to be the problem). I tried asking on the dev list if anyone has any ideas about this and they suggested recompiling with gcc 2.95 but that didn't make any difference. Previous Comments: [2003-06-15 22:19:35] [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 if that crashes too, please try to provide a short example script.. [2003-06-15 19:27:22] ramato at squiz dot net Description: I'm trying to track down a segfault to do with serializing an object. I can't reproduce it with a small script so I'm not sure where to go from here. Any suggestions, tips, helpful hints greatly appreciated. It's part of a largish CMS which uses lots of circular references so pasting an example isn't easy. I know that circular references are a source of a lot of problems however all the circular references are being removed in the __sleep function so this shouldn't be an issue. Expected result: Normal execution Actual result: -- (gdb) bt #0 0x4023d67e in php_var_serialize_class_name (buf=0xbffddf20, struc=0x8bd961c) at /usr/src/php-4.3.2/ext/standard/var.c:416 #1 0x4023c899 in php_var_serialize_class (buf=0xbffddf20, struc=0x8bd961c, retval_ptr=0x8b43dec, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:430 #2 0x4023cdf5 in php_var_serialize_intern (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:549 #3 0x4023d05b in php_var_serialize (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:623 #4 0x4023d108 in zif_serialize (ht=1, return_value=0x88340d4, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.2/ext/standard/var.c:646 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 (gdb) frame 5 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 1606 ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x4030831b "serialize" -- Edit this bug report at http://bugs.php.net/?id=24196&edit=1
#22092 [Fbk->NoF]: Strange warning and no functionality in imagettfbbox and imagettftext
ID: 22092 Updated by: [EMAIL PROTECTED] Reported By: davidl at tocquigny dot com -Status: Feedback +Status: No Feedback Bug Type: GD related Operating System: Redhat 7.1 PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-06-10 19:22:03] [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 [2003-05-29 10:47:42] davidl at tocquigny dot com The problem with spaces in the font name continues in 4.3.2. A font "arial.ttf" works but "futura bold.ttf" generates the error: Warning: imagettfbbox(): Could not find/open font in /xxx/xxx/xxx/custom_class.php on line 535 [2003-05-27 17:30:59] paul at thewall dot de I can confirm this bug, it still persist. A Full path did not help, as well as renaming the font file and cutting off the extension (which is reported to work). I have tried GD extension versions 1 and 2, same result. PHP Version is 4.2.3. [2003-04-10 08:51:29] kadlcakd at yahoo dot com I have the same problem with 4.3.1 I have GD 2.0.4 compiled with TTF support, php 4.3.1 compiled --with-gd --with-ttf --with-freetype-dir ImageTTFBBox( 18, 0, "fonts/times.ttf", "Hello" ); Gives an error: Warning: imagettfbbox() [function.imagettfbbox]: Could not find/open font in /usr2/accnts/theuser/www/tests/button.php Dave. [2003-03-13 14:00:41] FR at ncis dot ca We also have this bug with 4.3.1 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/22092 -- Edit this bug report at http://bugs.php.net/?id=22092&edit=1
#24081 [Fbk->NoF]: when "./configure" with MySQl error come out
ID: 24081 Updated by: [EMAIL PROTECTED] Reported By: zengkun_100 at 163 dot com -Status: Feedback +Status: No Feedback Bug Type: MySQL related Operating System: Red Hat Linux 9.0 PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-06-08 08:54:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-06-08 08:52:53] zengkun_100 at 163 dot com If I complie PHP with MySQL ,It seems that the most recent PHP "edition 4.3.2" cannot support the most recent MySQL edition4.0.13.It Seems that PHP cannot identify MySQL's new function "MySQL real Connect." -- Edit this bug report at http://bugs.php.net/?id=24081&edit=1
#24086 [Fbk->NoF]: file_exists generates false error
ID: 24086
Updated by: [EMAIL PROTECTED]
Reported By: danfratus at attbi dot com
-Status: Feedback
+Status: No Feedback
Bug Type: Filesystem function related
Operating System: Windows XP Professional
PHP Version: 4.3.2
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-06-09 08:38:00] [EMAIL PROTECTED]
Exactly what is the bug here? file_exists("...") ??
or what? (that returns FALSE..)
[2003-06-08 17:41:14] danfratus at attbi dot com
Ok the glitch is this: if $file is "." or ".." the script is fine, no
errors are generated, but, when $file is "..." or "..." or
"..", etc. then for some reason PHP reconizes this as a
directory, yet it can't be included therefore generating this error:
---
Warning: file(...) [function.file]: failed to create stream: No such
file or directory in F:\server\bug.php on line 4
Warning: join() [function.join]: Bad arguments. in F:\server\bug.php on
line 4
---
This "bug" isn't going to crash the entire internet or anything, but it
should be fixed.
--
Edit this bug report at http://bugs.php.net/?id=24086&edit=1
#24091 [Fbk->NoF]: CLI Segfault
ID: 24091 Updated by: [EMAIL PROTECTED] Reported By: devon at sitetronics dot com -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: RHL 7.3/kern 2.4.21-rc6 PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-06-09 08:36:08] [EMAIL PROTECTED] What might that script contain..? I can not reproduce this with PHP 4.3.3-dev. [2003-06-09 04:46:47] devon at sitetronics dot com Same in 4.3.2 [2003-06-09 04:35:11] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. And disable any accelerator, caching and encoding products. [2003-06-09 04:33:23] devon at sitetronics dot com Goofing around with shell scripting in PHP, I bumped into this problem. I scanned the other segfault bugs, but I didn't find one like this. Additionally, I haven't tried with any nightlies, so sorry, but here we go. When running a script with the CLI binary as so: # php -q < somescript.php I receive a segfault. This should work as PHP should parse stuff from stdin, and this is just a pipe. Copying the script to stdin when calling PHP as #php -q I'm able to run the script successfully. Additionally, I can run the script by doing # php -q somescript.php I'm positive that this is because I have PHP reading its pipe from stdin and then requesting user input from stdin as well. But PHP should die gracefully and not segfault. Oh yeah, here's the really strange backtrace #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x402c039c, va=0xbf800834, spec=0xbf800824, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 "ss|br", va=0xbf800834, flags=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:527 #2 0x08129e5b in zend_parse_parameters (num_args=2, type_spec=0x81568b6 "ss|br") at /root/build/php/php-4.3.1/Zend/zend_API.c:554 #3 0x080a9c8e in php_if_fopen (ht=2, return_value=0x81d5884, this_ptr=0x0, return_value_used=1) at /root/build/php/php-4.3.1/ext/standard/file.c:1086 #4 0x4027f922 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #5 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #6 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #7 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #8 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #9 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #10 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #12 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #13 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #14 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #15 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #16 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #17 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so ... #11382 0x40285ae9 in _ntime () from /usr/local/ioncube/ioncube_loader_lin_4.3.so #11383 0x08102869 in php_execute_script (primary_file=0xbac0) at /root/build/php/php-4.3.1/main/main.c:1573 #11384 0x08143610 in main (argc=2, argv=0xbb64) at /root/build/php/php-4.3.1/sapi/cli/php_cli.c:746 #11385 0x401331c4 in __libc_start_main () from /lib/libc.so.6 Aha! But before you say "idiot, go email Nick", here's the backtrace with the loader turned off :P. It just proves that Nick's gotta fix his stuff also. #0 0x081299f8 in zend_parse_arg (arg_num=1, arg=0x824be44, va=0xbf800754, spec=0xbf800744, quiet=0) at /root/build/php/php-4.3.1/Zend/zend_API.c:436 #1 0x08129df8 in zend_parse_va_args (num_args=2, type_spec=0x81568b6 "ss|br", va=0xbf800754, flags=0)
#24093 [Fbk->NoF]: fgets can't use you must use fread
ID: 24093 Updated by: [EMAIL PROTECTED] Reported By: sanry at now dot net dot cn -Status: Feedback +Status: No Feedback -Bug Type: Unknown/Other Function +Bug Type: Filesystem function related Operating System: linux PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-06-09 08:15:36] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-06-09 08:04:14] sanry at now dot net dot cn fgets can't use you must use fread -- Edit this bug report at http://bugs.php.net/?id=24093&edit=1
#24099 [Fbk->NoF]: large objects broken
ID: 24099 Updated by: [EMAIL PROTECTED] Reported By: gurov at f3h dot com -Status: Feedback +Status: No Feedback Bug Type: PostgreSQL related Operating System: linux 2.2.16-22 PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-06-09 11:28: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 [2003-06-09 11:15:46] gurov at f3h dot com it seems that after upgrading to 4.3.2stable from 4.3.2RC1 large objects refuse to work, tried with both 7.3.2 and 7.3.3 postgres downgrading to 4.3.2RC1 seemed to fix it for now -- Edit this bug report at http://bugs.php.net/?id=24099&edit=1
#24115 [Fbk->NoF]: dbase_get_record() crashes on some files
ID: 24115 Updated by: [EMAIL PROTECTED] Reported By: hensle at teq-services dot com -Status: Feedback +Status: No Feedback Bug Type: dBase related Operating System: winNT PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-06-10 12:20:19] [EMAIL PROTECTED] Please provide a full URL to this file in question. [2003-06-10 12:19:59] hensle at teq-services dot com using php_dbase.dll dated feb 15 2003 [2003-06-10 12:10:05] hensle at teq-services dot com The following code will crash with *some* dbf files. The dbf can be found at the US census site: Congressional districts for the entire US=cd99_108.zip -- Edit this bug report at http://bugs.php.net/?id=24115&edit=1
#24002 [Ver]: Nested calls to xml_parse no longer work
ID: 24002
Updated by: [EMAIL PROTECTED]
Reported By: derek at hostopia dot com
Status: Verified
Bug Type: XML related
Operating System: Linux
PHP Version: 4.3.3-dev
New Comment:
It also crashes:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
0x40678cd9 in __strtod_internal (nptr=0x8ad63ec "SCREEN",
endptr=0xbfe0225c, group=0) at strtod.c:419
(gdb) bt
#0 0x40678cd9 in __strtod_internal (nptr=0x8ad63ec "SCREEN",
endptr=0xbfe0225c, group=0) at strtod.c:419
#1 0x4067dc59 in strtod (nptr=0x8ad63ec "SCREEN", endptr=0xbfe0225c)
at strtod.c:1425
#2 0x82c5345 in is_numeric_string (str=0x8ad63ec "SCREEN", length=6,
lval=0xbfe022c8, dval=0xbfe022bc,
allow_errors=0 '\000') at
/usr/src/web/php/php4/Zend/zend_operators.h:94
#3 0x82c4ebe in zendi_smart_strcmp (result=0xbfe0242c, s1=0x8ad63ac,
s2=0x88a7764)
at /usr/src/web/php/php4/Zend/zend_operators.c:1670
#4 0x82c3736 in compare_function (result=0xbfe0242c, op1=0x8ad63ac,
op2=0x88a7764)
at /usr/src/web/php/php4/Zend/zend_operators.c:1137
#5 0x82c41a6 in is_equal_function (result=0xbfe0242c, op1=0x8ad63ac,
op2=0x88a7764)
at /usr/src/web/php/php4/Zend/zend_operators.c:1285
#6 0x82dc798 in execute (op_array=0x88a60c8) at
/usr/src/web/php/php4/Zend/zend_execute.c:1931
#7 0x82bc741 in call_user_function_ex (function_table=0x85a7cb0,
object_pp=0x0, function_name=0x88a1744,
retval_ptr_ptr=0xbfe02c44, param_count=3, params=0x8ad6554,
no_separation=1, symbol_table=0x0)
at /usr/src/web/php/php4/Zend/zend_execute_API.c:566
#8 0x82bbee7 in call_user_function (function_table=0x85a7cb0,
object_pp=0x88a0a58, function_name=0x88a1744,
retval_ptr=0x8ad6514, param_count=3, params=0xbfe02cdc) at
/usr/src/web/php/php4/Zend/zend_execute_API.c:408
#9 0x8261550 in xml_call_handler (parser=0x88a0a1c, handler=0x88a1744,
argc=3, argv=0xbfe02cdc)
at /usr/src/web/php/php4/ext/xml/xml.c:377
#10 0x826207c in _xml_startElementHandler (userData=0x88a0a1c,
name=0x8ad6326 "SCREEN", attributes=0x88a0d08)
at /usr/src/web/php/php4/ext/xml/xml.c:661
Diff betweeb 4.2.3 and 4.3.3-dev ext/xml doesn't give any significant
changes, so it must be something else that has changed and just hasn't
been changed also in ext/xml, call_user_function() maybe?
Previous Comments:
[2003-06-15 22:35:36] [EMAIL PROTECTED]
Works fine with PHP 4.2.3, breaks with 4.3.1, 4.3.2, 4.3.3-dev.
[2003-06-04 13:43:11] derek at hostopia dot com
Here as requested is an example which works fine under 4.2.2, and
causes an endless loop in 4.3.2:
This will render a random surprise shape
### CUT HERE ###
";
if ( !xml_parse($parser, $xml) )
{
print xml_error_string(xml_get_error_code($parser));
}
break;
case "SQUARE":
print "\n \n";
print " \n";
print " \n";
print " \n";
print " \n";
print " \n";
print " \n";
print " \n";
break;
case "TRIANGLE":
print "\n ## \n";
print " \n";
print "## \n";
print " \n";
print " ## \n";
print " \n";
print "## \n";
print " \n";
break;
case "CIRCLE":
print "\n \n";
print " \n";
print "## \n";
print "## \n";
print "## \n";
print "## \n";
print " \n";
print " \n";
break;
}
}
function endElement($parser, $name) {
}
function characterData($parser, $data) {
print "$data";
}
function defaultHandler($parser, $data) {
if (substr($data, 0, 1) == "&" && substr($data, -1, 1) == ";") {
printf('%s',
htmlspecialchars($data));
} else {
printf('%s',
htmlspecialchars($data));
}
}
function new_xml_parser($file) {
global $parser_file;
$xml_parser = xml_parser_create();
xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, 1);
xml_set_element_handler($xml_parser, "startElement",
"endElement");
xml_set_character_data_handler($xml_parser, "characterData");
xml_set_default_handler($xml_parser, "defaultHandler");
if (!
#24002 [Opn->Ver]: Nested calls to xml_parse no longer work
ID: 24002
Updated by: [EMAIL PROTECTED]
Reported By: derek at hostopia dot com
-Status: Open
+Status: Verified
Bug Type: XML related
Operating System: Linux
-PHP Version: 4.3.2
+PHP Version: 4.3.3-dev
New Comment:
Works fine with PHP 4.2.3, breaks with 4.3.1, 4.3.2, 4.3.3-dev.
Previous Comments:
[2003-06-04 13:43:11] derek at hostopia dot com
Here as requested is an example which works fine under 4.2.2, and
causes an endless loop in 4.3.2:
This will render a random surprise shape
### CUT HERE ###
";
if ( !xml_parse($parser, $xml) )
{
print xml_error_string(xml_get_error_code($parser));
}
break;
case "SQUARE":
print "\n \n";
print " \n";
print " \n";
print " \n";
print " \n";
print " \n";
print " \n";
print " \n";
break;
case "TRIANGLE":
print "\n ## \n";
print " \n";
print "## \n";
print " \n";
print " ## \n";
print " \n";
print "## \n";
print " \n";
break;
case "CIRCLE":
print "\n \n";
print " \n";
print "## \n";
print "## \n";
print "## \n";
print "## \n";
print " \n";
print " \n";
break;
}
}
function endElement($parser, $name) {
}
function characterData($parser, $data) {
print "$data";
}
function defaultHandler($parser, $data) {
if (substr($data, 0, 1) == "&" && substr($data, -1, 1) == ";") {
printf('%s',
htmlspecialchars($data));
} else {
printf('%s',
htmlspecialchars($data));
}
}
function new_xml_parser($file) {
global $parser_file;
$xml_parser = xml_parser_create();
xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, 1);
xml_set_element_handler($xml_parser, "startElement",
"endElement");
xml_set_character_data_handler($xml_parser, "characterData");
xml_set_default_handler($xml_parser, "defaultHandler");
if (!($fp = @fopen($file, "r"))) {
return false;
}
if (!is_array($parser_file)) {
settype($parser_file, "array");
}
$parser_file[$xml_parser] = $file;
return array($xml_parser, $fp);
}
if (!(list($xml_parser, $fp) = new_xml_parser($file))) {
die("could not open XML input");
}
print "";
while ($data = fread($fp, 4096)) {
if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d\n",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
print "";
print "parse complete\n";
xml_parser_free($xml_parser);
?>
[2003-06-03 22:16:21] [EMAIL PROTECTED]
Please provide a short but complete example script.
[2003-06-03 16:14:29] derek at hostopia dot com
PHP versions up to and including 4.2.2 supported calling xml_parse from
within an xml element/data handler, but when tested with version 4.3.2,
this functionality produces unexpected results.
Sometimes the error 'xml processing instruction not at start of
external entity' occurs, but most of the time the xml parser will get
stuck in an endless loop.
A rather massive PHP application makes use of this feature, and we
currently do not have a work-around.
Basically we need XML elements to be able to give dynamic XML content
to the XML parser.
This was working fine up until now, and is quite important.
Is there a "better way" to accomplish this if in fact this use of
xml_parse is unorthodox?
For example, this XML-based code:
This will render a random surprise shape
Where the element handler for "RANDOM" will give a random XML element
to the parser... i.e.
--
Edit this bug report at http://bugs.php.net/?id=24002&edit=1
#23889 [Asn]: xslt transform stop working after upgrade from 4.2.3 into 4.3.2
ID: 23889
Updated by: [EMAIL PROTECTED]
Reported By: sitnikov at infonet dot ee
Status: Assigned
Bug Type: XSLT related
Operating System: Linux
PHP Version: 4.3.2
Assigned To: msopacua
New Comment:
What is the status of this?? Still a bug or not?
Previous Comments:
[2003-06-06 14:20:42] [EMAIL PROTECTED]
Check bug http://bugs.php.net/20177 (which is mentioned in the
commit).
Before the fix of that bug, many people complained. After - you're the
only one of seen. You also have a work-around: set xslt_set_base
hardcoded yourself, then the library doesn't (see
http://bugs.php.net/20518 ).
If you could make the 'full test suite' available in zip or tar/gz,
then I'll look into your scenario, to see how common it is and perhaps
look for an option to set via xslt_set_option. Either way - you'll
probably have to recode.
[2003-06-06 02:29:16] [EMAIL PROTECTED]
Melvyn, you broke it, you fix it. :)
[2003-05-30 03:45:45] sitnikov at infonet dot ee
After upgrade PHP from 4.2.3 into 4.3.2 xslt transformation stop
working.
1.php (not working)
file_get_contents('xml/1.xml'),
'/_xsl' => file_get_contents('xsl/1.xsl'),
);
// Process the document
if ( $result = xslt_process($xh, 'arg:/_xml', 'arg:/_xsl', NULL,
$arguments) ) {
print "SUCCESS, test.xml was transformed by test.xsl into
result.xml";
print ", result.xml has the following contents\n\n";
print "\n";
echo $result;
print "\n";
}
else {
print "Sorry, test.xml could not be transformed by test.xsl into";
print " result.xml the reason is that " . xslt_error($xh) . " and
the ";
print "error code is " . xslt_errno($xh);
}
xslt_free($xh);
?>
2.php - working
file_get_contents('xml/1.xml'),
);
// Process the document
if ( $result = xslt_process($xh, 'arg:/_xml', 'xsl/1.xsl', NULL,
$arguments) ) {
print "SUCCESS, test.xml was transformed by test.xsl into
result.xml";
print ", result.xml has the following contents\n\n";
print "\n";
echo $result;
print "\n";
}
else {
print "Sorry, test.xml could not be transformed by test.xsl into";
print " result.xml the reason is that " . xslt_error($xh) . " and
the ";
print "error code is " . xslt_errno($xh);
}
xslt_free($xh);
?>
Test full suite: http://si.infonet.ee/sablot.rar
xml & xsl you can see in rar file.
after some research i found what problem in
http://cvs.php.net/diff.php/php4/ext/xslt/sablot.c?login=2&r1=1.63&r2=1.64&ty=u
patch.
after removing this patch my code again work.
--
Edit this bug report at http://bugs.php.net/?id=23889&edit=1
#24005 [Ana->Fbk]: Distributions version of mnoGoSearch extension does not work with MySQL 4
ID: 24005 Updated by: [EMAIL PROTECTED] Reported By: paul at ensigma dot com dot au -Status: Analyzed +Status: Feedback Bug Type: mnoGoSearch related Operating System: RedHat 9 PHP Version: 4.3.2 Assigned To: gluke 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 It should now have the latest mnogosearch extension. Previous Comments: [2003-06-11 00:49:00] [EMAIL PROTECTED] Yes. I will update PHP_4_3 source code branch soon. It means that updates extension will go to possible PHP-4.3.3 release in future. [2003-06-10 23:09:28] paul at ensigma dot com dot au There is still the issue of the old version of mnoGoSearch in the 4.3.2 source code... has that been updated?? [2003-06-10 09:34:41] [EMAIL PROTECTED] It seems to be because of buggy gcc-3.x compiler in your distribution. The normal gcc behavior is to ignore -l switch dupes. [2003-06-06 06:32:32] [EMAIL PROTECTED] Sergey, deal with this. [2003-06-03 21:24:12] paul at ensigma dot com dot au I tried to compile PHP-4.3.2 with the --with-mnogosearch option and with MySQL 4.0.13 installed from RPM . ./configure --with-mysql=/usr --with-gd --with-ttf --enable-track-vars --with-apxs2=/usr/local/apache2/bin/apxs --with-mnogosearch --with-jpeg-dir=/root/source/jpeg-6b/ --with-png-dir=/usr/local/lib/libpng.a --with-zlib-dir=/usr/local/lib/zlib.a --with-tiff-dir=/usr/local/lib/libtiff.a --with-mnogosearch It failed complaining about "ext/mysql/phpmysql.c: undefined reference to mysql_create_db". I downloaded the latest php-extension from www.mnogosearch.org (mnogosearch-php-extension-1.7.3.tar.gz) and replaced the contents of ext/mnogosearch with the files in this archive and it all worked a treat (with a quick edit to remove the second reference to -lmysqlclient in the EXTRA_LIBS line the PHP Makefile... but I think that mnoGo's fault!) -- Edit this bug report at http://bugs.php.net/?id=24005&edit=1
#24196 [Opn->Fbk]: Serialize segfaults in a rare instance
ID: 24196 Updated by: [EMAIL PROTECTED] Reported By: ramato at squiz dot net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Redhat 7.3 PHP Version: 4.3.2 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 And if that crashes too, please try to provide a short example script.. Previous Comments: [2003-06-15 19:27:22] ramato at squiz dot net Description: I'm trying to track down a segfault to do with serializing an object. I can't reproduce it with a small script so I'm not sure where to go from here. Any suggestions, tips, helpful hints greatly appreciated. It's part of a largish CMS which uses lots of circular references so pasting an example isn't easy. I know that circular references are a source of a lot of problems however all the circular references are being removed in the __sleep function so this shouldn't be an issue. Expected result: Normal execution Actual result: -- (gdb) bt #0 0x4023d67e in php_var_serialize_class_name (buf=0xbffddf20, struc=0x8bd961c) at /usr/src/php-4.3.2/ext/standard/var.c:416 #1 0x4023c899 in php_var_serialize_class (buf=0xbffddf20, struc=0x8bd961c, retval_ptr=0x8b43dec, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:430 #2 0x4023cdf5 in php_var_serialize_intern (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:549 #3 0x4023d05b in php_var_serialize (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:623 #4 0x4023d108 in zif_serialize (ht=1, return_value=0x88340d4, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.2/ext/standard/var.c:646 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 (gdb) frame 5 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 1606 ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x4030831b "serialize" -- Edit this bug report at http://bugs.php.net/?id=24196&edit=1
#24041 [Asn]: max_execution_time does not seem to work
ID: 24041 Updated by: [EMAIL PROTECTED] Reported By: jcastro at elnuevodia dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.2 -Assigned To: iliaa +Assigned To: hholzgra New Comment: Hartmut: Your "fix" for something related to some weird keep-alive thing broke this. See SAPI.c:389-398 I tested with Apache and it left apache hang around forever after first request that failed when max_input_time kicked in. Settings: max_execution_time = 2 max_input_time = 1 And upload big enough file. Might hang also in the first try, just check what the apache childs are doing after the request hangs: (gdb) bt #0 0x401e7a34 in __libc_read () from /lib/libc.so.6 #1 0x80a4594 in ?? () #2 0x8054475 in buff_read () #3 0x805441b in saferead_guts () #4 0x8052df2 in read_with_errors () #5 0x8053026 in ap_bread () #6 0x8066d32 in ap_get_client_block () #7 0x4034a116 in sapi_apache_read_post ( buffer=0xbfffe028 "Vajfæ3\"[EMAIL PROTECTED]&[EMAIL PROTECTED]"@\005¾\200\021x\002R@)\202Õ\215\210\002\230q\021pÆ\nqÔ\006à¾R\005f²\024X¿N 2¡Q\tÜ\004 \200B<\001H ò\200d\221\034(v¡Hð\t. +»\200\023\020\223q\034M¶É8Y'K\001\236ì\223\201²¦\005Ä»\230\020\207¼á1\224±Å@<¦S", count_bytes=3999) at /usr/src/web/php/php4/sapi/apache/mod_php4.c:146 #8 0x402fac3a in sapi_deactivate () at /usr/src/web/php/php4/main/SAPI.c:395 #9 0x402f3aa3 in php_request_shutdown (dummy=0x0) at /usr/src/web/php/php4/main/main.c:999 #10 0x4034a66d in php_apache_request_shutdown (dummy=0x0) at /usr/src/web/php/php4/sapi/apache/mod_php4.c:302 #11 0x80518a1 in run_cleanups () #12 0x804fec5 in ap_clear_pool () #13 0x804ff47 in ap_destroy_pool () #14 0x8061943 in child_main () #15 0x8061b8a in make_child () #16 0x8061c46 in startup_children () #17 0x80622dd in standalone_main () #18 0x8062b6c in main () #19 0x401599cb in __libc_start_main (main=0x80627a8 , argc=1, argv=0xb674, init=0x804ecfc <_init>, fini=0x8082e34 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>, stack_end=0xb66c) at ../sysdeps/generic/libc-start.c:92 Previous Comments: [2003-06-15 18:08:57] [EMAIL PROTECTED] Ilia: You messed with this the last time. And it really doesn't work with Apache either..(tried setting the execution time to 2 and max_input_time to 1, latter has no kind of effect) [2003-06-11 19:49:34] [EMAIL PROTECTED] Quick analysis: The max_input_timeout is set in main.c for the request startup and should override the timeout for execution time..but it seems like the max_execution_time is not reset again after request startup is over. (hope someone else sees this and can check it out too :) [2003-06-05 10:25:27] jcastro at elnuevodia dot com I have a page that people use to upload files. I changed from 4.2.3 to 4.3.2 my configuration is max_execution_time = 3600 max_input_time = 60 memory_limit = 22M web server: iis The upload process will work for about 5 minutes and then stop. I will get and error message in my syslog saying that the script terminated because it ran for more than 3600. That is imposible since it ran for only 4 or 5 minutes. I had to go back to 4.2.3. I even set the max_execution_time to 0 and I still get the same error, except the message change from 3600 to 0. Keep in mind that I did not change any IIS configuration. just the php version toi make it work again. -- Edit this bug report at http://bugs.php.net/?id=24041&edit=1
#24197 [Opn->Bgs]: @$_GET[""] doesn't work properly
ID: 24197
Updated by: [EMAIL PROTECTED]
Reported By: elaine_sit at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Windows 2000
PHP Version: 4.3.2
New Comment:
Turn off all magic_quotes* settings in your php.ini.
Previous Comments:
[2003-06-15 21:40:35] elaine_sit at yahoo dot com
Description:
@$_GET[""] doesn't work properly (a backslace is added) when some
encoded chinese character contains "%5C" such as "³\" or "¥\".
Reproduce code:
---
=
In file "test1.php"
$name="³\¦¨¥\";
HEADER("Location:test2.php?message=".urlencode($name));
=
In file "test2.php"
$smessage = @$GET["message"];
echo urlencode($smessage)."";
=
Expected result:
In page "test2.php"
A message of "³\¦¨¥\" should be displayed properly.
Actual result:
--
However, a message of "³\\¦¨¥\\" is displayed where 2 "\" is added.
--
Edit this bug report at http://bugs.php.net/?id=24197&edit=1
#24197 [NEW]: @$_GET[""] doesn't work properly
From: elaine_sit at yahoo dot com
Operating system: Windows 2000
PHP version: 4.3.2
PHP Bug Type: Output Control
Bug description: @$_GET[""] doesn't work properly
Description:
@$_GET[""] doesn't work properly (a backslace is added) when some encoded
chinese character contains "%5C" such as "³\" or "¥\".
Reproduce code:
---
=
In file "test1.php"
$name="³\¦¨¥\";
HEADER("Location:test2.php?message=".urlencode($name));
=
In file "test2.php"
$smessage = @$GET["message"];
echo urlencode($smessage)."";
=
Expected result:
In page "test2.php"
A message of "³\¦¨¥\" should be displayed properly.
Actual result:
--
However, a message of "³\\¦¨¥\\" is displayed where 2 "\" is added.
--
Edit bug report at http://bugs.php.net/?id=24197&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24197&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24197&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24197&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24197&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24197&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24197&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24197&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24197&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24197&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24197&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24197&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24197&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24197&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24197&r=gnused
#24196 [NEW]: Serialize segfaults in a rare instance
From: ramato at squiz dot net Operating system: Redhat 7.3 PHP version: 4.3.2 PHP Bug Type: Reproducible crash Bug description: Serialize segfaults in a rare instance Description: I'm trying to track down a segfault to do with serializing an object. I can't reproduce it with a small script so I'm not sure where to go from here. Any suggestions, tips, helpful hints greatly appreciated. It's part of a largish CMS which uses lots of circular references so pasting an example isn't easy. I know that circular references are a source of a lot of problems however all the circular references are being removed in the __sleep function so this shouldn't be an issue. Expected result: Normal execution Actual result: -- (gdb) bt #0 0x4023d67e in php_var_serialize_class_name (buf=0xbffddf20, struc=0x8bd961c) at /usr/src/php-4.3.2/ext/standard/var.c:416 #1 0x4023c899 in php_var_serialize_class (buf=0xbffddf20, struc=0x8bd961c, retval_ptr=0x8b43dec, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:430 #2 0x4023cdf5 in php_var_serialize_intern (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:549 #3 0x4023d05b in php_var_serialize (buf=0xbffddf20, struc=0x8bd961c, var_hash=0xbffddf30) at /usr/src/php-4.3.2/ext/standard/var.c:623 #4 0x4023d108 in zif_serialize (ht=1, return_value=0x88340d4, this_ptr=0x0, return_value_used=1) at /usr/src/php-4.3.2/ext/standard/var.c:646 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 (gdb) frame 5 #5 0x402c8947 in execute (op_array=0x8cb5da4) at /usr/src/php-4.3.2/Zend/zend_execute.c:1606 1606 ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x4030831b "serialize" -- Edit bug report at http://bugs.php.net/?id=24196&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24196&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24196&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24196&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24196&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24196&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24196&r=support Expected behavior: http://bugs.php.net/fix.php?id=24196&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24196&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24196&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24196&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24196&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24196&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24196&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24196&r=gnused
#24112 [Opn->Fbk]: php_admin_value defaults - open_basedir
ID: 24112 Updated by: [EMAIL PROTECTED] Reported By: pd at pauldemarco dot com -Status: Open +Status: Feedback -Bug Type: PHP options/info functions +Bug Type: Scripting Engine problem Operating System: redhat 7.3 PHP Version: 4.3.2 New Comment: Could you try commenting out the open_basedir in your php.ini? Previous Comments: [2003-06-10 09:44:07] pd at pauldemarco dot com ignore the message about /tmp, due to the previousily mentioned randomness, it appeared to go away, but is still present, explicitly setting the open_basedir at the virtual host level is the only thing that removes the error consistently [2003-06-10 09:32:23] pd at pauldemarco dot com if someone can confirm the behavorial difference on this between 4.3.0 and 4.3.2 Does 4.3.0 automatically add /tmp/ to open_basedir, but 4.3.2 does not? This is a phpbb installation, its failing on its cached templating files, and occasionally on file uploads. If the above /tmp behavior is correct, then that would explain why it breaks in 4.3.2, however the error messages are still very wrong as they list other virtual-hosts open_basedir settings [2003-06-10 08:19:07] pd at pauldemarco dot com This problem does not occur on 4.3.0, with the same configure line (any basic configuration will do). Sadly, I cannot provide any real error information, as it is not crashing, but the behavior is fairly predictable. I have a open_basedir setting in php.ini, confirmed via phpinfo(), its value is not important. On each of the configured virtual hosts I have a different value using php_admin_value. However, on some virtual hosts I turn safe_mode off using php_admin_flag and do not set an open_basedir value, so it should be using the php.ini setting. Turning safe mode off is probably not relevant, but trying to provide any related information. When requesting pages on that virtual host (the one with no overriding open_basedir setting, and safe mode off), the requests will randomly fail. When checking the error log, it is a normal exit and php is logging that 'open_basedir restriction in effect ... ' The path that it provides as the active open_basedir value is not correct. It in fact randomly changes to other virtual hosts settings. It does not always fail, it may take 20 requests before it does (even a simple auto-refreshing page, will fail shortly with that error). I believe there may be a bug in reverting to the default configuration value, and using an old value in memory. I am using prefork in apache, so it would most likely have to be an uninitialized pointer to the same memory space, memory spaces for new forked processes should be repeatable. Well thats about all I can provide, it can be fixed by explicitly stating the open_basedir value in each virtual host (so ones where before I kept it at the default value, now explicitly set the default value). I'm more than happy to follow any instructions to get further information on this, just not sure what to do as its not an actual crash or anything. -- Edit this bug report at http://bugs.php.net/?id=24112&edit=1
#24041 [Opn->Asn]: max_execution_time does not seem to work
ID: 24041 Updated by: [EMAIL PROTECTED] Reported By: jcastro at elnuevodia dot com -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.2 -Assigned To: +Assigned To: iliaa New Comment: Ilia: You messed with this the last time. And it really doesn't work with Apache either..(tried setting the execution time to 2 and max_input_time to 1, latter has no kind of effect) Previous Comments: [2003-06-11 19:49:34] [EMAIL PROTECTED] Quick analysis: The max_input_timeout is set in main.c for the request startup and should override the timeout for execution time..but it seems like the max_execution_time is not reset again after request startup is over. (hope someone else sees this and can check it out too :) [2003-06-05 10:25:27] jcastro at elnuevodia dot com I have a page that people use to upload files. I changed from 4.2.3 to 4.3.2 my configuration is max_execution_time = 3600 max_input_time = 60 memory_limit = 22M web server: iis The upload process will work for about 5 minutes and then stop. I will get and error message in my syslog saying that the script terminated because it ran for more than 3600. That is imposible since it ran for only 4 or 5 minutes. I had to go back to 4.2.3. I even set the max_execution_time to 0 and I still get the same error, except the message change from 3600 to 0. Keep in mind that I did not change any IIS configuration. just the php version toi make it work again. -- Edit this bug report at http://bugs.php.net/?id=24041&edit=1
#21513 [Ver->Asn]: shutdown functions not executed if timed out
ID: 21513 Updated by: [EMAIL PROTECTED] Reported By: ceeam at mail dot ru -Status: Verified +Status: Assigned Bug Type: Scripting Engine problem Operating System: windows (only) -PHP Version: 4.3.0 +PHP Version: 4.3.2 -Assigned To: +Assigned To: zeev New Comment: Seems to happen with PHP 5 too. :) Previous Comments: [2003-06-15 17:47:06] sergio at libero dot it This bug is still present in version 4.3.2 :-( [2003-05-06 02:34:18] nut at tutu dot com Somebody DO FINALLY SOMETHING WITH THIS! Please! [2003-03-24 17:58:04] prac1 at dynawest dot cz The bug appears for both timeouts - by set_time_limit() and php.ini's max_execution_time. [2003-03-24 17:18:23] prac1 at dynawest dot cz I have Win2000 SP2, Apache 1.3.27, PHP 4.2.2 and 4.3.0, and using this the problem appears too. [2003-02-02 15:33:25] [EMAIL PROTECTED] tests/func/005a.phpt also failed with latestest win32 snap on W2k server. 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/21513 -- Edit this bug report at http://bugs.php.net/?id=21513&edit=1
#23906 [Opn->Fbk]: Immediate segfault on startup
ID: 23906 Updated by: [EMAIL PROTECTED] Reported By: mbrennen at fni dot com -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: MDK 8.2 (Linux 2.4) PHP Version: 4.3.2 New Comment: Can you please try reducing the configure options to only contain the apache and imap related options? And also try compiling PHP as DSO. Previous Comments: [2003-06-06 19:12:59] mbrennen at fni dot com As originally stated, 4.3.0 runs with --with-imap-ssl; 4.3.2 segfaults on startup with that option, all other things being equal. Why is that NOT a bug? I see no reason why you keep classifying the bug as bogus. I am very open to hearing why this is not a 4.3.2 bug, but the reason must be valid. Your claim that IMAP was built without SSL support is not true. [2003-06-06 18:43:26] [EMAIL PROTECTED] If it works without --with-imap-ssl, what is the problem? [2003-06-06 10:51:55] mbrennen at fni dot com The c-client is built with SSL support. There are two MDK 8.2 IMAP RPMs installed on the server. imap-2001a-5.1mdk imap-devel-2001a-5.1mdk Running 'strings /usr/lib/libc-client.a' I see references to ssl_open, ssl_aopen, ssl_getline, ssl_getbuffer and other ssl functions. There is also a libc-client-nossl.a library. It seems safe to assume that the libc-client.a I am linking against was built with SSL support. Do you disagree? Why did the --with-imap-ssl configuration work without problem on 4.3.0 on exactly the same server, with the same RPM set? Is there perhaps an openssl version dependency change between 4.3.0 and 4.3.2? The following SSL RPMs are installed. Does 4.3.2 depend on a later version? libopenssl0-devel-0.9.6i-1.4mdk openssl-0.9.6i-1.4mdk libopenssl0-0.9.6i-1.4mdk [2003-06-06 06:30:35] [EMAIL PROTECTED] Why do you add --with-imap-ssl if the c-client is not build with SSL support? Not PHP bug. [2003-06-02 14:41:55] mbrennen at fni dot com gdb version: GNU gdb 5.1.1 (via RPM on Mandrake 8.2) IMAP is imap-2001a via RPM on Mandrake 8.2. openssl is openssl-0.9.6c, again via RPM on Mandrake 8.2. There is no other version of openssl on the box. I have verified that it is the imap_ssl option; with just imap apache starts okay. PHP 4.3.0 works fine on the same servers. On the servers that I've done testing on so far IMAP is not actually used, so there isn't a c-client configuration per se that I am aware of. It isn't that apache dies when using IMAP; it segfaults very quickly during startup. Thanks, glad to help debug as needed... 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/23906 -- Edit this bug report at http://bugs.php.net/?id=23906&edit=1
#21513 [Com]: shutdown functions not executed if timed out
ID: 21513 Comment by: sergio at libero dot it Reported By: ceeam at mail dot ru Status: Verified Bug Type: Scripting Engine problem Operating System: windows (only) PHP Version: 4.3.0 New Comment: This bug is still present in version 4.3.2 :-( Previous Comments: [2003-05-06 02:34:18] nut at tutu dot com Somebody DO FINALLY SOMETHING WITH THIS! Please! [2003-03-24 17:58:04] prac1 at dynawest dot cz The bug appears for both timeouts - by set_time_limit() and php.ini's max_execution_time. [2003-03-24 17:18:23] prac1 at dynawest dot cz I have Win2000 SP2, Apache 1.3.27, PHP 4.2.2 and 4.3.0, and using this the problem appears too. [2003-02-02 15:33:25] [EMAIL PROTECTED] tests/func/005a.phpt also failed with latestest win32 snap on W2k server. [2003-01-22 22:44:36] [EMAIL PROTECTED] I can not reproduce this with PHP CGI/CLI/Apache DSO, but Steph tested the script under windows and got the same results as [EMAIL PROTECTED] did so this is definately a windows-only bug. 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/21513 -- Edit this bug report at http://bugs.php.net/?id=21513&edit=1
#14542 [Com]: register_shutdown_function() timeout problem
ID: 14542 Comment by: sergio at libero dot it Reported By: dward at maidencreek dot com Status: Closed Bug Type: Scripting Engine problem Operating System: Linux 2.4.5 PHP Version: 4.3.0 New Comment: This bug has been not fixed on win32. I've tried to execute this script PHP says: Fatal error: Maximum execution time of 1 second exceeded in C:\Inetpub\wwwroot\php\mynewsgate\shutdown.php on line 11 Fatal error: Maximum execution time of 1 second exceeded in C:\Inetpub\wwwroot\php\mynewsgate\shutdown.php on line 6 I've used PHP 4.3.2 on windows xp Previous Comments: [2003-01-22 23:17:05] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-10 22:23:58] [EMAIL PROTECTED] Verified with latest CVS and 4.3.0. [2002-12-08 10:38:04] [EMAIL PROTECTED] Verified with 4.3.0-dev at this date. [2002-06-16 00:11:57] [EMAIL PROTECTED] reclassified. [2002-04-27 19:09:27] [EMAIL PROTECTED] It's not fixed.. 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/14542 -- Edit this bug report at http://bugs.php.net/?id=14542&edit=1
#23942 [Opn->Bgs]: php 4.3.x causes apache2+mod_ssl to sigsev on client authentication
ID: 23942 Updated by: [EMAIL PROTECTED] Reported By: alextxm at tin dot it -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: Yes, just what I expected. It's not really our problem, most likely mysql does some fancy init stuff with openssl, or you just mix two different openssl versions. Try compiling everything from sources with debug symbols, I guess mysql and openssl have some --enable-debug switch too. Then you'll get better GDB backtrace. Previous Comments: [2003-06-15 14:14:22] alextxm at tin dot it more news: i've jsut tried recompiling mysql without openssl support on both the gentoo platforms (as of RH9, cfr ldd output in my previous comment) and php now work as expected with --with-mysql=/usr. So the whole things seems to be related to openssl support in MySQL. Is still the whole thing pertinent to php or should I ask mysql people ? alessandro [2003-06-15 13:56:18] alextxm at tin dot it output of ldd libmysqlclient.so for each platform (cfr. my previous comment) : rh9) libz.so.1 => /usr/lib/libz.so.1 (0x40053000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40061000) libnsl.so.1 => /lib/libnsl.so.1 (0x4008e000) libm.so.6 => /lib/tls/libm.so.6 (0x400a4000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.2) libz.so.1 => /usr/lib/libz.so.1 (0x40047000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40055000) libnsl.so.1 => /lib/libnsl.so.1 (0x40082000) libm.so.6 => /lib/libm.so.6 (0x40097000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400b8000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x400e6000) libc.so.6 => /lib/libc.so.6 (0x401d9000) libdl.so.2 => /lib/libdl.so.2 (0x402fc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.4) libz.so.1 => /usr/lib/libz.so.1 (0x40052000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4006) libnsl.so.1 => /lib/libnsl.so.1 (0x4008d000) libm.so.6 => /lib/libm.so.6 (0x400a1000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x400c3000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400f1000) libc.so.6 => /lib/libc.so.6 (0x401b1000) libdl.so.2 => /lib/libdl.so.2 (0x402da000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) i'm also investigating more things... let me know if you need to me to test some specific items alessandro [2003-06-14 17:19:25] [EMAIL PROTECTED] That sounds odd. And as you're not running Apache2 as threaded (worker, or whatever that MPM was again), it shouldn't be thread-safety issue either. Could you check what libmysqlclient.so is linked with on those systems? Output of: # ldd libmysqlclient.so And FYI: the bundled mysql library is far from obsolete. (it works, doesn't it? :) [2003-06-14 15:40:21] alextxm at tin dot it finally, i've found the problem: compiling php 4.3.2 with --with-mysql=/path-to-mysql staically linked is the culprit. The problem can be avoided using --with-mysql and so using PHP's built-in (but obsolete) mysql interface or using: --with-mysql=shared,/path-to-mysql and then enabling php_mysql.so in php.ini Tests had been accomplished on three machines: a) gentoo linux 1.2: glibc 2.2.5, php 4.3.2, apache 2.0.45/46, mysql 4.0.12, openssl 0.9.6j b) gentoo linux 1.4rc4: glibc 2.3.1, php 4.3.2, apache 2.0.46, mysql 4.0.13, openssl 0.9.7b c) redhat 9: php 4.2.2, apache 2.0.40, openssl 0.9.7a, mysql-4.0.10 alessandro [2003-06-14 08:02:41] alextxm at tin dot it i'm doing some more tests... an interesting thing: on Redhat 9.0 it works fine (openssl 0.9.7a, php 4.2.2, apache 2.0.40 - both stock versions) . I'm trying to figure out where the problem is. I'll let you know, probaly there is something in my setup which causes php or apache to behave strangely. alessandro 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/23942 -- Edit this bug report at http://bugs.php.net/?id=23942&edit=1
#13636 [Com]: configure doesn't find librecode
ID: 13636 Comment by: php_public at macfreek dot nl Reported By: arne at dome dot net dot tw Status: Bogus Bug Type: Recode related Operating System: FreeBSD 4.1-RELEASE PHP Version: 4.0.6 New Comment: Just letting you know I've got the same problem, with Mac OS X (10.2.6), PHP 4.3.2 and Recode 3.6 (3.6-6, installed using fink). The error I got in config.log: ld: Undefined symbols: _error Previous Comments: [2003-03-10 04:58:25] mbr at freebsd dot org I have a fix for this. Please look at: http://people.freebsd.org/~mbr/patches/patch-php+recode.diff This is a librecode problem, not a PHP problem. Martin [2001-11-10 04:31:26] [EMAIL PROTECTED] There is something wrong with your install of recode libraries and this is not support forum for FreeBSD so ask them for help on this part. PHP's configure can not do anything if your system is broken. [2001-11-05 20:58:10] arne at dome dot net dot tw Ok, I tried it this way: I removed the libraries as requested and tried to configure php again -> same error like before Then I tried to compile recode from source (this time without the ports patches) again, but it failed. Then used the ports directory to recompile recode successfully. Then I configured php again -> same error. BTW: the librarues are librecode.so and librecode.so.3, not librecode.so.2. I also tried to make a symbolic link to the library with the suffix '2', but no success... [2001-11-02 02:42:02] [EMAIL PROTECTED] Seems like there is something wrong with the shared lib. Try removing those librecode.so and librecode.so.2 files and try to configure PHP again. --Jani [2001-11-01 03:32:08] arne at dome dot net dot tw ldd librecode.so says: librecode.so: ldd: librecode.so: Exec format error librecode.so: exit status 1 recode is version 3.6 compiled from the FreeBSD ports directory. Using recode from the command line works properly. Meanwhile I updated the OS to FreeBSD 4.4-STABLE. 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/13636 -- Edit this bug report at http://bugs.php.net/?id=13636&edit=1
#18371 [Csd->Bgs]: --enable-discard-path breaks php-cgi
ID: 18371 Updated by: [EMAIL PROTECTED] Reported By: janus at area319 dot de -Status: Closed +Status: Bogus Bug Type: CGI related Operating System: ALL PHP Version: 4.3.2 New Comment: .. Previous Comments: [2003-06-15 16:16:33] janus at area319 dot de If you ignore the CGI-API, go on. I give a sh*t on php, it's only for my customers, and if they ask me for the broken ENV vars, i refer to this bug report. What a pity... and i gave php a chance. [2003-06-06 00:59:19] [EMAIL PROTECTED] Please read Shane's comment again.. [2003-06-05 16:01:09] janus at area319 dot de Read my previous posts!! It's still the same setup, nothing changed except the PHP version, so please don't bother me with newbie-treatment. ``To get PHP to handle PATH_INFO and PATH_TRANSLATED information correctly with this setup, the php parser should be compiled with the --enable-discard-path configure option.'' That's true and the reason why i need --enable-discard-path working again. [2003-06-03 02:52:38] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. I do beleive you should not have any configuration for PHP in httpd.conf when you use --enable-discard-path? See http://www.php.net/manual/en/security.cgi-bin.php Case 4. If properly configured in this situation, you should not see the self parsing bug. If --enable-discard-path is not what you really want, use --enable-force-cgi-redirect with the configuration you provided a long time ago. [2003-06-01 16:28:20] janus at area319 dot de Wow! Incredible, it's back again. Powered by 4.3.2-RELEASE this time. 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/18371 -- Edit this bug report at http://bugs.php.net/?id=18371&edit=1
#24195 [Csd->Bgs]: ./configure script fails to detect libpng/libjpeg/etc.
ID: 24195 Updated by: [EMAIL PROTECTED] Reported By: live at generation dot net -Status: Closed +Status: Bogus -Bug Type: *Configuration Issues +Bug Type: GD related Operating System: RedHat 9 PHP Version: 4.3.2 New Comment: User error -> bogus. Previous Comments: [2003-06-15 14:06:50] live at generation dot net Argh! Forget it. I needed the damned -devel packages. [2003-06-15 14:01:36] live at generation dot net Description: Hello. When trying to run ./configure with the options to enable GD with support for jpeg/png/etc, configure fails not being able to find the appropriate lib files. If I'm not mistaken, looking at the configure script, it's looking for libpng.so or libjpeg.so, while in RedHat 9, those files are called, for example, libpng.so.3, effectively making it so configure fails in finding the appropriate lib files... [15/06-14:47] [EMAIL PROTECTED] - /usr/local/src/php-4.3.2] # ls -l /usr/lib/libpng.so* lrwxrwxrwx1 root root 19 Jun 12 16:34 /usr/lib/libpng.so.3 -> libpng12.so.0.1.2.2* lrwxrwxrwx1 root root 19 Jun 12 16:34 /usr/lib/libpng.so.3.1.2.2 -> libpng12.so.0.1.2.2* Comparing with a RedHat 7.3 box, I see they used to also include a symlink pointing /usr/lib/libpng.so to /usr/lib/libpng.so.2. Guess they "forgot" or changed their way of doing. The quickfix way is most probably to add the symlinks myself, pointing libpng.so to libpng.so.3, but still... Is there something to be done for this in PHP's configure script? Or should this be considered a RedHat bug? Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-exif --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-ttf=/usr --with-freetype-dir=/usr --with-gettext checking for GD support... yes checking for the location of libjpeg... /usr checking for the location of libpng... /usr checking for the location of libXpm... no checking for FreeType 1.x support... /usr checking for FreeType 2... /usr checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. -- Edit this bug report at http://bugs.php.net/?id=24195&edit=1
#24174 [Fbk]: Seg. fault when calling imagecreatefromstring
ID: 24174
Updated by: [EMAIL PROTECTED]
Reported By: legion at altlinux dot org
Status: Feedback
Bug Type: GD related
Operating System: ALTLinux
PHP Version: 4.3.2
New Comment:
And if you get the same segfault with --with-gd (ie. the bundled GD),
then provide a GDB backtrace.
Previous Comments:
[2003-06-15 14:20:00] [EMAIL PROTECTED]
I would recomment to use the bundled GD library which you can enable by
using --with-gd (without path). Can you try that?
[2003-06-15 11:57:14] legion at altlinux dot org
This was my configure command:
configure --with-gd=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr
--with-xpm-dir=/usr/X11R6 --with-t1lib --with-ttf=/usr
--with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr
What is the version libgd do you use ? Maybe this is problem on my
side...
[2003-06-13 08:36:58] [EMAIL PROTECTED]
And what was the configure line you used to configure PHP?
(note: This does NOT crash for me)
[2003-06-13 08:33:40] legion at altlinux dot org
Description:
Script segfaults when calling function imagecreatefromstring() with
built-in font.
PHP version: 4.3.2 (cvs snapshot 20030609)
GD version: 2.0.4
Reproduce code:
---
$tmpfilename = tempnam ("/tmp", "FOO");
$im = imagecreate(200, 100);
$black = imagecolorallocate ($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
imagefill($im, 0, 0, $black);
$string = '::: Oops! :::';
imagestring($im, 3, 0, 10, $string, $orange);
imagejpeg($im, $tmpfilename);
imagedestroy($im);
$fp = fopen($tmpfilename, 'r');
while (!feof ($fp)) { $content .= fgets($fp, 4096); }
fclose($fp);
$img = imagecreatefromstring($content);
// following function will be work
// $img = imagecreatefromjpeg($tmpfilename);
header ("Content-type: image/jpeg");
imagejpeg($img);
imagedestroy($img);
unlink($tmpfilename);
Expected result:
Must be generate jpeg image.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=24174&edit=1
#24194 [Opn->Bgs]: XPath only supporting absolute location paths?
ID: 24194
Updated by: [EMAIL PROTECTED]
Reported By: markus dot pfefferle at web dot de
-Status: Open
+Status: Bogus
Bug Type: DOM XML related
Operating System: Windows 2000
PHP Version: 4.3.2
New Comment:
See bug #24168
Previous Comments:
[2003-06-15 11:16:45] markus dot pfefferle at web dot de
Description:
By the definition of XPath from http://www.w3.org/TR/xpath, the xpath
expression 'foo' (being an abbreviated syntax of 'child::foo') is a
Relative Location Path and would reference to all child nodes of the
given context node with a tagname of 'foo'.
The expression '/foo' ('/child::foo') is an Absolute Location Path
which references the child nodes named 'foo' of the context node's
document root node.
So the following small code:
$s = '';
$s .= '';
$s .= '';
$s .= '';
$doc = domxml_open_mem($s);
$ctx = xpath_new_context($doc);
$n = xpath_eval($ctx, 'foo');
should by strict XPath definition result in the refrencing of the
element just because foo is a child node of the document root node.
However, this always results in an empty $n->nodeset. This is the first
error.
The Absolute Location Path '/foo' however, used in the above
xpath_eval(), would deliver the expected node correctly in
$n->nodeset[0].
Now if we use this node as a new context node:
$ctx = xpath_new_context($n->nodeset[0]);
$n = xpath_eval($ctx, 'bar');
Again, by W3C Definition, this should deliver the bar-Element, but
instead it will find nothing. Altering the expression to '/bar' however
suddenly finds the bar-Node. But this is incorret, since the expression
'/bar' would read "the child nodes of the context node's document's
root node named 'bar'" - which are non-existent, because the document's
root node only child node is 'foo'.
So instead the current implementation of XPath seems to treat the
preceding slash as mandatory and only referencing to the context node -
not the document root.
This is not in accordance to XPath!
Reproduce code:
---
$s = '';
$s .= '';
$s .= '';
$s .= 'abc';
$s .= '';
$s .= '';
$doc = domxml_open_mem($s);
$ctx = xpath_new_context($doc);
$a = xpath_eval($ctx, 'foo');
$b = xpath_eval($ctx, '/foo');
$ctx = xpath_new_context($b->nodeset[0]);
$c = xpath_eval($ctx, 'bar');
$d = xpath_eval($ctx, '/bar');
echo "a = $a b = $b c = $c d = $d";($ctx, '/foo');
Expected result:
a = Object
b = Object
c = Object
d =
Actual result:
--
a =
b = Object
c =
d = Object
--
Edit this bug report at http://bugs.php.net/?id=24194&edit=1
#24189 [Csd->Bgs]: big problem on stream function
ID: 24189 Updated by: [EMAIL PROTECTED] Reported By: anton at valuehost dot ru -Status: Closed +Status: Bogus Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: let's keep this bogus.. Previous Comments: [2003-06-15 11:02:43] anton at valuehost dot ru Do not want to help well and it is not necessary, in backtrace I and itself can understand. [2003-06-15 10:58:08] [EMAIL PROTECTED] Not enough information -> bogus. (get rid of the zendoptimizer on some machine and provide a backtrace, otherwise -> not bug) [2003-06-15 10:55:20] anton at valuehost dot ru In it that all and the problem, on dev server to us was not possible to receive this mistake. The problem arises on production a level what from scripts of users of her causes to understand not really, we hold over 25000 sites. We at once find out any mistakes and we celebrate them quickly enough, and this of us has led up a blind alley :( But I can tell precisely, that all functions which work with socket cease to work, what that restriction on work mod_php is imposed. [2003-06-15 10:25:52] [EMAIL PROTECTED] You should have a dev machine to test this on. Just leave ZendOptimizer out. If you can't do this and can't provide decent backtrace, we can't fix anything. [2003-06-15 07:49:27] anton at valuehost dot ru It is impossible to switch off ZendOptimazer, on servers is from 500 up to 1500 sites, the some people use Zend if we shall switch off it at us there will be problems. Let's think as it is possible to make it without deenergizing, can be ktrace will approach? 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/24189 -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#18371 [Bgs->Csd]: --enable-discard-path breaks php-cgi
ID: 18371 User updated by: janus at area319 dot de Reported By: janus at area319 dot de -Status: Bogus +Status: Closed Bug Type: CGI related Operating System: ALL PHP Version: 4.3.2 New Comment: If you ignore the CGI-API, go on. I give a sh*t on php, it's only for my customers, and if they ask me for the broken ENV vars, i refer to this bug report. What a pity... and i gave php a chance. Previous Comments: [2003-06-06 00:59:19] [EMAIL PROTECTED] Please read Shane's comment again.. [2003-06-05 16:01:09] janus at area319 dot de Read my previous posts!! It's still the same setup, nothing changed except the PHP version, so please don't bother me with newbie-treatment. ``To get PHP to handle PATH_INFO and PATH_TRANSLATED information correctly with this setup, the php parser should be compiled with the --enable-discard-path configure option.'' That's true and the reason why i need --enable-discard-path working again. [2003-06-03 02:52:38] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. I do beleive you should not have any configuration for PHP in httpd.conf when you use --enable-discard-path? See http://www.php.net/manual/en/security.cgi-bin.php Case 4. If properly configured in this situation, you should not see the self parsing bug. If --enable-discard-path is not what you really want, use --enable-force-cgi-redirect with the configuration you provided a long time ago. [2003-06-01 16:28:20] janus at area319 dot de Wow! Incredible, it's back again. Powered by 4.3.2-RELEASE this time. [2002-12-03 01:09:41] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. don't use discard path. but really, fixed in cvs. 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/18371 -- Edit this bug report at http://bugs.php.net/?id=18371&edit=1
#24174 [Opn->Fbk]: Seg. fault when calling imagecreatefromstring
ID: 24174
Updated by: [EMAIL PROTECTED]
Reported By: legion at altlinux dot org
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: ALTLinux
PHP Version: 4.3.2
New Comment:
I would recomment to use the bundled GD library which you can enable by
using --with-gd (without path). Can you try that?
Previous Comments:
[2003-06-15 11:57:14] legion at altlinux dot org
This was my configure command:
configure --with-gd=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr
--with-xpm-dir=/usr/X11R6 --with-t1lib --with-ttf=/usr
--with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr
What is the version libgd do you use ? Maybe this is problem on my
side...
[2003-06-13 08:36:58] [EMAIL PROTECTED]
And what was the configure line you used to configure PHP?
(note: This does NOT crash for me)
[2003-06-13 08:33:40] legion at altlinux dot org
Description:
Script segfaults when calling function imagecreatefromstring() with
built-in font.
PHP version: 4.3.2 (cvs snapshot 20030609)
GD version: 2.0.4
Reproduce code:
---
$tmpfilename = tempnam ("/tmp", "FOO");
$im = imagecreate(200, 100);
$black = imagecolorallocate ($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
imagefill($im, 0, 0, $black);
$string = '::: Oops! :::';
imagestring($im, 3, 0, 10, $string, $orange);
imagejpeg($im, $tmpfilename);
imagedestroy($im);
$fp = fopen($tmpfilename, 'r');
while (!feof ($fp)) { $content .= fgets($fp, 4096); }
fclose($fp);
$img = imagecreatefromstring($content);
// following function will be work
// $img = imagecreatefromjpeg($tmpfilename);
header ("Content-type: image/jpeg");
imagejpeg($img);
imagedestroy($img);
unlink($tmpfilename);
Expected result:
Must be generate jpeg image.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=24174&edit=1
#23942 [Opn]: php 4.3.x causes apache2+mod_ssl to sigsev on client authentication
ID: 23942 User updated by: alextxm at tin dot it Reported By: alextxm at tin dot it Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: more news: i've jsut tried recompiling mysql without openssl support on both the gentoo platforms (as of RH9, cfr ldd output in my previous comment) and php now work as expected with --with-mysql=/usr. So the whole things seems to be related to openssl support in MySQL. Is still the whole thing pertinent to php or should I ask mysql people ? alessandro Previous Comments: [2003-06-15 13:56:18] alextxm at tin dot it output of ldd libmysqlclient.so for each platform (cfr. my previous comment) : rh9) libz.so.1 => /usr/lib/libz.so.1 (0x40053000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40061000) libnsl.so.1 => /lib/libnsl.so.1 (0x4008e000) libm.so.6 => /lib/tls/libm.so.6 (0x400a4000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.2) libz.so.1 => /usr/lib/libz.so.1 (0x40047000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40055000) libnsl.so.1 => /lib/libnsl.so.1 (0x40082000) libm.so.6 => /lib/libm.so.6 (0x40097000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400b8000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x400e6000) libc.so.6 => /lib/libc.so.6 (0x401d9000) libdl.so.2 => /lib/libdl.so.2 (0x402fc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.4) libz.so.1 => /usr/lib/libz.so.1 (0x40052000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4006) libnsl.so.1 => /lib/libnsl.so.1 (0x4008d000) libm.so.6 => /lib/libm.so.6 (0x400a1000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x400c3000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400f1000) libc.so.6 => /lib/libc.so.6 (0x401b1000) libdl.so.2 => /lib/libdl.so.2 (0x402da000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) i'm also investigating more things... let me know if you need to me to test some specific items alessandro [2003-06-14 17:19:25] [EMAIL PROTECTED] That sounds odd. And as you're not running Apache2 as threaded (worker, or whatever that MPM was again), it shouldn't be thread-safety issue either. Could you check what libmysqlclient.so is linked with on those systems? Output of: # ldd libmysqlclient.so And FYI: the bundled mysql library is far from obsolete. (it works, doesn't it? :) [2003-06-14 15:40:21] alextxm at tin dot it finally, i've found the problem: compiling php 4.3.2 with --with-mysql=/path-to-mysql staically linked is the culprit. The problem can be avoided using --with-mysql and so using PHP's built-in (but obsolete) mysql interface or using: --with-mysql=shared,/path-to-mysql and then enabling php_mysql.so in php.ini Tests had been accomplished on three machines: a) gentoo linux 1.2: glibc 2.2.5, php 4.3.2, apache 2.0.45/46, mysql 4.0.12, openssl 0.9.6j b) gentoo linux 1.4rc4: glibc 2.3.1, php 4.3.2, apache 2.0.46, mysql 4.0.13, openssl 0.9.7b c) redhat 9: php 4.2.2, apache 2.0.40, openssl 0.9.7a, mysql-4.0.10 alessandro [2003-06-14 08:02:41] alextxm at tin dot it i'm doing some more tests... an interesting thing: on Redhat 9.0 it works fine (openssl 0.9.7a, php 4.2.2, apache 2.0.40 - both stock versions) . I'm trying to figure out where the problem is. I'll let you know, probaly there is something in my setup which causes php or apache to behave strangely. alessandro [2003-06-11 11:28:03] [EMAIL PROTECTED] Try reduce the configure options to the bare minimum first. Then if you don't get any segfaults, try every excluded option one by one to see which one is causing this. And for the backtrace you just need to keep pressing 'enter' until it gets there..the first couple of screens gdb is loading the symbols from every linked library, you can ignore it.. 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/23942 -- Edit this bug report at http://bugs.php.net/?id=23942&edit=1
#24195 [Opn->Csd]: ./configure script fails to detect libpng/libjpeg/etc.
ID: 24195 User updated by: live at generation dot net Reported By: live at generation dot net -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: RedHat 9 PHP Version: 4.3.2 New Comment: Argh! Forget it. I needed the damned -devel packages. Previous Comments: [2003-06-15 14:01:36] live at generation dot net Description: Hello. When trying to run ./configure with the options to enable GD with support for jpeg/png/etc, configure fails not being able to find the appropriate lib files. If I'm not mistaken, looking at the configure script, it's looking for libpng.so or libjpeg.so, while in RedHat 9, those files are called, for example, libpng.so.3, effectively making it so configure fails in finding the appropriate lib files... [15/06-14:47] [EMAIL PROTECTED] - /usr/local/src/php-4.3.2] # ls -l /usr/lib/libpng.so* lrwxrwxrwx1 root root 19 Jun 12 16:34 /usr/lib/libpng.so.3 -> libpng12.so.0.1.2.2* lrwxrwxrwx1 root root 19 Jun 12 16:34 /usr/lib/libpng.so.3.1.2.2 -> libpng12.so.0.1.2.2* Comparing with a RedHat 7.3 box, I see they used to also include a symlink pointing /usr/lib/libpng.so to /usr/lib/libpng.so.2. Guess they "forgot" or changed their way of doing. The quickfix way is most probably to add the symlinks myself, pointing libpng.so to libpng.so.3, but still... Is there something to be done for this in PHP's configure script? Or should this be considered a RedHat bug? Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-exif --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-ttf=/usr --with-freetype-dir=/usr --with-gettext checking for GD support... yes checking for the location of libjpeg... /usr checking for the location of libpng... /usr checking for the location of libXpm... no checking for FreeType 1.x support... /usr checking for FreeType 2... /usr checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. -- Edit this bug report at http://bugs.php.net/?id=24195&edit=1
#24195 [NEW]: ./configure script fails to detect libpng/libjpeg/etc.
From: live at generation dot net Operating system: RedHat 9 PHP version: 4.3.2 PHP Bug Type: *Configuration Issues Bug description: ./configure script fails to detect libpng/libjpeg/etc. Description: Hello. When trying to run ./configure with the options to enable GD with support for jpeg/png/etc, configure fails not being able to find the appropriate lib files. If I'm not mistaken, looking at the configure script, it's looking for libpng.so or libjpeg.so, while in RedHat 9, those files are called, for example, libpng.so.3, effectively making it so configure fails in finding the appropriate lib files... [15/06-14:47] [EMAIL PROTECTED] - /usr/local/src/php-4.3.2] # ls -l /usr/lib/libpng.so* lrwxrwxrwx1 root root 19 Jun 12 16:34 /usr/lib/libpng.so.3 -> libpng12.so.0.1.2.2* lrwxrwxrwx1 root root 19 Jun 12 16:34 /usr/lib/libpng.so.3.1.2.2 -> libpng12.so.0.1.2.2* Comparing with a RedHat 7.3 box, I see they used to also include a symlink pointing /usr/lib/libpng.so to /usr/lib/libpng.so.2. Guess they "forgot" or changed their way of doing. The quickfix way is most probably to add the symlinks myself, pointing libpng.so to libpng.so.3, but still... Is there something to be done for this in PHP's configure script? Or should this be considered a RedHat bug? Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-exif --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-ttf=/usr --with-freetype-dir=/usr --with-gettext checking for GD support... yes checking for the location of libjpeg... /usr checking for the location of libpng... /usr checking for the location of libXpm... no checking for FreeType 1.x support... /usr checking for FreeType 2... /usr checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. -- Edit bug report at http://bugs.php.net/?id=24195&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24195&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24195&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24195&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24195&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24195&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24195&r=support Expected behavior: http://bugs.php.net/fix.php?id=24195&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24195&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24195&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24195&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24195&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24195&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24195&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24195&r=gnused
#22576 [Com]: include() or require() file via HTTP wrapper
ID: 22576
Comment by: unknown at yabbse dot org
Reported By: mav at alkar dot net
Status: Closed
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.8-RC
PHP Version: 4.3.2-dev
New Comment:
This report is related to bug #24053
(http://bugs.php.net/bug.php?id=24053) which was marked bogus.
(although it is not.)
This has repercussions with functions like getimagesize, which clearly
need to be able to access remote files. Now they spit out a
warning
-[Unknown]
Previous Comments:
[2003-06-08 13:00:03] jrpozo at conclase dot net
We are seeing the same with PHP4.3.2, Linux RedHat 7.3, Apache 1.3.27
(PHP as a module).
http://www.example.com/test.txt";);
?>
yields this
Warning: main(): stream does not support seeking in
/home/example/public_html/test.php on line 3
and includes the file.
[2003-06-03 13:11:15] kelv at kelv dot net
Same problem here. Using stable PHP 4.3.2 on Slackware Linux 7.1,
kernel 2.4.20.
http://www.some.url.somewhere";); ?>
[2003-05-07 02:48:44] screwdriver at lxnt dot info
Does not work (i.e. spits warning: stream does not support seeking bla
bla bla) for me on FreeBSD 4.8-RELEASE
Tried:
PHP-4.3.2RC2
php4-STABLE-200305070730
Both spit out warnings like
Warning: main(): stream does not support seeking in
/home/www/htdocs/English/vacancy/job.php on line 2
line 2 being
include("http://blablalbla ...");
[2003-04-06 06:58:05] [EMAIL PROTECTED]
Works fine with 4.3.2-RC.
[2003-03-31 16:01:33] [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
Cannot replicate using latest stable snapshot.
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/22576
--
Edit this bug report at http://bugs.php.net/?id=22576&edit=1
#24053 [Com]: include issues spurious "stream" warning that clutters up the page ...
ID: 24053 Comment by: unknown at yabbse dot org Reported By: jphey at netdoor dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.4.20 PHP Version: 4.3.2 New Comment: This is not bogus, I've seen it causing a lot of problems. Here's a better example. Let's say someone tries to use an avatar on a forum, and the forum decides to check if that avatar is immensely huge. Before, getimagesize would work fine. Now, it generates a warning - effectively requiring a @ before the getimagesize, and making previous versions of the forum simply not work. (the error handler will catch the warning and die.) -[Unknown] Previous Comments: [2003-06-09 19:10:54] kriek at jonkriek dot com I had to form absolute paths out of my relative ones. [2003-06-06 15:43:01] admin at 1000rpm dot net I don't think this should have a bogus status. Have a search for the error message on google, tons of sites are getting this error. It's pretty urgent, I'm already getting customers complaining. [2003-06-06 15:37:51] admin at 1000rpm dot net What about non-local files? The error still comes up for those... [2003-06-06 01:48:56] [EMAIL PROTECTED] Don't include local files via http://..., use the correct path. [2003-06-06 01:41:34] jphey at netdoor dot com My web hosting provider says the problem is merely that "error logging was set to all" and by changing that, the warning messages disappear. So perhaps this is not a bug, but an intended behavior. Still, I don't know why such a warning would be issued when no call to fseek had been made. 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/24053 -- Edit this bug report at http://bugs.php.net/?id=24053&edit=1
#23942 [Fbk->Opn]: php 4.3.x causes apache2+mod_ssl to sigsev on client authentication
ID: 23942 User updated by: alextxm at tin dot it Reported By: alextxm at tin dot it -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: output of ldd libmysqlclient.so for each platform (cfr. my previous comment) : rh9) libz.so.1 => /usr/lib/libz.so.1 (0x40053000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40061000) libnsl.so.1 => /lib/libnsl.so.1 (0x4008e000) libm.so.6 => /lib/tls/libm.so.6 (0x400a4000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.2) libz.so.1 => /usr/lib/libz.so.1 (0x40047000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40055000) libnsl.so.1 => /lib/libnsl.so.1 (0x40082000) libm.so.6 => /lib/libm.so.6 (0x40097000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400b8000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x400e6000) libc.so.6 => /lib/libc.so.6 (0x401d9000) libdl.so.2 => /lib/libdl.so.2 (0x402fc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) gentoo 1.4) libz.so.1 => /usr/lib/libz.so.1 (0x40052000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4006) libnsl.so.1 => /lib/libnsl.so.1 (0x4008d000) libm.so.6 => /lib/libm.so.6 (0x400a1000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x400c3000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400f1000) libc.so.6 => /lib/libc.so.6 (0x401b1000) libdl.so.2 => /lib/libdl.so.2 (0x402da000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) i'm also investigating more things... let me know if you need to me to test some specific items alessandro Previous Comments: [2003-06-14 17:19:25] [EMAIL PROTECTED] That sounds odd. And as you're not running Apache2 as threaded (worker, or whatever that MPM was again), it shouldn't be thread-safety issue either. Could you check what libmysqlclient.so is linked with on those systems? Output of: # ldd libmysqlclient.so And FYI: the bundled mysql library is far from obsolete. (it works, doesn't it? :) [2003-06-14 15:40:21] alextxm at tin dot it finally, i've found the problem: compiling php 4.3.2 with --with-mysql=/path-to-mysql staically linked is the culprit. The problem can be avoided using --with-mysql and so using PHP's built-in (but obsolete) mysql interface or using: --with-mysql=shared,/path-to-mysql and then enabling php_mysql.so in php.ini Tests had been accomplished on three machines: a) gentoo linux 1.2: glibc 2.2.5, php 4.3.2, apache 2.0.45/46, mysql 4.0.12, openssl 0.9.6j b) gentoo linux 1.4rc4: glibc 2.3.1, php 4.3.2, apache 2.0.46, mysql 4.0.13, openssl 0.9.7b c) redhat 9: php 4.2.2, apache 2.0.40, openssl 0.9.7a, mysql-4.0.10 alessandro [2003-06-14 08:02:41] alextxm at tin dot it i'm doing some more tests... an interesting thing: on Redhat 9.0 it works fine (openssl 0.9.7a, php 4.2.2, apache 2.0.40 - both stock versions) . I'm trying to figure out where the problem is. I'll let you know, probaly there is something in my setup which causes php or apache to behave strangely. alessandro [2003-06-11 11:28:03] [EMAIL PROTECTED] Try reduce the configure options to the bare minimum first. Then if you don't get any segfaults, try every excluded option one by one to see which one is causing this. And for the backtrace you just need to keep pressing 'enter' until it gets there..the first couple of screens gdb is loading the symbols from every linked library, you can ignore it.. [2003-06-02 13:21:38] [EMAIL PROTECTED] No, don't change the MPM. And yes, you will get a backtrace always, it's not really PHP related thing. # gdb httpd (gdb) run -X -DSSL ..then access the page causing the crash.. (gdb) bt 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/23942 -- Edit this bug report at http://bugs.php.net/?id=23942&edit=1
#20551 [Opn->Csd]: Output compression causes segfaults (sapi/apache/mod_php.c)
ID: 20551
User updated by: sroussey at network54 dot com
Reported By: sroussey at network54 dot com
-Status: Open
+Status: Closed
Bug Type: Apache related
Operating System: RedHat 7.2
PHP Version: 4.3.0
New Comment:
Reopened wrong report.
Previous Comments:
[2003-06-15 12:19:31] sroussey at network54 dot com
FYI: This bug was in the final for 4.3.0. Also in 4.3.1. Now also in
4.3.2.
[2003-03-09 18:45:02] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-02-25 02:36: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
There was a fix for a possible crash in sapi_apache_header_handler() so
please try the latest snapshot.
[2003-02-24 12:29:22] plant at virtualsolution dot net
I have see the same problem on PHP4.3.1 Apache 1.3.27 Redhat 7.3:
Before the upgrade to PHP 4.3.1 with my 4.2.3,
ob_start ("ob_gzhandler") work OK.
Now there aren't way to compress the output, i try also
ini_set("output_handler", "ob_gzhandler");
or
ini_set ( "zlib.output_compression", 1);
with no result.
if i try to return to my old ob_start ("ob_gzhandler") ..
now php return me this Worning:
Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler'
cannot be used twice in Unknown on line 0
Any idea ??
[2003-02-14 00:57:47] sroussey at network54 dot com
Tried php4-STABLE-200302140230 and still it segfaults in the Apache
module. Either I patch PHP to check r for null, or I turn off
'ob_gzhandler' to stop the segfaults.
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/20551
--
Edit this bug report at http://bugs.php.net/?id=20551&edit=1
#20551 [NoF->Opn]: Output compression causes segfaults (sapi/apache/mod_php.c)
ID: 20551
User updated by: sroussey at network54 dot com
-Summary: Output compression causes segfaults (ob_gzhandler)
Reported By: sroussey at network54 dot com
-Status: No Feedback
+Status: Open
Bug Type: Apache related
Operating System: RedHat 7.2
PHP Version: 4.3.0
New Comment:
FYI: This bug was in the final for 4.3.0. Also in 4.3.1. Now also in
4.3.2.
Previous Comments:
[2003-03-09 18:45:02] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-02-25 02:36: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
There was a fix for a possible crash in sapi_apache_header_handler() so
please try the latest snapshot.
[2003-02-24 12:29:22] plant at virtualsolution dot net
I have see the same problem on PHP4.3.1 Apache 1.3.27 Redhat 7.3:
Before the upgrade to PHP 4.3.1 with my 4.2.3,
ob_start ("ob_gzhandler") work OK.
Now there aren't way to compress the output, i try also
ini_set("output_handler", "ob_gzhandler");
or
ini_set ( "zlib.output_compression", 1);
with no result.
if i try to return to my old ob_start ("ob_gzhandler") ..
now php return me this Worning:
Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler'
cannot be used twice in Unknown on line 0
Any idea ??
[2003-02-14 00:57:47] sroussey at network54 dot com
Tried php4-STABLE-200302140230 and still it segfaults in the Apache
module. Either I patch PHP to check r for null, or I turn off
'ob_gzhandler' to stop the segfaults.
[2003-02-13 19:55:22] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
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/20551
--
Edit this bug report at http://bugs.php.net/?id=20551&edit=1
#24174 [Fbk->Opn]: Seg. fault when calling imagecreatefromstring
ID: 24174
User updated by: legion at altlinux dot org
Reported By: legion at altlinux dot org
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: ALTLinux
PHP Version: 4.3.2
New Comment:
This was my configure command:
configure --with-gd=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr
--with-xpm-dir=/usr/X11R6 --with-t1lib --with-ttf=/usr
--with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr
What is the version libgd do you use ? Maybe this is problem on my
side...
Previous Comments:
[2003-06-13 08:36:58] [EMAIL PROTECTED]
And what was the configure line you used to configure PHP?
(note: This does NOT crash for me)
[2003-06-13 08:33:40] legion at altlinux dot org
Description:
Script segfaults when calling function imagecreatefromstring() with
built-in font.
PHP version: 4.3.2 (cvs snapshot 20030609)
GD version: 2.0.4
Reproduce code:
---
$tmpfilename = tempnam ("/tmp", "FOO");
$im = imagecreate(200, 100);
$black = imagecolorallocate ($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
imagefill($im, 0, 0, $black);
$string = '::: Oops! :::';
imagestring($im, 3, 0, 10, $string, $orange);
imagejpeg($im, $tmpfilename);
imagedestroy($im);
$fp = fopen($tmpfilename, 'r');
while (!feof ($fp)) { $content .= fgets($fp, 4096); }
fclose($fp);
$img = imagecreatefromstring($content);
// following function will be work
// $img = imagecreatefromjpeg($tmpfilename);
header ("Content-type: image/jpeg");
imagejpeg($img);
imagedestroy($img);
unlink($tmpfilename);
Expected result:
Must be generate jpeg image.
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=24174&edit=1
#24194 [NEW]: XPath only supporting absolute location paths?
From: markus dot pfefferle at web dot de
Operating system: Windows 2000
PHP version: 4.3.2
PHP Bug Type: DOM XML related
Bug description: XPath only supporting absolute location paths?
Description:
By the definition of XPath from http://www.w3.org/TR/xpath, the xpath
expression 'foo' (being an abbreviated syntax of 'child::foo') is a
Relative Location Path and would reference to all child nodes of the given
context node with a tagname of 'foo'.
The expression '/foo' ('/child::foo') is an Absolute Location Path which
references the child nodes named 'foo' of the context node's document root
node.
So the following small code:
$s = '';
$s .= '';
$s .= '';
$s .= '';
$doc = domxml_open_mem($s);
$ctx = xpath_new_context($doc);
$n = xpath_eval($ctx, 'foo');
should by strict XPath definition result in the refrencing of the
element just because foo is a child node of the document root node.
However, this always results in an empty $n->nodeset. This is the first
error.
The Absolute Location Path '/foo' however, used in the above xpath_eval(),
would deliver the expected node correctly in $n->nodeset[0].
Now if we use this node as a new context node:
$ctx = xpath_new_context($n->nodeset[0]);
$n = xpath_eval($ctx, 'bar');
Again, by W3C Definition, this should deliver the bar-Element, but instead
it will find nothing. Altering the expression to '/bar' however suddenly
finds the bar-Node. But this is incorret, since the expression '/bar'
would read "the child nodes of the context node's document's root node
named 'bar'" - which are non-existent, because the document's root node
only child node is 'foo'.
So instead the current implementation of XPath seems to treat the
preceding slash as mandatory and only referencing to the context node -
not the document root.
This is not in accordance to XPath!
Reproduce code:
---
$s = '';
$s .= '';
$s .= '';
$s .= 'abc';
$s .= '';
$s .= '';
$doc = domxml_open_mem($s);
$ctx = xpath_new_context($doc);
$a = xpath_eval($ctx, 'foo');
$b = xpath_eval($ctx, '/foo');
$ctx = xpath_new_context($b->nodeset[0]);
$c = xpath_eval($ctx, 'bar');
$d = xpath_eval($ctx, '/bar');
echo "a = $a b = $b c = $c d = $d";($ctx, '/foo');
Expected result:
a = Object
b = Object
c = Object
d =
Actual result:
--
a =
b = Object
c =
d = Object
--
Edit bug report at http://bugs.php.net/?id=24194&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24194&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24194&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24194&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24194&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24194&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24194&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24194&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24194&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24194&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24194&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24194&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24194&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24194&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24194&r=gnused
#24189 [Bgs->Csd]: big problem on stream function
ID: 24189 User updated by: anton at valuehost dot ru Reported By: anton at valuehost dot ru -Status: Bogus +Status: Closed Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: Do not want to help well and it is not necessary, in backtrace I and itself can understand. Previous Comments: [2003-06-15 10:58:08] [EMAIL PROTECTED] Not enough information -> bogus. (get rid of the zendoptimizer on some machine and provide a backtrace, otherwise -> not bug) [2003-06-15 10:55:20] anton at valuehost dot ru In it that all and the problem, on dev server to us was not possible to receive this mistake. The problem arises on production a level what from scripts of users of her causes to understand not really, we hold over 25000 sites. We at once find out any mistakes and we celebrate them quickly enough, and this of us has led up a blind alley :( But I can tell precisely, that all functions which work with socket cease to work, what that restriction on work mod_php is imposed. [2003-06-15 10:25:52] [EMAIL PROTECTED] You should have a dev machine to test this on. Just leave ZendOptimizer out. If you can't do this and can't provide decent backtrace, we can't fix anything. [2003-06-15 07:49:27] anton at valuehost dot ru It is impossible to switch off ZendOptimazer, on servers is from 500 up to 1500 sites, the some people use Zend if we shall switch off it at us there will be problems. Let's think as it is possible to make it without deenergizing, can be ktrace will approach? [2003-06-15 07:45:46] anton at valuehost dot ru if to make "apachectl restart" the problem will disappear for some time, but after a while it proves again while it was necessary to make restart on cron each 4 hours. And the problem does not disappear if to do "killall -HUP httpd". 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/24189 -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [Opn->Bgs]: big problem on stream function
ID: 24189 Updated by: [EMAIL PROTECTED] Reported By: anton at valuehost dot ru -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: Not enough information -> bogus. (get rid of the zendoptimizer on some machine and provide a backtrace, otherwise -> not bug) Previous Comments: [2003-06-15 10:55:20] anton at valuehost dot ru In it that all and the problem, on dev server to us was not possible to receive this mistake. The problem arises on production a level what from scripts of users of her causes to understand not really, we hold over 25000 sites. We at once find out any mistakes and we celebrate them quickly enough, and this of us has led up a blind alley :( But I can tell precisely, that all functions which work with socket cease to work, what that restriction on work mod_php is imposed. [2003-06-15 10:25:52] [EMAIL PROTECTED] You should have a dev machine to test this on. Just leave ZendOptimizer out. If you can't do this and can't provide decent backtrace, we can't fix anything. [2003-06-15 07:49:27] anton at valuehost dot ru It is impossible to switch off ZendOptimazer, on servers is from 500 up to 1500 sites, the some people use Zend if we shall switch off it at us there will be problems. Let's think as it is possible to make it without deenergizing, can be ktrace will approach? [2003-06-15 07:45:46] anton at valuehost dot ru if to make "apachectl restart" the problem will disappear for some time, but after a while it proves again while it was necessary to make restart on cron each 4 hours. And the problem does not disappear if to do "killall -HUP httpd". [2003-06-15 07:41:32] [EMAIL PROTECTED] Then turn it off! 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/24189 -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [Fbk->Opn]: big problem on stream function
ID: 24189 User updated by: anton at valuehost dot ru Reported By: anton at valuehost dot ru -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: In it that all and the problem, on dev server to us was not possible to receive this mistake. The problem arises on production a level what from scripts of users of her causes to understand not really, we hold over 25000 sites. We at once find out any mistakes and we celebrate them quickly enough, and this of us has led up a blind alley :( But I can tell precisely, that all functions which work with socket cease to work, what that restriction on work mod_php is imposed. Previous Comments: [2003-06-15 10:25:52] [EMAIL PROTECTED] You should have a dev machine to test this on. Just leave ZendOptimizer out. If you can't do this and can't provide decent backtrace, we can't fix anything. [2003-06-15 07:49:27] anton at valuehost dot ru It is impossible to switch off ZendOptimazer, on servers is from 500 up to 1500 sites, the some people use Zend if we shall switch off it at us there will be problems. Let's think as it is possible to make it without deenergizing, can be ktrace will approach? [2003-06-15 07:45:46] anton at valuehost dot ru if to make "apachectl restart" the problem will disappear for some time, but after a while it proves again while it was necessary to make restart on cron each 4 hours. And the problem does not disappear if to do "killall -HUP httpd". [2003-06-15 07:41:32] [EMAIL PROTECTED] Then turn it off! [2003-06-15 07:36:12] anton at valuehost dot ru I cannot use - enable-debug as ZendOptimazer does not work with this option: ( 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/24189 -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24010 [Opn->Csd]: Make failure
ID: 24010 Updated by: [EMAIL PROTECTED] Reported By: ronald_zeelenberg at hotmail dot com -Status: Open +Status: Closed -Bug Type: Zend Engine 2 problem +Bug Type: Reproducible crash Operating System: Red Hat 8 PHP Version: 5CVS-2003-06-04 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Looks fixed in latest CVS. Previous Comments: [2003-06-10 08:40:59] ronald_zeelenberg at hotmail dot com I know get a server hang with the latest build today 13:30 GMT Still with 434 no problem at all [2003-06-10 01:21:49] ronald_zeelenberg at hotmail dot com So i cant use it know? And when is PEAR ready for PHP5...? Keep in mind that it did work? Does anyone knows where i can find an older (3 weeks ago) PHP5 dev version... [2003-06-09 23:02:06] [EMAIL PROTECTED] It's PHP5. And PEAR is not ready for it.. :) [2003-06-09 16:37:52] ronald_zeelenberg at hotmail dot com I can now link again (been able since 4 days ago) saw this in my system log. But pages with PEAR are still crashing. I do not have these problems in version 43x. What is this thing? [2003-06-09 04:17:13] ronald_zeelenberg at hotmail dot com After setting LogLevel to debug in httpd.conf i found this extra info. [Mon Jun 09 06:12:27 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal operations [Mon Jun 09 10:55:58 2003] [notice] child pid 21213 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21168 exit signal Segmentation fault (11) [Mon Jun 09 10:55:58 2003] [notice] child pid 21167 exit signal Segmentation fault (11) [Mon Jun 09 11:11:25 2003] [notice] caught SIGTERM, shutting down [Mon Jun 09 11:11:25 2003] [notice] Apache/2.0.46 (Unix) DAV/2 PHP/5.0.0-dev configured -- resuming normal oper ations [Mon Jun 09 11:11:25 2003] [info] Server built: Jun 1 2003 13:15:30 [Mon Jun 09 11:11:25 2003] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Mon Jun 09 11:12:13 2003] [notice] child pid 21487 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21486 exit signal Segmentation fault (11) [Mon Jun 09 11:12:13 2003] [notice] child pid 21485 exit signal Segmentation fault (11) 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/24010 -- Edit this bug report at http://bugs.php.net/?id=24010&edit=1
#24191 [Opn]: can not change open_basedir from httpd.conf
ID: 24191 Updated by: [EMAIL PROTECTED] Reported By: info at crooce dot com Status: Open Bug Type: *Configuration Issues Operating System: OpenBSD 3.2 PHP Version: 4.3.1 New Comment: Try using php_admin_value Previous Comments: [2003-06-15 09:31:01] info at crooce dot com Description: php engine ignores php_value directice for open_basedir variable. This is not general issue, because for example include_dir works. Reproduce code: --- php_value open_basedir "some path" #; does not works php_value include_path "/htdocs/_com_/" #; works great -- Edit this bug report at http://bugs.php.net/?id=24191&edit=1
#24189 [Opn->Fbk]: big problem on stream function
ID: 24189 Updated by: [EMAIL PROTECTED] Reported By: anton at valuehost dot ru -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: You should have a dev machine to test this on. Just leave ZendOptimizer out. If you can't do this and can't provide decent backtrace, we can't fix anything. Previous Comments: [2003-06-15 07:49:27] anton at valuehost dot ru It is impossible to switch off ZendOptimazer, on servers is from 500 up to 1500 sites, the some people use Zend if we shall switch off it at us there will be problems. Let's think as it is possible to make it without deenergizing, can be ktrace will approach? [2003-06-15 07:45:46] anton at valuehost dot ru if to make "apachectl restart" the problem will disappear for some time, but after a while it proves again while it was necessary to make restart on cron each 4 hours. And the problem does not disappear if to do "killall -HUP httpd". [2003-06-15 07:41:32] [EMAIL PROTECTED] Then turn it off! [2003-06-15 07:36:12] anton at valuehost dot ru I cannot use - enable-debug as ZendOptimazer does not work with this option: ( [2003-06-15 07:32:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please try without the ZendOptimizer. 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/24189 -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24192 [Fbk->Bgs]: Unloading GD resource created with custom module causes crash
ID: 24192
Updated by: [EMAIL PROTECTED]
Reported By: iridium at beyondunreal dot com
-Status: Feedback
+Status: Bogus
-Bug Type: Reproducible crash
+Bug Type: GD related
Operating System: Windows XP sp1
PHP Version: 4.3.2
New Comment:
This bug system is not any support site, not for PHP script
or 3rd party extensions. Please ask such questions on more
appropriate forum, like [EMAIL PROTECTED]
Previous Comments:
[2003-06-15 10:18:46] [EMAIL PROTECTED]
It might be helpful to explain what exactly is unloaded here and how.
It may be that you are using some resource or function from unloaded
DLL, in which case you should destroy the resources before unloading
DLL.
[2003-06-15 10:12:53] iridium at beyondunreal dot com
Description:
Apache Version: 1.3.27
Operating System: Windows XP SP1
PHP Version: 4.3.2
PHP runs as a module for apache.
Basically, I've created my own module for reading bitmaps under
windows. The module creates a gd object, and reads the pixels from a
bitmap to the gd object.
This module worked fine before PHP4.3.2 (at least it worked in 4.3.2's
RCs), but it seems to have stopped working in PHP4.3.2's release.
What I did was I removed all of the code for creating the bitmap
itself, and was left with the image creating code.
What I found was, that when the image was either destroyed, or
unloaded, Apache Crashed ( presumably segmentation fault ).
As far as I can tell, I use exactly the same code as the gd module for
creating an image.
I have included the code I use for my readbitmap function. I have
tested le_gd and it is the correct value.
I'm afraid I cannot provide a backtrace because this is a windows
system, and I am unfamilier with generating a backtrace on a windows
system, and I could not see instruction on how to do it.
I tried compiling my module in debug mode, but when given the chance to
debug when it crashed - I was given the ASM for apache, seeing as it
was apache.exe that actually crashed, and apache was not compiled in
debug mode.
I have also tried gdImageDestroy'ing (im) as soon as it is created and
returning false. This does not cause any problems.
In the source below you can see im = readbitmaptogdimage(). This is the
function that reads the bitmap, but it turns out that if I just use
gdImageCreateTrueColor, when that is unloaded, apache crashes.
If you can think of anything that might cause it, or any way around the
problem, it would be appreciated.
An alternative would be to write one function to get the size from a
bitmap, create the image using php, and use another function to copy a
bitmap to the image. If I try that, I'll reply to this bug report, but
that should work, because the problem seems to be related to unloading
resources created with a module.
I've written other modules that just manipulate gd resources (no
resource creation), and they still work fine for PHP4.3.2.
Thanks in Advance for any help. Sorry I can't provide a backtrace..
Reproduce code:
---
PHP_FUNCTION(readbitmap)
{
gdImagePtr im;
zval **file;
if ( zend_get_parameters_ex( 1, &file ) == FAILURE )
ZEND_WRONG_PARAM_COUNT();
convert_to_string_ex(file);
//im = readbitmaptogdimage( Z_STRVAL_PP(file) );
im = gdImageCreateTrueColor( 100, 100 );
if ( !im ) RETURN_FALSE;
ZEND_REGISTER_RESOURCE( return_value, im, le_gd );
}
Expected result:
A GD object to be created and registered as a resource
Actual result:
--
A GD object is created, but when an attempt is made to unload it (or
when PHP finishes executing and does its resource cleanup), it
crashes.
I cannot provide a backtrace at this time.
--
Edit this bug report at http://bugs.php.net/?id=24192&edit=1
#24177 [Fbk->Opn]: header() call doesn't replace 404 status code
ID: 24177
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 4.3.2
New Comment:
Yes. Odd at first.
After some experimentation I figured it out.
do-download.inc calls flush() on line 31. This causes the 'original'
status to be sent instead of the one specified by the call to
header().
If 4096 bytes or more are written before the flush the correct status
is sent.
I guess the codepath that handles an expicit flush manages to loose the
new status code somewhere.
I replaced echo " " with echo str_repeat(' ', 4096) and now our mirror
works fine and dandy again.
Previous Comments:
[2003-06-13 15:19:17] [EMAIL PROTECTED]
# lynx -dump -head http://se.php.net/imap
HTTP/1.1 200 OK
Date: Fri, 13 Jun 2003 19:17:17 GMT
Server: Apache/2.0.46 (Unix) mod_ssl/2.0.46 OpenSSL/0.9.6b PHP/4.3.2
X-Powered-By: PHP/4.3.2
Content-language: en
Set-Cookie: COUNTRY=FIN%2C213.243.181.8; expires=Fri, 20-Jun-2003
19:17:17 GMT;
path=/; domain=.php.net
Status: 200 OK
Last-Modified: Fri, 13 Jun 2003 19:09:38 GMT
Vary: Cookie
Connection: close
Content-Type: text/html;charset=ISO-8859-1
That works just fine?
[2003-06-13 13:42:09] [EMAIL PROTECTED]
Description:
Using Apache 2.0.46 and PHP 4.3.2 compiled with --with-apxs2
When a PHP page is used as an ErrorDocument page, calling any variation
of header() to replace the status code doesn't work. The client always
receive 404.
For example, try downloading from se.php.net:
http://se.php.net/get/php-4.3.2.tar.gz/from/this/mirror
You'll se that a Location header has been added (by the call to
header() in /include/do-download.inc) but the status returned is still
404, not 302 as expected.
--
Edit this bug report at http://bugs.php.net/?id=24177&edit=1
#23750 [Opn->Csd]: Win32 build failed (snaps.php.net)
ID: 23750 Updated by: [EMAIL PROTECTED] Reported By: rabus at users dot sourceforge dot net -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Win32 PHP Version: 5CVS-2003-06-15 (dev) New Comment: Yes, it's fixed now, at least it's not saying build failed. :) Previous Comments: [2003-06-15 03:48:16] rabus at users dot sourceforge dot net Any news on this? [2003-05-22 17:13:58] [EMAIL PROTECTED] This is because the expat library is not bundled in PHP sources anymore. Edin, or someone should look into using the libxml2 instead for this. [2003-05-22 05:34:29] rabus at users dot sourceforge dot net Since May 18th, there have no new Win32 CVS builds been released from the HEAD branch on snaps.php.net due to a compile failure (again). It would be great if you could fix that soon. Regards, Alexander M. Turek -- Edit this bug report at http://bugs.php.net/?id=23750&edit=1
#24192 [Opn->Fbk]: Unloading GD resource created with custom module causes crash
ID: 24192
Updated by: [EMAIL PROTECTED]
Reported By: iridium at beyondunreal dot com
-Status: Open
+Status: Feedback
-Bug Type: Zend Engine 2 problem
+Bug Type: Reproducible crash
Operating System: Windows XP sp1
PHP Version: 4.3.2
New Comment:
It might be helpful to explain what exactly is unloaded here and how.
It may be that you are using some resource or function from unloaded
DLL, in which case you should destroy the resources before unloading
DLL.
Previous Comments:
[2003-06-15 10:12:53] iridium at beyondunreal dot com
Description:
Apache Version: 1.3.27
Operating System: Windows XP SP1
PHP Version: 4.3.2
PHP runs as a module for apache.
Basically, I've created my own module for reading bitmaps under
windows. The module creates a gd object, and reads the pixels from a
bitmap to the gd object.
This module worked fine before PHP4.3.2 (at least it worked in 4.3.2's
RCs), but it seems to have stopped working in PHP4.3.2's release.
What I did was I removed all of the code for creating the bitmap
itself, and was left with the image creating code.
What I found was, that when the image was either destroyed, or
unloaded, Apache Crashed ( presumably segmentation fault ).
As far as I can tell, I use exactly the same code as the gd module for
creating an image.
I have included the code I use for my readbitmap function. I have
tested le_gd and it is the correct value.
I'm afraid I cannot provide a backtrace because this is a windows
system, and I am unfamilier with generating a backtrace on a windows
system, and I could not see instruction on how to do it.
I tried compiling my module in debug mode, but when given the chance to
debug when it crashed - I was given the ASM for apache, seeing as it
was apache.exe that actually crashed, and apache was not compiled in
debug mode.
I have also tried gdImageDestroy'ing (im) as soon as it is created and
returning false. This does not cause any problems.
In the source below you can see im = readbitmaptogdimage(). This is the
function that reads the bitmap, but it turns out that if I just use
gdImageCreateTrueColor, when that is unloaded, apache crashes.
If you can think of anything that might cause it, or any way around the
problem, it would be appreciated.
An alternative would be to write one function to get the size from a
bitmap, create the image using php, and use another function to copy a
bitmap to the image. If I try that, I'll reply to this bug report, but
that should work, because the problem seems to be related to unloading
resources created with a module.
I've written other modules that just manipulate gd resources (no
resource creation), and they still work fine for PHP4.3.2.
Thanks in Advance for any help. Sorry I can't provide a backtrace..
Reproduce code:
---
PHP_FUNCTION(readbitmap)
{
gdImagePtr im;
zval **file;
if ( zend_get_parameters_ex( 1, &file ) == FAILURE )
ZEND_WRONG_PARAM_COUNT();
convert_to_string_ex(file);
//im = readbitmaptogdimage( Z_STRVAL_PP(file) );
im = gdImageCreateTrueColor( 100, 100 );
if ( !im ) RETURN_FALSE;
ZEND_REGISTER_RESOURCE( return_value, im, le_gd );
}
Expected result:
A GD object to be created and registered as a resource
Actual result:
--
A GD object is created, but when an attempt is made to unload it (or
when PHP finishes executing and does its resource cleanup), it
crashes.
I cannot provide a backtrace at this time.
--
Edit this bug report at http://bugs.php.net/?id=24192&edit=1
#24089 [Dup->Bgs]: Problem creating objects with names from class' fields
ID: 24089 Updated by: [EMAIL PROTECTED] Reported By: bartosz at webcity dot pl -Status: Duplicate +Status: Bogus Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 5CVS-2003-06-09 (dev) New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. . Previous Comments: [2003-06-15 07:23:17] [EMAIL PROTECTED] This is the same issue as bug #21669 [2003-06-09 22:56:00] [EMAIL PROTECTED] Latest CVS gives: Parse error: parse error in /home/jani/t.php on line 25 (for the script provided in the first comment in this report) [2003-06-09 13:39:34] bartosz at webcity dot pl Only notice about parse error, nothing else: Parse error: parse error in /home/bartosz/www/foo.php on line 25 [2003-06-09 12:47:59] neon at neon-line dot net Oh... I propably wasn't thinking while writing my previous comment. For me it works with php5-200306091730 and PHP4. Are you sure that you don't have some kind of typing error etc. in you code... [2003-06-09 12:15:14] bartosz at webcity dot pl So, why it works with php4, but with php5 doesn't? 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/24089 -- Edit this bug report at http://bugs.php.net/?id=24089&edit=1
#24192 [NEW]: Unloading GD resource created with custom module causes crash
From: iridium at beyondunreal dot com
Operating system: Windows XP sp1
PHP version: 4.3.2
PHP Bug Type: Zend Engine 2 problem
Bug description: Unloading GD resource created with custom module causes crash
Description:
Apache Version: 1.3.27
Operating System: Windows XP SP1
PHP Version: 4.3.2
PHP runs as a module for apache.
Basically, I've created my own module for reading bitmaps under windows.
The module creates a gd object, and reads the pixels from a bitmap to the
gd object.
This module worked fine before PHP4.3.2 (at least it worked in 4.3.2's
RCs), but it seems to have stopped working in PHP4.3.2's release.
What I did was I removed all of the code for creating the bitmap itself,
and was left with the image creating code.
What I found was, that when the image was either destroyed, or unloaded,
Apache Crashed ( presumably segmentation fault ).
As far as I can tell, I use exactly the same code as the gd module for
creating an image.
I have included the code I use for my readbitmap function. I have tested
le_gd and it is the correct value.
I'm afraid I cannot provide a backtrace because this is a windows system,
and I am unfamilier with generating a backtrace on a windows system, and I
could not see instruction on how to do it.
I tried compiling my module in debug mode, but when given the chance to
debug when it crashed - I was given the ASM for apache, seeing as it was
apache.exe that actually crashed, and apache was not compiled in debug
mode.
I have also tried gdImageDestroy'ing (im) as soon as it is created and
returning false. This does not cause any problems.
In the source below you can see im = readbitmaptogdimage(). This is the
function that reads the bitmap, but it turns out that if I just use
gdImageCreateTrueColor, when that is unloaded, apache crashes.
If you can think of anything that might cause it, or any way around the
problem, it would be appreciated.
An alternative would be to write one function to get the size from a
bitmap, create the image using php, and use another function to copy a
bitmap to the image. If I try that, I'll reply to this bug report, but
that should work, because the problem seems to be related to unloading
resources created with a module.
I've written other modules that just manipulate gd resources (no resource
creation), and they still work fine for PHP4.3.2.
Thanks in Advance for any help. Sorry I can't provide a backtrace..
Reproduce code:
---
PHP_FUNCTION(readbitmap)
{
gdImagePtr im;
zval **file;
if ( zend_get_parameters_ex( 1, &file ) == FAILURE )
ZEND_WRONG_PARAM_COUNT();
convert_to_string_ex(file);
//im = readbitmaptogdimage( Z_STRVAL_PP(file) );
im = gdImageCreateTrueColor( 100, 100 );
if ( !im ) RETURN_FALSE;
ZEND_REGISTER_RESOURCE( return_value, im, le_gd );
}
Expected result:
A GD object to be created and registered as a resource
Actual result:
--
A GD object is created, but when an attempt is made to unload it (or when
PHP finishes executing and does its resource cleanup), it crashes.
I cannot provide a backtrace at this time.
--
Edit bug report at http://bugs.php.net/?id=24192&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24192&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24192&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24192&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24192&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24192&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24192&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24192&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24192&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24192&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24192&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24192&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24192&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24192&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24192&r=gnused
#23279 [Opn->Csd]: output buffering failure with set_exception_handler
ID: 23279 Updated by: [EMAIL PROTECTED] Reported By: george at omniti dot com -Status: Open +Status: Closed Bug Type: Zend Engine 2 problem Operating System: linux PHP Version: 5CVS-2003-04-19 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-04-19 11:11:33] george at omniti dot com generates empty output with no warnings. -- Edit this bug report at http://bugs.php.net/?id=23279&edit=1
#18872 [Ver->Csd]: Improper handling of class constants used as default function argument values
ID: 18872 Updated by: [EMAIL PROTECTED] Reported By: optikSmoke at subdimension dot com -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Mandrake 8.2 (linux 2.4.18) PHP Version: 5.0.0-dev New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-08-12 23:27:03] optikSmoke at subdimension dot com I am using CVS from August 12, compiled with Zend2, as a module in Apache 1.3.23. My problem is this: When I use a class constant as the default value to an argument in a function, the first time I call the function (omitting the argument), PHP correctly uses the value of the constant for the value of the omitted argument. The second time I call the same function (again omitting the argument), PHP uses a slightly-garbled form of the name of the class constant, instead of the value of the constant. For example: The expected output of this is (obviously): 3 3 The output I get is: 3 foobar :BIFF (The space before ":BIFF" should be a non-printing character, rendered as a box on my system, but I'm not sure if it will come through properly :) This error does not occur when using regular "define()'d" constants. For example, if I replaced FooBar::BIFF with a constant BIFF, I get the expected output (no garbled constant names, "3" is displayed by each call to foo()). -- Edit this bug report at http://bugs.php.net/?id=18872&edit=1
#24190 [Opn->Bgs]: Fatal error: Call to undefined function: mysql_pconnect()
ID: 24190 Updated by: [EMAIL PROTECTED] Reported By: oishyasan at netscape dot net -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: RedHat Linux 7.3 PHP Version: 4.3.2 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 compiled mysql as a shared extension, but you didn't load it. Previous Comments: [2003-06-15 08:47:18] oishyasan at netscape dot net Description: Hi, I had problems with base dirs issues in the previous php version, so I upgraded. So far, that seems to have been sorted out nicely. But, I can't use my apps as a new problem exists with all my apps - Fatal error: Call to undefined function: mysql_pconnect(). I have checked EVERYWHERE about this - I have tried the latest mysql, but no change. I thought it may be the config in my php - but as you can see from the phpinfo address attached, it "appears" to include mysql - however I did see in the ./configure stage that it didn't pick up on the socket location. http://www.salubriousvision.com/info.php You can see the error at this page - which worked fine until this version was installed. http://www.dreamcounselling.com/Default.php I have installed the php-mysql rpms that as provided by RedHat Reproduce code: --- Fatal error: Call to undefined function: mysql_pconnect() Expected result: I expected the code to connect to the mysql DB as per normal. Actual result: -- Can not access mysql with any code -connect or pconnect -- Edit this bug report at http://bugs.php.net/?id=24190&edit=1
#24191 [NEW]: can not change open_basedir from httpd.conf
From: info at crooce dot com Operating system: OpenBSD 3.2 PHP version: 4.3.1 PHP Bug Type: *Configuration Issues Bug description: can not change open_basedir from httpd.conf Description: php engine ignores php_value directice for open_basedir variable. This is not general issue, because for example include_dir works. Reproduce code: --- php_value open_basedir "some path" #; does not works php_value include_path "/htdocs/_com_/" #; works great -- Edit bug report at http://bugs.php.net/?id=24191&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24191&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24191&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24191&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24191&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24191&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24191&r=support Expected behavior: http://bugs.php.net/fix.php?id=24191&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24191&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24191&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24191&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24191&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24191&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24191&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24191&r=gnused
#24187 [Fbk->Opn]: Smarty causes "page could not load" error
ID: 24187
User updated by: terjeto at stud dot ntnu dot no
Reported By: terjeto at stud dot ntnu dot no
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Red Hat 9.0
PHP Version: 5CVS-2003-06-14 (dev)
New Comment:
ok. had to run some tests and go through the smarty
code, took some time.
but doesnt seem to be the smarty coding itself thats
the problem. and i cant reproduce a code that 'brings
forth' the problem eather.
im currently writing my code on a mac using BBedit,
storing it on my linux server (using unix line breaks).
my old code ( written on the mac, but with php 4.2.3 )
worked fine, but on php5 i get these 'random' parse
errors. when i was testing the smarty code i added some
print('test'); exit; lines to see where the problem
could be. i was then just abt line 1000. and regulary
after editing a line i for some reason got a parse
error on line 2400+. all i had to do was put a empty
line there. and thats not the first time something like
that happens, i also have had delete a line just to
write it again, exactly the same, because it caused a
parse error.
sorry that i cant reproduce any code with this
problem.. i comes and goes as it wants on my server
too..
when i was debuging the smarty code i say added a print
statement at line 1090 and got "page could not load"
error. after some trials i maybe found that line 1070
worked while 1071 didnt work (nb! without changing the
existing line breaks). if i then added a empty line at
1071 and tried again it worked, i no longer got a "page
could not load" error on that line, there where many of
those. seemed like it didnt like the existing line
break...
( this might be messy.. sorry )
Previous Comments:
[2003-06-15 07:21:59] [EMAIL PROTECTED]
Please try to produce the reproducing code for the problem that shown
it is an engine problem and not the Smarty code problem.
[2003-06-15 06:47:45] terjeto at stud dot ntnu dot no
Cant seem to manage to reproduce the error.. The
problem wasnt what I first thought thou. After several
trials I get the same error with :: and ->. My old code
still produces the same error. Seems to have something
to do with Smarty. When I load Smarty and run the
display( 'index.tpl' ) it causes the "page could not
load" error. I sometimes get a lot of warnings, like :
fetch() could not find index.tpl etc. And it doesnt
produce any files in the template_c folder, so
something is wrong...
[2003-06-15 03:08:41] [EMAIL PROTECTED]
But it's still a bug. Can you provide a full script (ie, we can copy
and paste it and run it, that script includes then)?
Derick
[2003-06-14 18:06:19] terjeto at stud dot ntnu dot no
worked with return $this::array; :)
[2003-06-14 18:03:32] terjeto at stud dot ntnu dot no
Description:
A function get_array() inside the class Foo tries to
return an array stored inside the class. This worked
fine in PHP4, but in the latest PHP5 the webpage wont
load.
Reproduce code:
---
class Foo {
var $array = array();
function get_array() {
return $this->array;
}
}
Expected result:
expected to see the page or at least an error message
of what the problem was.
Actual result:
--
the page didnt load at all. i got "page could not load"
every time. if i commented the "return ..." and
replaced it with "return true;" or anything else it
worked, but when i tried to return an array the webpage
wouldnt load at all
--
Edit this bug report at http://bugs.php.net/?id=24187&edit=1
#23384 [Opn->Csd]: static array accessed from subclass
ID: 23384
Updated by: [EMAIL PROTECTED]
Reported By: thixit at yahoo dot com
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows 98
PHP Version: 5CVS-2003-04-28 (dev)
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
The first form will not work, since it is ambigious, so I don't think
it is possible to make it work right. The second form should be working
now.
Previous Comments:
[2003-04-28 11:44:23] thixit at yahoo dot com
The following codes didn't work as expected. There're two problems that
I don't understand.
First, PHP doesn't know about defined constant if test() is called from
subclass.
'ten');
print_r($arr);
}
}
class Bar extends Foo {
}
Foo::test();// output: Array([10] => ten)
Bar::test();// output: Array([TEN] => ten)
?>
Second, as commented, it doesn't know about const TEN too.
'ten');
// --- This line cause $arr to be an empty array
// without any error
static $arr = array(Foo::TEN => 'ten');
print_r($arr);
}
}
Foo::test();// output: Array()
?>
--
Edit this bug report at http://bugs.php.net/?id=23384&edit=1
#23975 [Opn]: dba_open locking error with ndbm/db2/db3
ID: 23975 Updated by: [EMAIL PROTECTED] Reported By: rhalstenbach at t-online dot de Status: Open Bug Type: DBM/DBA related -Operating System: ANY +Operating System: Windows PHP Version: 4.3.2 Assigned To: helly New Comment: Seems to be a windows only problem. The bug is fixed for *nix. Previous Comments: [2003-06-15 08:43:41] rhalstenbach at t-online dot de Re-Opened. It still does not work, tested with snapshot "Built On: Jun 15, 2003 12:30 GMT". Sent an email to marcus dot boerger at post dot rwth-aachen dot de (he asked me to check out the snapshot and to run a test). [2003-06-12 15:01:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Maybe this applies to dbm, too. However the problem is solved in a generic way. [2003-06-10 05:19:49] adam at saki dot com dot au This is actually because the locking will prematurely create an empty file, causing the VCWD_STAT command in dba_db3.c to return 0, resulting in the wrong parameters to db_open. This can be verified by putting a stat command after the lock detection code and before the call to open (line 590 in ext/dba/dba.c). [2003-06-05 01:28:33] [EMAIL PROTECTED] Marcus, take a look? [2003-06-03 03:43:56] rhalstenbach at t-online dot de The new locking feature (introduced with 4.3.0) does not work correctly in default mode "d". Very annoying because it is the default mode ... Example: Same problem for mode "w". It works correctly for locking mode "l" and for suppressing locking via "-". Obviously the dba_open() function tries to create a lock file with exactly the same name as the database file - what fails of course. Tested on WindowsXP with db3, but i think it will fail for every db-driver (except gdbm) on every OS. -- Edit this bug report at http://bugs.php.net/?id=23975&edit=1
#24190 [NEW]: Fatal error: Call to undefined function: mysql_pconnect()
From: oishyasan at netscape dot net Operating system: RedHat Linux 7.3 PHP version: 4.3.2 PHP Bug Type: MySQL related Bug description: Fatal error: Call to undefined function: mysql_pconnect() Description: Hi, I had problems with base dirs issues in the previous php version, so I upgraded. So far, that seems to have been sorted out nicely. But, I can't use my apps as a new problem exists with all my apps - Fatal error: Call to undefined function: mysql_pconnect(). I have checked EVERYWHERE about this - I have tried the latest mysql, but no change. I thought it may be the config in my php - but as you can see from the phpinfo address attached, it "appears" to include mysql - however I did see in the ./configure stage that it didn't pick up on the socket location. http://www.salubriousvision.com/info.php You can see the error at this page - which worked fine until this version was installed. http://www.dreamcounselling.com/Default.php I have installed the php-mysql rpms that as provided by RedHat Reproduce code: --- Fatal error: Call to undefined function: mysql_pconnect() Expected result: I expected the code to connect to the mysql DB as per normal. Actual result: -- Can not access mysql with any code -connect or pconnect -- Edit bug report at http://bugs.php.net/?id=24190&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24190&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24190&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24190&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24190&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24190&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24190&r=support Expected behavior: http://bugs.php.net/fix.php?id=24190&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24190&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24190&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24190&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24190&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24190&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24190&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24190&r=gnused
#23975 [Csd->Opn]: dba_open locking error with ndbm/db2/db3
ID: 23975 User updated by: rhalstenbach at t-online dot de Reported By: rhalstenbach at t-online dot de -Status: Closed +Status: Open Bug Type: DBM/DBA related Operating System: ANY PHP Version: 4.3.2 Assigned To: helly New Comment: Re-Opened. It still does not work, tested with snapshot "Built On: Jun 15, 2003 12:30 GMT". Sent an email to marcus dot boerger at post dot rwth-aachen dot de (he asked me to check out the snapshot and to run a test). Previous Comments: [2003-06-12 15:01:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Maybe this applies to dbm, too. However the problem is solved in a generic way. [2003-06-10 05:19:49] adam at saki dot com dot au This is actually because the locking will prematurely create an empty file, causing the VCWD_STAT command in dba_db3.c to return 0, resulting in the wrong parameters to db_open. This can be verified by putting a stat command after the lock detection code and before the call to open (line 590 in ext/dba/dba.c). [2003-06-05 01:28:33] [EMAIL PROTECTED] Marcus, take a look? [2003-06-03 03:43:56] rhalstenbach at t-online dot de The new locking feature (introduced with 4.3.0) does not work correctly in default mode "d". Very annoying because it is the default mode ... Example: Same problem for mode "w". It works correctly for locking mode "l" and for suppressing locking via "-". Obviously the dba_open() function tries to create a lock file with exactly the same name as the database file - what fails of course. Tested on WindowsXP with db3, but i think it will fail for every db-driver (except gdbm) on every OS. -- Edit this bug report at http://bugs.php.net/?id=23975&edit=1
#24189 [Opn]: big problem on stream function
ID: 24189 User updated by: anton at valuehost dot ru Reported By: anton at valuehost dot ru Status: Open Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: It is impossible to switch off ZendOptimazer, on servers is from 500 up to 1500 sites, the some people use Zend if we shall switch off it at us there will be problems. Let's think as it is possible to make it without deenergizing, can be ktrace will approach? Previous Comments: [2003-06-15 07:45:46] anton at valuehost dot ru if to make "apachectl restart" the problem will disappear for some time, but after a while it proves again while it was necessary to make restart on cron each 4 hours. And the problem does not disappear if to do "killall -HUP httpd". [2003-06-15 07:41:32] [EMAIL PROTECTED] Then turn it off! [2003-06-15 07:36:12] anton at valuehost dot ru I cannot use - enable-debug as ZendOptimazer does not work with this option: ( [2003-06-15 07:32:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please try without the ZendOptimizer. [2003-06-15 07:31:00] anton at valuehost dot ru Description: phpinfo: http://v6test.valuehost.ru/phpinfo.php The problem has the following character, after long work php as mod_php in apache, various variations of sockets, fsockopen, include, fopen and etc cease to work. As did not work and curl, but it managed to be solved rebuild libcurl with FD_SETSIZE=16384 (sys/types.h). Such sensation that descriptors come to an end. At occurrence of this problem fsockopen starts to return a mistake " Operation now in progress " Function include in general causes Segmentation fault (11) Unfortunately there is no opportunity to include an option debug as ZendOptimazer does not work in debug a mode. -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [Fbk->Opn]: big problem on stream function
ID: 24189 User updated by: anton at valuehost dot ru Reported By: anton at valuehost dot ru -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: if to make "apachectl restart" the problem will disappear for some time, but after a while it proves again while it was necessary to make restart on cron each 4 hours. And the problem does not disappear if to do "killall -HUP httpd". Previous Comments: [2003-06-15 07:41:32] [EMAIL PROTECTED] Then turn it off! [2003-06-15 07:36:12] anton at valuehost dot ru I cannot use - enable-debug as ZendOptimazer does not work with this option: ( [2003-06-15 07:32:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please try without the ZendOptimizer. [2003-06-15 07:31:00] anton at valuehost dot ru Description: phpinfo: http://v6test.valuehost.ru/phpinfo.php The problem has the following character, after long work php as mod_php in apache, various variations of sockets, fsockopen, include, fopen and etc cease to work. As did not work and curl, but it managed to be solved rebuild libcurl with FD_SETSIZE=16384 (sys/types.h). Such sensation that descriptors come to an end. At occurrence of this problem fsockopen starts to return a mistake " Operation now in progress " Function include in general causes Segmentation fault (11) Unfortunately there is no opportunity to include an option debug as ZendOptimazer does not work in debug a mode. -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [Opn->Fbk]: big problem on stream function
ID: 24189 Updated by: [EMAIL PROTECTED] Reported By: anton at valuehost dot ru -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: Then turn it off! Previous Comments: [2003-06-15 07:36:12] anton at valuehost dot ru I cannot use - enable-debug as ZendOptimazer does not work with this option: ( [2003-06-15 07:32:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please try without the ZendOptimizer. [2003-06-15 07:31:00] anton at valuehost dot ru Description: phpinfo: http://v6test.valuehost.ru/phpinfo.php The problem has the following character, after long work php as mod_php in apache, various variations of sockets, fsockopen, include, fopen and etc cease to work. As did not work and curl, but it managed to be solved rebuild libcurl with FD_SETSIZE=16384 (sys/types.h). Such sensation that descriptors come to an end. At occurrence of this problem fsockopen starts to return a mistake " Operation now in progress " Function include in general causes Segmentation fault (11) Unfortunately there is no opportunity to include an option debug as ZendOptimazer does not work in debug a mode. -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [Fbk->Opn]: big problem on stream function
ID: 24189 User updated by: anton at valuehost dot ru Reported By: anton at valuehost dot ru -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: I cannot use - enable-debug as ZendOptimazer does not work with this option: ( Previous Comments: [2003-06-15 07:32:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please try without the ZendOptimizer. [2003-06-15 07:31:00] anton at valuehost dot ru Description: phpinfo: http://v6test.valuehost.ru/phpinfo.php The problem has the following character, after long work php as mod_php in apache, various variations of sockets, fsockopen, include, fopen and etc cease to work. As did not work and curl, but it managed to be solved rebuild libcurl with FD_SETSIZE=16384 (sys/types.h). Such sensation that descriptors come to an end. At occurrence of this problem fsockopen starts to return a mistake " Operation now in progress " Function include in general causes Segmentation fault (11) Unfortunately there is no opportunity to include an option debug as ZendOptimazer does not work in debug a mode. -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [Opn->Fbk]: big problem on stream function
ID: 24189 Updated by: [EMAIL PROTECTED] Reported By: anton at valuehost dot ru -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please try without the ZendOptimizer. Previous Comments: [2003-06-15 07:31:00] anton at valuehost dot ru Description: phpinfo: http://v6test.valuehost.ru/phpinfo.php The problem has the following character, after long work php as mod_php in apache, various variations of sockets, fsockopen, include, fopen and etc cease to work. As did not work and curl, but it managed to be solved rebuild libcurl with FD_SETSIZE=16384 (sys/types.h). Such sensation that descriptors come to an end. At occurrence of this problem fsockopen starts to return a mistake " Operation now in progress " Function include in general causes Segmentation fault (11) Unfortunately there is no opportunity to include an option debug as ZendOptimazer does not work in debug a mode. -- Edit this bug report at http://bugs.php.net/?id=24189&edit=1
#24189 [NEW]: big problem on stream function
From: anton at valuehost dot ru Operating system: FreeBSD 4.8 PHP version: 4.3.2 PHP Bug Type: Sockets related Bug description: big problem on stream function Description: phpinfo: http://v6test.valuehost.ru/phpinfo.php The problem has the following character, after long work php as mod_php in apache, various variations of sockets, fsockopen, include, fopen and etc cease to work. As did not work and curl, but it managed to be solved rebuild libcurl with FD_SETSIZE=16384 (sys/types.h). Such sensation that descriptors come to an end. At occurrence of this problem fsockopen starts to return a mistake " Operation now in progress " Function include in general causes Segmentation fault (11) Unfortunately there is no opportunity to include an option debug as ZendOptimazer does not work in debug a mode. -- Edit bug report at http://bugs.php.net/?id=24189&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24189&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24189&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24189&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24189&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24189&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24189&r=support Expected behavior: http://bugs.php.net/fix.php?id=24189&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24189&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24189&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24189&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24189&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24189&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24189&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24189&r=gnused
#24089 [Ver->Dup]: Problem creating objects with names from class' fields
ID: 24089 Updated by: [EMAIL PROTECTED] Reported By: bartosz at webcity dot pl -Status: Verified +Status: Duplicate Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 5CVS-2003-06-09 (dev) New Comment: This is the same issue as bug #21669 Previous Comments: [2003-06-09 22:56:00] [EMAIL PROTECTED] Latest CVS gives: Parse error: parse error in /home/jani/t.php on line 25 (for the script provided in the first comment in this report) [2003-06-09 13:39:34] bartosz at webcity dot pl Only notice about parse error, nothing else: Parse error: parse error in /home/bartosz/www/foo.php on line 25 [2003-06-09 12:47:59] neon at neon-line dot net Oh... I propably wasn't thinking while writing my previous comment. For me it works with php5-200306091730 and PHP4. Are you sure that you don't have some kind of typing error etc. in you code... [2003-06-09 12:15:14] bartosz at webcity dot pl So, why it works with php4, but with php5 doesn't? [2003-06-09 05:12:33] neon at neon-line dot net It's not a bug. 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/24089 -- Edit this bug report at http://bugs.php.net/?id=24089&edit=1
#24187 [Opn->Fbk]: Smarty causes "page could not load" error
ID: 24187
Updated by: [EMAIL PROTECTED]
Reported By: terjeto at stud dot ntnu dot no
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Red Hat 9.0
PHP Version: 5CVS-2003-06-14 (dev)
New Comment:
Please try to produce the reproducing code for the problem that shown
it is an engine problem and not the Smarty code problem.
Previous Comments:
[2003-06-15 06:47:45] terjeto at stud dot ntnu dot no
Cant seem to manage to reproduce the error.. The
problem wasnt what I first thought thou. After several
trials I get the same error with :: and ->. My old code
still produces the same error. Seems to have something
to do with Smarty. When I load Smarty and run the
display( 'index.tpl' ) it causes the "page could not
load" error. I sometimes get a lot of warnings, like :
fetch() could not find index.tpl etc. And it doesnt
produce any files in the template_c folder, so
something is wrong...
[2003-06-15 03:08:41] [EMAIL PROTECTED]
But it's still a bug. Can you provide a full script (ie, we can copy
and paste it and run it, that script includes then)?
Derick
[2003-06-14 18:06:19] terjeto at stud dot ntnu dot no
worked with return $this::array; :)
[2003-06-14 18:03:32] terjeto at stud dot ntnu dot no
Description:
A function get_array() inside the class Foo tries to
return an array stored inside the class. This worked
fine in PHP4, but in the latest PHP5 the webpage wont
load.
Reproduce code:
---
class Foo {
var $array = array();
function get_array() {
return $this->array;
}
}
Expected result:
expected to see the page or at least an error message
of what the problem was.
Actual result:
--
the page didnt load at all. i got "page could not load"
every time. if i commented the "return ..." and
replaced it with "return true;" or anything else it
worked, but when i tried to return an array the webpage
wouldnt load at all
--
Edit this bug report at http://bugs.php.net/?id=24187&edit=1
#21669 [Ver->Ana]: "$obj = new $this->var;" doesn't work
ID: 21669 Updated by: [EMAIL PROTECTED] Reported By: slowbyte at hot dot ee -Status: Verified +Status: Analyzed Bug Type: Zend Engine 2 problem Operating System: Debian Linux 3.0r0 PHP Version: 5CVS-2003-01-15 (dev) New Comment: This is due to dynamic_class_name chain of rules, which does not allow property references. Somebody with more parser knowledge (which means Zeev or Andi, I guess :) should look at it. Previous Comments: [2003-03-02 05:15:28] [EMAIL PROTECTED] Verified with latest CVS. [2003-02-18 12:51:16] yoglets at hotmail dot com FWIW, this problem is still present in a post-nested-class ZE2 build: [2003-01-28 19:55:58] yoglets at hotmail dot com Don't know if this is the same issue or not, but it's certainly related. You can't use $obj = new $name for nested classes either. For example: [2003-01-15 11:56:13] slowbyte at hot dot ee The following snippet is a parse error in PHP5-ZE2 (used to work on earlier versions). This feature is also used in Smarty templates. name; /* Parse error */ return $obj; } } $factory = new Factory; $test = $factory->create(); $test->say_hello(); ?> -- Edit this bug report at http://bugs.php.net/?id=21669&edit=1
#24187 [Fbk->Opn]: Smarty causes "page could not load" error
ID: 24187
User updated by: terjeto at stud dot ntnu dot no
-Summary: returning an array from a object
Reported By: terjeto at stud dot ntnu dot no
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Red Hat 9.0
PHP Version: 5CVS-2003-06-14 (dev)
New Comment:
Cant seem to manage to reproduce the error.. The
problem wasnt what I first thought thou. After several
trials I get the same error with :: and ->. My old code
still produces the same error. Seems to have something
to do with Smarty. When I load Smarty and run the
display( 'index.tpl' ) it causes the "page could not
load" error. I sometimes get a lot of warnings, like :
fetch() could not find index.tpl etc. And it doesnt
produce any files in the template_c folder, so
something is wrong...
Previous Comments:
[2003-06-15 03:08:41] [EMAIL PROTECTED]
But it's still a bug. Can you provide a full script (ie, we can copy
and paste it and run it, that script includes then)?
Derick
[2003-06-14 18:06:19] terjeto at stud dot ntnu dot no
worked with return $this::array; :)
[2003-06-14 18:03:32] terjeto at stud dot ntnu dot no
Description:
A function get_array() inside the class Foo tries to
return an array stored inside the class. This worked
fine in PHP4, but in the latest PHP5 the webpage wont
load.
Reproduce code:
---
class Foo {
var $array = array();
function get_array() {
return $this->array;
}
}
Expected result:
expected to see the page or at least an error message
of what the problem was.
Actual result:
--
the page didnt load at all. i got "page could not load"
every time. if i commented the "return ..." and
replaced it with "return true;" or anything else it
worked, but when i tried to return an array the webpage
wouldnt load at all
--
Edit this bug report at http://bugs.php.net/?id=24187&edit=1
#21800 [Ver->Csd]: Segfault in CLI
ID: 21800 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: carl at thep dot lu dot se -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem -Operating System: RH 8.0 +Operating System: Linux PHP Version: 5CVS-2003-01-21 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-21 13:05:13] [EMAIL PROTECTED] The bug occurs due to the handler in execute_data.opline->handler not being set. [2003-01-21 12:47:55] [EMAIL PROTECTED] not reproduced with ZE1 => reclassfying as ZE2 problem [2003-01-21 12:45:08] [EMAIL PROTECTED] verified [2003-01-21 12:36:38] carl at thep dot lu dot se the following produces a coredump: [EMAIL PROTECTED]:30 [~]:php -ea Interactive mode enabled Segmentation fault (core dumped) Backtrace gives (gdb) bt #0 0x in ?? () #1 0x081f3a4f in execute (op_array=0x0) at /usr/local/src/cvs/php5/Zend/zend_execute.c:1218 #2 0x081d78b9 in execute_new_code () at /usr/local/src/cvs/php5/Zend/zend_execute_API.c:827 #3 0x081be693 in zendparse () at /usr/local/src/cvs/php5/Zend/zend_language_parser.y:148 #4 0x081c272d in compile_file (file_handle=0xb930, type=2) at /usr/local/src/cvs/php5/Zend/zend_language_scanner.l:297 #5 0x081e14ad in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/cvs/php5/Zend/zend.c:992 #6 0x081a84c7 in php_execute_script (primary_file=0xb930) at /usr/local/src/cvs/php5/main/main.c:1691 #7 0x0820966f in main (argc=2, argv=0xb9c4) at /usr/local/src/cvs/php5/sapi/cli/php_cli.c:753 #8 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=21800&edit=1
#23750 [Opn]: Win32 build failed (snaps.php.net)
ID: 23750 User updated by: rabus at users dot sourceforge dot net Reported By: rabus at users dot sourceforge dot net Status: Open Bug Type: Compile Failure Operating System: Win32 -PHP Version: 5CVS-2003-05-22 (dev) +PHP Version: 5CVS-2003-06-15 (dev) New Comment: Any news on this? Previous Comments: [2003-05-22 17:13:58] [EMAIL PROTECTED] This is because the expat library is not bundled in PHP sources anymore. Edin, or someone should look into using the libxml2 instead for this. [2003-05-22 05:34:29] rabus at users dot sourceforge dot net Since May 18th, there have no new Win32 CVS builds been released from the HEAD branch on snaps.php.net due to a compile failure (again). It would be great if you could fix that soon. Regards, Alexander M. Turek -- Edit this bug report at http://bugs.php.net/?id=23750&edit=1
#24187 [Bgs->Fbk]: returning an array from a object
ID: 24187
Updated by: [EMAIL PROTECTED]
Reported By: terjeto at stud dot ntnu dot no
-Status: Bogus
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Red Hat 9.0
PHP Version: 5CVS-2003-06-14 (dev)
New Comment:
But it's still a bug. Can you provide a full script (ie, we can copy
and paste it and run it, that script includes then)?
Derick
Previous Comments:
[2003-06-14 18:06:19] terjeto at stud dot ntnu dot no
worked with return $this::array; :)
[2003-06-14 18:03:32] terjeto at stud dot ntnu dot no
Description:
A function get_array() inside the class Foo tries to
return an array stored inside the class. This worked
fine in PHP4, but in the latest PHP5 the webpage wont
load.
Reproduce code:
---
class Foo {
var $array = array();
function get_array() {
return $this->array;
}
}
Expected result:
expected to see the page or at least an error message
of what the problem was.
Actual result:
--
the page didnt load at all. i got "page could not load"
every time. if i commented the "return ..." and
replaced it with "return true;" or anything else it
worked, but when i tried to return an array the webpage
wouldnt load at all
--
Edit this bug report at http://bugs.php.net/?id=24187&edit=1
