Bug #15940 Updated: Segmentation fault (11)
ID: 15940 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache related Operating System: Linux PHP Version: 4.1.2 New Comment: I found that if you pass the wrong type of object to ibase_free_result or ibase_free_query you cause the Apache child running the PHP script to segfault. So, for example, if I create a query object and then later pass it to ibase_free_result I guarantee that the Apache child segfaults. Maybe an object check should take place inside the ibase_free_result to see that it was actually passed a result rather than a query object. Like one of the other people reporting this bug, the page renders to a point and then (I guess when Apache dies) no more of the document is returned. I spent a week trying to solve this problem and it manifests itself in 4.1.1 and 4.1.2. I'm running Red Hat 7.2 with Apache 1.3.20. PHP was built using a very long set of options - if they are required please e-mail me and I will send them. I'm running PHP as an Apache module without the CGI option. Previous Comments: [2002-03-08 08:23:52] [EMAIL PROTECTED] [root@trex dev]# gdb /usr/sbin/httpd GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run -X Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) PHP was compiled with: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug [2002-03-08 06:18:03] [EMAIL PROTECTED] To properly diagnose this bug, 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. [2002-03-08 04:28:47] [EMAIL PROTECTED] I have the sam problem (PHP 4.1.2 Apache 1.3.23) I'm intalling a new server so I'm the only one testing it but i still get Segmentation fault if I use Interbase. [2002-03-07 15:07:55] [EMAIL PROTECTED] There seems to be a bug in PHP 4.1.2. Being not an expert in this kind of stuff I can only report the symptoms. We are running the site for quite a time without any problems (4.0.6 compiled with configure --with-apache=../apache_1.3.23 --enable-track-vars --with-interbase=/opt/interbase --enable-trans-id). After upgrading to 4.1.2 the output of PHP did occasionally - not always - create only parts of the expected output. The apache error log showed child pid 8354 exit signal Segmentation fault (11) for about every 20 sec. The site has quite a high load with about 80 kByte/s at the time of watching this. Switching back to 4.0.6 made the problem disappear. On a other server with almost exactly the same config the problem does not occur. The only difference between the two is that the load is lower (between 1 and 4 kBytes/s) and that Interbase is not used by any PHP script on the server but support is compiled in and interbase is running. -- Edit this bug report at http://bugs.php.net/?id=15940edit=1
Bug #15830 Updated: configure recognize lib mcrypt 2.4 as 2.2
ID: 15830 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: mcrypt related Operating System: RedHat Linux 7.2 PHP Version: 4.1.2 New Comment: Derick: just sent to you via email again :) bye, Alessandro Previous Comments: [2002-03-13 04:18:29] [EMAIL PROTECTED] I can't find that configure.log here... can you resend it? Derick [2002-03-13 03:53:31] [EMAIL PROTECTED] Yes, it is the same problem :) [2002-03-13 01:29:40] [EMAIL PROTECTED] PHP 4.1.2 compiles fine, but when I run a test script using libmcrypt it returns: libmcrypt is 2.2.x when I am really using libmcrypt 2.4.22. Could this be the same problem? [2002-03-02 10:36:53] [EMAIL PROTECTED] That is really weird, because mcrypt didn't change one single bit. Can you send me your configure.log (or config.log) (privately please)? Derick [2002-03-02 10:34:56] [EMAIL PROTECTED] configure in php 4.1.2 will recognize libmcrypt 2.4.x (tested with libmcrypt 2.4.15/16 and 22) as libmcrypt 2.2.x. This will cause compile to fail due to some missing #define php 4.1.1 perfectly works instead (tested with the same libmcrypt versions). -- Edit this bug report at http://bugs.php.net/?id=15830edit=1
Bug #16030 Updated: Cannot load php_ldap.php extension
ID: 16030 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows NT SP 6 PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-12 20:37:13] [EMAIL PROTECTED] I copied the libsasl.dll to %windir%\system32 directory but it didn't work. [2002-03-12 20:31:43] [EMAIL PROTECTED] The other extensions I use (db, dba, dbase, gd)works properly, but when I try to put the ldap extension PHP always say: Unable to load dynamic library 'D:\PHP\php_ldap.php' - The specified procedure could not be found. I copied the libsasl.dll to %winnt%\system32 directory but it didn't work. -- Edit this bug report at http://bugs.php.net/?id=16030edit=1
Bug #16035: Printer - functionality
From: [EMAIL PROTECTED] Operating system: NT4 PHP version: 4.1.2 PHP Bug Type: Unknown/Other Function Bug description: Printer - functionality printer functions are not available in this version!! including php_printer.dll is not working! how can i activate printer functionality ??? thx -- Edit bug report at http://bugs.php.net/?id=16035edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16035r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16035r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16035r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16035r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16035r=support Expected behavior: http://bugs.php.net/fix.php?id=16035r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16035r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16035r=submittedtwice
Bug #16031 Updated: installation
ID: 16031 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned -Bug Type: PHP options/info functions +Bug Type: Documentation problem Operating System: window XP PHP Version: 4.1.2 -Assigned To: +Assigned To: sander New Comment: Reclassified as docu prob and assigning to myself. Previous Comments: [2002-03-13 05:13:14] [EMAIL PROTECTED] Maybe you have a c:\windows\system or c:\windows\system32 directory? [2002-03-12 21:22:40] [EMAIL PROTECTED] In the installation guide, there's part says that copy all .dll files to c:\winnt\system32 for Windows NT/2000/XP , but c:\winnt\system32 directory is not existed in windowXP. The same problem for the .ini file, there is no c:\winnt40 exist. Please let me know where should I copy these files to. Thanks mt -- Edit this bug report at http://bugs.php.net/?id=16031edit=1
Bug #15940 Updated: Segmentation fault (11)
ID: 15940 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Linux PHP Version: 4.1.2 New Comment: I should mention that the problems occurs even if there is no call to Interbase at all. In our case we saw it happen in an index.php file which gets some session values and sets some constants base on the environment. It then creates html/javascript to open a new browser window. This didn't happen as the rendering ended inmidst the javascript code. Only after this is Interbase involved. Previous Comments: [2002-03-13 04:03:07] [EMAIL PROTECTED] I found that if you pass the wrong type of object to ibase_free_result or ibase_free_query you cause the Apache child running the PHP script to segfault. So, for example, if I create a query object and then later pass it to ibase_free_result I guarantee that the Apache child segfaults. Maybe an object check should take place inside the ibase_free_result to see that it was actually passed a result rather than a query object. Like one of the other people reporting this bug, the page renders to a point and then (I guess when Apache dies) no more of the document is returned. I spent a week trying to solve this problem and it manifests itself in 4.1.1 and 4.1.2. I'm running Red Hat 7.2 with Apache 1.3.20. PHP was built using a very long set of options - if they are required please e-mail me and I will send them. I'm running PHP as an Apache module without the CGI option. [2002-03-08 08:23:52] [EMAIL PROTECTED] [root@trex dev]# gdb /usr/sbin/httpd GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run -X Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) PHP was compiled with: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug [2002-03-08 06:18:03] [EMAIL PROTECTED] To properly diagnose this bug, 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. [2002-03-08 04:28:47] [EMAIL PROTECTED] I have the sam problem (PHP 4.1.2 Apache 1.3.23) I'm intalling a new server so I'm the only one testing it but i still get Segmentation fault if I use Interbase. [2002-03-07 15:07:55] [EMAIL PROTECTED] There seems to be a bug in PHP 4.1.2. Being not an expert in this kind of stuff I can only report the symptoms. We are running the site for quite a time without any problems (4.0.6 compiled with configure --with-apache=../apache_1.3.23 --enable-track-vars --with-interbase=/opt/interbase --enable-trans-id). After upgrading to 4.1.2 the output of PHP did occasionally - not always - create only parts of the expected output. The apache error log showed child pid 8354 exit signal Segmentation fault (11) for about every 20 sec. The site has quite a high load with about 80 kByte/s at the time of watching this. Switching back to 4.0.6 made the problem disappear. On a other server with almost exactly the same config the problem does not occur. The only difference between the two is that the load is lower (between 1 and 4 kBytes/s) and that Interbase is not used by any PHP script on the server but support is compiled in and interbase is running. -- Edit this bug report at http://bugs.php.net/?id=15940edit=1
Bug #16036: in_array() with pow()
From: [EMAIL PROTECTED] Operating system: Solaris PHP version: 4.1.0 PHP Bug Type: *Math Functions Bug description: in_array() with pow() $a = pow(2,31); $b = array($a); var_dump( in_array(2147483648, $b)); $b = array(2147483648); var_dump( in_array(2147483648, $b)); // this is the result. how come there are different? bool(false) bool(true) -- Edit bug report at http://bugs.php.net/?id=16036edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16036r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16036r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16036r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16036r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16036r=support Expected behavior: http://bugs.php.net/fix.php?id=16036r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16036r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16036r=submittedtwice
Bug #16036 Updated: in_array() with pow()
ID: 16036 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Solaris PHP Version: 4.1.0 New Comment: var_dump() _ONLY_ works on variables. Previous Comments: [2002-03-13 06:15:21] [EMAIL PROTECTED] $a = pow(2,31); $b = array($a); var_dump( in_array(2147483648, $b)); $b = array(2147483648); var_dump( in_array(2147483648, $b)); // this is the result. how come there are different? bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=16036edit=1
Bug #16036 Updated: in_array() with pow()
ID: 16036 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Math Functions Operating System: Solaris PHP Version: 4.1.0 New Comment: This is a variation of the commonly asked floating point number comparison question. At numbers beyond 2^31-1 pow() returns a float. Doing exact comparisons of an integer against a floating point value in any computer language is tricky because of the way floating point numbers are represented. You could make sure your precision is set the way you want and convert to a string, or apply a fuzz factor. Previous Comments: [2002-03-13 06:20:57] [EMAIL PROTECTED] var_dump() _ONLY_ works on variables. [2002-03-13 06:15:21] [EMAIL PROTECTED] $a = pow(2,31); $b = array($a); var_dump( in_array(2147483648, $b)); $b = array(2147483648); var_dump( in_array(2147483648, $b)); // this is the result. how come there are different? bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=16036edit=1
Bug #16037: random parse errors on dual xeon machine
From: [EMAIL PROTECTED] Operating system: Win PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: random parse errors on dual xeon machine I am using Php in a Win enviornment. The machine has a Raid 5 system, 1GB Ram and two Xeon 700 CPUs. PHP runs in Apache (1.3.23) as Module. I am using official binaries PHP and Apache. There are very strang parse errors in files that are 100% ok. The files are used in three other installations and there are no errors at all. I think there is something bad with threading. I noticed the error when a session is accessed within a frame e.g. 3 or more independant PHP files usind the same data. There is a newsgroup posting dealing with the same problem: http://groups.google.com/groups?q=php+xeon+parse+errorhl=deselm=Pine.BSF.4.10.10203070837300.22588-10%40sea-incorporated.comrnum=1 -- Edit bug report at http://bugs.php.net/?id=16037edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16037r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16037r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16037r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16037r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16037r=support Expected behavior: http://bugs.php.net/fix.php?id=16037r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16037r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16037r=submittedtwice
Bug #16038: COM Object: Works fine with PHP 4.0.6, causes Access Violation with 4.1.1
From: [EMAIL PROTECTED] Operating system: Windows NT 4.0 Server PHP version: 4.1.1 PHP Bug Type: COM related Bug description: COM Object: Works fine with PHP 4.0.6, causes Access Violation with 4.1.1 I wrote a very simple ActiveX Library with Delphi 5, containing an Automation Object with just a few functions. Calling this object from Delphi, ASP or PHP 4.0.6 worked fine, but from PHP 4.1.1 did not. $myObj = new COM(...); or $myObj = com_load(...); worked and returned an object (at least echo $myObj; said so) and $myObj = null destroyed it, but whenever I called any object function (whether by $myObj-...; or com_invoke(...) did not matter), I got an Access Violation. I tried lots of different versions with functions actually doing nothing at all and with different kinds of parameters or none, the result was always the same. Also, the problem occurred on both Apache and IIS, and with the Library written under Delphi as well as under Visual C++. Only when replacing PHP 4.1.1 by older 4.0.6 (I did not replace php.ini), it suddenly worked as expected. Personally, I am satisfied now. But for others who might spend a lot of time and nerves as I did, i thought it worth dropping this note -- Edit bug report at http://bugs.php.net/?id=16038edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16038r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16038r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16038r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16038r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16038r=support Expected behavior: http://bugs.php.net/fix.php?id=16038r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16038r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16038r=submittedtwice
Bug #16036 Updated: in_array() with pow()
ID: 16036 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Math Functions Operating System: Solaris PHP Version: 4.1.0 New Comment: Can anyone give me a workable version? I've tried even to convert all numbers into integers, floats or whatever. It still does not work. Previous Comments: [2002-03-13 06:23:40] [EMAIL PROTECTED] This is a variation of the commonly asked floating point number comparison question. At numbers beyond 2^31-1 pow() returns a float. Doing exact comparisons of an integer against a floating point value in any computer language is tricky because of the way floating point numbers are represented. You could make sure your precision is set the way you want and convert to a string, or apply a fuzz factor. [2002-03-13 06:20:57] [EMAIL PROTECTED] var_dump() _ONLY_ works on variables. [2002-03-13 06:15:21] [EMAIL PROTECTED] $a = pow(2,31); $b = array($a); var_dump( in_array(2147483648, $b)); $b = array(2147483648); var_dump( in_array(2147483648, $b)); // this is the result. how come there are different? bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=16036edit=1
Bug #16036 Updated: in_array() with pow()
ID: 16036 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Math Functions Operating System: Solaris PHP Version: 4.1.0 New Comment: The bug database is not the place to ask questions like this. And like I mentioned, just convert to a string: $a = pow(2,31); $b = array($a); echo in_array(2147483648, $b); That prints 1 Previous Comments: [2002-03-13 06:47:58] [EMAIL PROTECTED] Can anyone give me a workable version? I've tried even to convert all numbers into integers, floats or whatever. It still does not work. [2002-03-13 06:23:40] [EMAIL PROTECTED] This is a variation of the commonly asked floating point number comparison question. At numbers beyond 2^31-1 pow() returns a float. Doing exact comparisons of an integer against a floating point value in any computer language is tricky because of the way floating point numbers are represented. You could make sure your precision is set the way you want and convert to a string, or apply a fuzz factor. [2002-03-13 06:20:57] [EMAIL PROTECTED] var_dump() _ONLY_ works on variables. [2002-03-13 06:15:21] [EMAIL PROTECTED] $a = pow(2,31); $b = array($a); var_dump( in_array(2147483648, $b)); $b = array(2147483648); var_dump( in_array(2147483648, $b)); // this is the result. how come there are different? bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=16036edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... Previous Comments: [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. [2002-03-04 04:38:12] [EMAIL PROTECTED] Can you please try a shapshot from snaps.php.net, my guess is that this is already fixed. Derick [2002-03-04 00:55:05] [EMAIL PROTECTED] It looks you are having session bug. It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere in your script, aren't you? [2002-03-03 21:12:33] [EMAIL PROTECTED] I'm seeing the same problem with 4.1.2. Can reproduce, but with no consistency. I'm also seeing a problem where PHP isn't responded to POSTs (watching it in ethereal, I had to post repeatedly to get a response; the responding page was to set a couple cookies and do a redirect). Any possibility that they might be related? (Had added a comment with a backtrace, but this one looks much more useful): #0 0x402ad693 in _zend_is_inconsistent (ht=0x0, file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84 #1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0xb090) at zend_hash.c:975 #2 0x4031da18 in php_session_save_current_state () at session.c:544 #3 0x40320579 in php_session_flush () at session.c:1381 #4 0x403205bd in zm_deactivate_session (type=1, module_number=3) at session.c:1393 #5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at zend_API.c:1165 #6 0x402af394 in zend_hash_apply (ht=0x404808c0, apply_func=0x402ac5d0 module_registry_cleanup) at zend_hash.c:669 #7 0x402a8a4e in zend_deactivate_modules () at zend.c:585 #8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723 #9 0x402b63ff in apache_php_module_main (r=0x80ab44c, display_source_mode=0) at sapi_apache.c:96 #10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0, filename=0x80ab9cc /usr/local/apache/htdocs/planworld/index.php) at mod_php4.c:575 #11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590 #12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1 #13 0x400630b9 in ?? () from /lib/libdb.so.3 #14 0x40063529 in ?? () from /lib/libdb.so.3 #15 0x400354e2 in ?? () from /lib/libcrypt.so.1 #16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1 #17 0x400630b9 in ?? () from /lib/libdb.so.3 #18 0x4006312f in ?? () from /lib/libdb.so.3 #19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1 #20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1 #21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1 #22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1 #23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1 #24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so #25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
Bug #15568 Updated: ImageTTFText doesn't work in 4.1.1
ID: 15568 Updated by: [EMAIL PROTECTED] -Summary: ImageTTFText doesn't work in 4.1.1 Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux PHP Version: 4.1.1 New Comment: Again, unfortunately no messages. Just the black square. Previous Comments: [2002-03-12 16:26:58] [EMAIL PROTECTED] Tried with PHP 4.1.2 on Win2K/Apache - still doesn't work - still getting those funny characters as the error message I noted earlier on. [2002-02-27 12:15:45] [EMAIL PROTECTED] Tried with PHP 4.1.2. It still doesn't work. [2002-02-24 19:12:57] [EMAIL PROTECTED] I have come across the same issue on Win2K running PHP4.1.1. The code worked in 4.0.6 though. The error message I am getting (if I comment out the ImagePNG line) is a strange one: Warning: óO in (file) on line 6 Those funny characters (if you can see them) are what PHP outputs - they seem to be fairly random though - sometimes I get different funny characters. [2002-02-21 17:25:15] [EMAIL PROTECTED] Remove the header line and take a look at the output. You will probably see the error now [2002-02-15 09:50:55] [EMAIL PROTECTED] No errors. Just a black square. 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/15568 -- Edit this bug report at http://bugs.php.net/?id=15568edit=1
Bug #12061 Updated: CGI Error
ID: 12061 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Win 2K PHP Version: 4.0.6 New Comment: Çá Previous Comments: [2002-03-01 17:02:20] [EMAIL PROTECTED] i get this CGI Error when only running phpmyadmin...and i've following everything to the line. using win2kpro sp2 iis5 [2002-02-28 07:46:22] [EMAIL PROTECTED] I've fixed the problem, all you gotta do is set full permition to phpmyadmin directory. At least now it works fine on my w2k server. =] [2002-02-28 07:11:26] [EMAIL PROTECTED] I'm having the same problem mikevalstar, I've tried a lot of things but I can't manage to have the phpmyadmin to open! Please if there's someone out there who knows what's going on. Let me know! Tkz. [2002-02-18 14:15:31] [EMAIL PROTECTED] i am attempting to run phpmyadmin and all i get is a split screen in franes with a cgi error in both, i have the newest version of mysql and the newest version of php, im running on a win 2000 box and i am running iis. any ideas how to fix my problem? [2001-07-12 06:16:13] [EMAIL PROTECTED] Ok - you don't seem to want to read install.txt, so here's the relevant bit - please read and act on it: You have installed PHP, but when try to access a php script file via your browser, you get the error: cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: This error message means that php failed to output anything at all. From the command line hange to the directory containing php.exe. Run php.exe -i If php has any problems running, then a suitable error message will be displayed which will give you a clue as to what needs to be done next. If you get a screen full of html codes (the output of the phpinfo() function) then php is working ok. Once php is working at the command line, try accessing the php script via the browser again. If it still fails then it could be one of the following: file permissions on your php script, php.exe, php4ts.dll, php.ini or any php extensions you are trying to load are such that the anonymous internet user ISUR_machinename cannot access them. The script file does not exist (or possibly isn't where you think it is relative to your web root directory). Note that for IIS you can trap this error by ticking the 'check file exists' box when setting up the script mappings in the Internet Services Manager. If a script file does not exist then the server will return a 404 error instead. There is also the additional benefit that IIS will do any authentication required for you based on the NTLanMan permissions on your script file. Other problems If you are still stuck, someone on the PHP installation mailing list may be able to help you. You should check out the archive first, in case someone already answered someone else who had the same problem as you. The archives are available from the support page on www.php.net To subscribe to the PHP installation mailing list, send an empty mail to [EMAIL PROTECTED] The mailing list address is [EMAIL PROTECTED] If you want to get help on the mailing list, please try to be precise and give the necessary details about your environment (which operating system, what PHP version, what web server, if ou are running PHP as CGI or a server module, etc.), and referably enough code to make others able to reproduce and test our problem. 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/12061 -- Edit this bug report at http://bugs.php.net/?id=12061edit=1
Bug #16041: CGI and EXECUTABLE version produce different results for environment variables
From: [EMAIL PROTECTED] Operating system: Windows 2000 + IIS 5 PHP version: 4.1.2 PHP Bug Type: PHP options/info functions Bug description: CGI and EXECUTABLE version produce different results for environment variables Upgraded from v4.1.1 to v4.1.2 - using EXE under IIS Tried to use ISAPI module for IIS as previous versions were still unstable, this version appears better however certain $_SERVER variable go missing, e.g. $_SERVER[PATH_INFO] is not present when running phpinfo() if using the ISAPI module, but reappears when using PHP.EXE BTW. Not sure if this happened in 4.1.0 or 4.1.1 as those versions of the ISAPI module would not run very well on my system. Perhaps the ISAPI module isn't reading the PHP.INI from the same place as PHP.EXE? -- Edit bug report at http://bugs.php.net/?id=16041edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16041r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16041r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16041r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16041r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16041r=support Expected behavior: http://bugs.php.net/fix.php?id=16041r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16041r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16041r=submittedtwice
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: Which webserver and version do you use? Derick Previous Comments: [2002-03-13 08:19:41] [EMAIL PROTECTED] Further to my previous comment. I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem. [2002-03-13 07:10:42] [EMAIL PROTECTED] RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. [2002-03-04 04:38:12] [EMAIL PROTECTED] Can you please try a shapshot from snaps.php.net, my guess is that this is already fixed. Derick 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: i faintly remember issues with the gcc version RedHat uses (experimental gcc prerelease from their own labs or something) there were definetly problems in the past that where RedHat-only :( do you have a chance to test on another linux distribution or to compile on another one and transfer the binaries to your RH system? Previous Comments: [2002-03-13 08:31:53] [EMAIL PROTECTED] Which webserver and version do you use? Derick [2002-03-13 08:19:41] [EMAIL PROTECTED] Further to my previous comment. I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem. [2002-03-13 07:10:42] [EMAIL PROTECTED] RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #16042: mkdir no longer works correcrly (wrong UID)
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.2
PHP Bug Type: *Directory/Filesystem functions
Bug description: mkdir no longer works correcrly (wrong UID)
ENV:
Linux 2.2.19/apache 1.3.23/ Safe mode on, latest security
update
The following simple scripts no longer work:
?
mkdir('/var/www/web/test/testfolder' , 0777);
mkdir('/var/www/web/test/testfolder/another', 0777);
?
It generates: SAFE MODE Restriction in effect. The script
whose uid is 48561 is not allowed to
access /var/www/web/test/testfolder owned by uid 98 in ..
--
Edit bug report at http://bugs.php.net/?id=16042edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16042r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16042r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16042r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16042r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16042r=support
Expected behavior: http://bugs.php.net/fix.php?id=16042r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16042r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16042r=submittedtwice
Bug #16042 Updated: mkdir no longer works correcrly (wrong UID)
ID: 16042
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.1.2
New Comment:
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
Previous Comments:
[2002-03-13 09:26:53] [EMAIL PROTECTED]
ENV:
Linux 2.2.19/apache 1.3.23/ Safe mode on, latest security
update
The following simple scripts no longer work:
?
mkdir('/var/www/web/test/testfolder' , 0777);
mkdir('/var/www/web/test/testfolder/another', 0777);
?
It generates: SAFE MODE Restriction in effect. The script
whose uid is 48561 is not allowed to
access /var/www/web/test/testfolder owned by uid 98 in ..
--
Edit this bug report at http://bugs.php.net/?id=16042edit=1
Bug #16042 Updated: mkdir no longer works correcrly (wrong UID)
ID: 16042
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Feedback
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.1.2
New Comment:
Which working version were you using prior ?
Previous Comments:
[2002-03-13 09:57:46] [EMAIL PROTECTED]
This is NOT a support question!
We have lost 37 websites in the last few days due to a BUG
in the security update. Come on people! I provided a
sample script not because I need help, but because I
thought you did. We are hacking into the php core now to
get it running again as we are a hosting service and ALL
AND EVERY WEBSITE USING PHP's mkdir function do not work
because of a problem (READ BUG) with the uid setup.
[2002-03-13 09:49:59] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-03-13 09:26:53] [EMAIL PROTECTED]
ENV:
Linux 2.2.19/apache 1.3.23/ Safe mode on, latest security
update
The following simple scripts no longer work:
?
mkdir('/var/www/web/test/testfolder' , 0777);
mkdir('/var/www/web/test/testfolder/another', 0777);
?
It generates: SAFE MODE Restriction in effect. The script
whose uid is 48561 is not allowed to
access /var/www/web/test/testfolder owned by uid 98 in ..
--
Edit this bug report at http://bugs.php.net/?id=16042edit=1
Bug #16042 Updated: mkdir no longer works correcrly (wrong UID)
ID: 16042
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.1.2
-Assigned To:
+Assigned To: jflemer
Previous Comments:
[2002-03-13 10:02:07] [EMAIL PROTECTED]
Which working version were you using prior ?
[2002-03-13 09:57:46] [EMAIL PROTECTED]
This is NOT a support question!
We have lost 37 websites in the last few days due to a BUG
in the security update. Come on people! I provided a
sample script not because I need help, but because I
thought you did. We are hacking into the php core now to
get it running again as we are a hosting service and ALL
AND EVERY WEBSITE USING PHP's mkdir function do not work
because of a problem (READ BUG) with the uid setup.
[2002-03-13 09:49:59] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-03-13 09:26:53] [EMAIL PROTECTED]
ENV:
Linux 2.2.19/apache 1.3.23/ Safe mode on, latest security
update
The following simple scripts no longer work:
?
mkdir('/var/www/web/test/testfolder' , 0777);
mkdir('/var/www/web/test/testfolder/another', 0777);
?
It generates: SAFE MODE Restriction in effect. The script
whose uid is 48561 is not allowed to
access /var/www/web/test/testfolder owned by uid 98 in ..
--
Edit this bug report at http://bugs.php.net/?id=16042edit=1
Bug #16042 Updated: mkdir no longer works correcrly (wrong UID)
ID: 16042
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Feedback
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.1.2
Assigned To: jflemer
New Comment:
Is it creating the first directory testfolder, or does it fail on the
first mkdir()?
Previous Comments:
[2002-03-13 10:02:07] [EMAIL PROTECTED]
Which working version were you using prior ?
[2002-03-13 09:57:46] [EMAIL PROTECTED]
This is NOT a support question!
We have lost 37 websites in the last few days due to a BUG
in the security update. Come on people! I provided a
sample script not because I need help, but because I
thought you did. We are hacking into the php core now to
get it running again as we are a hosting service and ALL
AND EVERY WEBSITE USING PHP's mkdir function do not work
because of a problem (READ BUG) with the uid setup.
[2002-03-13 09:49:59] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-03-13 09:26:53] [EMAIL PROTECTED]
ENV:
Linux 2.2.19/apache 1.3.23/ Safe mode on, latest security
update
The following simple scripts no longer work:
?
mkdir('/var/www/web/test/testfolder' , 0777);
mkdir('/var/www/web/test/testfolder/another', 0777);
?
It generates: SAFE MODE Restriction in effect. The script
whose uid is 48561 is not allowed to
access /var/www/web/test/testfolder owned by uid 98 in ..
--
Edit this bug report at http://bugs.php.net/?id=16042edit=1
Bug #16042 Updated: mkdir no longer works correcrly (wrong UID)
ID: 16042
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.1.2
Assigned To: jflemer
New Comment:
The second mkdir() will fail with a safe_mode restriction as it should.
This is not a bug. Files or directories created by PHP when PHP is
running as an Apache module will be owned by the Apache user id. There
is simply no way around that given the current state of Apache. And
the safe-mode restriction correctly restricts you from creating a
directory inside a directory not owned by the same uid as the script.
The fact that it worked before was a security problem which was fixed.
If you want to be able to do something like this, you should consider
using the open_basedir restriction mechanism where all these checks are
done based on the base directory and anything the user does
within/beneath that base directory is ok.
Please read http://www.php.net/manual/en/features.safe-mode.php and
http://www.php.net/manual/en/configuration.php#ini.open-basedir
Previous Comments:
[2002-03-13 10:05:44] [EMAIL PROTECTED]
Is it creating the first directory testfolder, or does it fail on the
first mkdir()?
[2002-03-13 10:02:07] [EMAIL PROTECTED]
Which working version were you using prior ?
[2002-03-13 09:57:46] [EMAIL PROTECTED]
This is NOT a support question!
We have lost 37 websites in the last few days due to a BUG
in the security update. Come on people! I provided a
sample script not because I need help, but because I
thought you did. We are hacking into the php core now to
get it running again as we are a hosting service and ALL
AND EVERY WEBSITE USING PHP's mkdir function do not work
because of a problem (READ BUG) with the uid setup.
[2002-03-13 09:49:59] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-03-13 09:26:53] [EMAIL PROTECTED]
ENV:
Linux 2.2.19/apache 1.3.23/ Safe mode on, latest security
update
The following simple scripts no longer work:
?
mkdir('/var/www/web/test/testfolder' , 0777);
mkdir('/var/www/web/test/testfolder/another', 0777);
?
It generates: SAFE MODE Restriction in effect. The script
whose uid is 48561 is not allowed to
access /var/www/web/test/testfolder owned by uid 98 in ..
--
Edit this bug report at http://bugs.php.net/?id=16042edit=1
Bug #16043: $_SESSION can't use in PHP 4.1.2
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.1.2 PHP Bug Type: Session related Bug description: $_SESSION can't use in PHP 4.1.2 as title, the global var. array $_SESSION can't use in PHP 4.1.2 (4.1.1/4.1.0 are OK) P.S. I install PHP in Apache 1.3.23 modules -- Edit bug report at http://bugs.php.net/?id=16043edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16043r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16043r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16043r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16043r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16043r=support Expected behavior: http://bugs.php.net/fix.php?id=16043r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16043r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16043r=submittedtwice
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: A question for [EMAIL PROTECTED] : Did you try it before the patch was applied in 4.0.6 Of the pages giving me grief, some of them have forms and some of them don't. I don't have the access at my end to try my scripts on a different linux version. Previous Comments: [2002-03-13 08:57:03] [EMAIL PROTECTED] i faintly remember issues with the gcc version RedHat uses (experimental gcc prerelease from their own labs or something) there were definetly problems in the past that where RedHat-only :( do you have a chance to test on another linux distribution or to compile on another one and transfer the binaries to your RH system? [2002-03-13 08:31:53] [EMAIL PROTECTED] Which webserver and version do you use? Derick [2002-03-13 08:19:41] [EMAIL PROTECTED] Further to my previous comment. I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem. [2002-03-13 07:10:42] [EMAIL PROTECTED] RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #16031 Updated: installation
ID: 16031 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Open Bug Type: Documentation problem Operating System: window XP PHP Version: 4.1.2 Assigned To: sander New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-13 05:37:38] [EMAIL PROTECTED] Reclassified as docu prob and assigning to myself. [2002-03-13 05:13:14] [EMAIL PROTECTED] Maybe you have a c:\windows\system or c:\windows\system32 directory? [2002-03-12 21:22:40] [EMAIL PROTECTED] In the installation guide, there's part says that copy all .dll files to c:\winnt\system32 for Windows NT/2000/XP , but c:\winnt\system32 directory is not existed in windowXP. The same problem for the .ini file, there is no c:\winnt40 exist. Please let me know where should I copy these files to. Thanks mt -- Edit this bug report at http://bugs.php.net/?id=16031edit=1
Bug #16031 Updated: installation
ID: 16031 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: window XP PHP Version: 4.1.2 Assigned To: sander New Comment: Weird... I used the Quick Fix 'Fixed in CVS' anyway, closing for real now. Previous Comments: [2002-03-13 10:29:53] [EMAIL PROTECTED] This bug has been fixed in CVS. [2002-03-13 05:37:38] [EMAIL PROTECTED] Reclassified as docu prob and assigning to myself. [2002-03-13 05:13:14] [EMAIL PROTECTED] Maybe you have a c:\windows\system or c:\windows\system32 directory? [2002-03-12 21:22:40] [EMAIL PROTECTED] In the installation guide, there's part says that copy all .dll files to c:\winnt\system32 for Windows NT/2000/XP , but c:\winnt\system32 directory is not existed in windowXP. The same problem for the .ini file, there is no c:\winnt40 exist. Please let me know where should I copy these files to. Thanks mt -- Edit this bug report at http://bugs.php.net/?id=16031edit=1
Bug #12335 Updated: mail() function returns false but the email was sent.
ID: 12335
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Mail related
Operating System: Sun Solaris 2.6
PHP Version: 4.0.6
New Comment:
I am experiencing this behaviour on a Cobalt RaQ3 (Linux)
running PHP 4.1.2. The mail function always returns false,
regardless of whether the mail was sent or not:
if ( mail( '...', '...', '...' ) ) {
echo mail sent okay!;
}
else {
echo mail not sent!;
}
This code will always say mail not sent! whether the mail
has been sent or not.
Previous Comments:
[2002-01-15 03:46:40] [EMAIL PROTECTED]
I also has same trouble with Solaris8+PHP4.1.1+Apache1.3.22.
It seems that, pcloase(inside of mail.c) always return -1.
So php_mail function always return FALSE.
when I remove /usr/lib/sendmail and test mail().
Apache's error_log report that Apache cannot fork sendmail.
but sendmail=popen(...) still return not NULL and pclose()
return -1.
I think that mail.c must fix for apache I/F or not?
[2001-08-07 07:45:11] [EMAIL PROTECTED]
I found out, that the problem is not the EX_OK or EX_TEMPFAIL but the
sendmail return value.
Sendmail (the sendmail qmail wrapper) is returning the value -1 when I
call it with php 4.0.6.
When I call it with 4.0.4pl than 0 is returned.
What could be the reason for this behaviour?
[2001-08-01 05:20:35] [EMAIL PROTECTED]
I had a look on the mail.c sourcecode and I made a change. So I found
the part where the error appears.
But I do not know why, in version 4.0.4pl1 it is the same code and with
this version it works.
This is the extract from mail.c where the error appears:
ret = pclose(sendmail);
#if definded (EX_TEMPFAIL)
if ((ret != EX_OK)(ret != EX_TEMPFAIL)) {
#else
if (ret != EX_OK) {
#endif
return 0;
} else {
return 1;
}
If I change the 0 to 1 than I get true as response of the mail()
function.
So what could be the problem with EX_OK and EX_TEMPFAIL that the same
if query is working in 4.0.4pl1 and not
in 4.0.6? Who is EX_OK and EX_TEMPFAIL defined?
[2001-07-30 01:42:49] [EMAIL PROTECTED]
This was a misunderstanding.
I have the problems with version 4.0.6.
But this machine is not on the internet. Because it's our testmachine.
Our livesystem thats on the internet has version 4.0.4 and we want to
update this machine to 4.0.6 but we can't do
that as long as we have the problem with the mail function. The both
systems are exactly the same.
I wrote this only to explain why I can't put the test script on the
internet.
[2001-07-27 13:27:28] [EMAIL PROTECTED]
So which version of PHP are you using? In your comments
you say 4.0.4 but in the headers there is 4.0.6??
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/12335
--
Edit this bug report at http://bugs.php.net/?id=12335edit=1
Bug #16044: crashing apparently in session module
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.7
PHP version: 4.1.2
PHP Bug Type: Reproducible crash
Bug description: crashing apparently in session module
Using any handler BUT files for sessions seems to crash the PHP program
nine times out of ten - once the session is registered, however, it seems
to operate just fine.
Here's my session code, hope it will help.
?PHP
require_once 'db.php';
$debug_session = 0;
$SESS_DBNAME = mage;
$SESS_DBTABLE = sessions;
//$SESS_LIFE = get_cfg_var(session.gc_maxlifetime);
$SESS_LIFE = 1800; // session data not refresh could run for 30 min?
function sess_open($save_path, $session_name) {
global $SESS_DBNAME, $SESS_DBTABLE, $debug_session;
return true;
}
function sess_close() {
global $debug_session;
return true;
}
function sess_read($key) {
global $debug_session, $SESS_DBNAME, $SESS_DBTABLE;
if($debug_session) echo sess_read($key)BR;
$q = SELECT svalue FROM $SESS_DBTABLE WHERE sesskey='$key' AND expire
.time();
$dbr = db_request($q);
if($dbr mysql_num_rows($dbr)) {
$q = DELETE FROM $SESS_DBTABLE WHERE sesskey='$key';
db_request($q);
header(Location: expire.php);
exit;
}
$q = SELECT svalue FROM $SESS_DBTABLE WHERE sesskey='$key' AND expire
. time();
$dbr = db_request($q);
if($debug_session) echo msql($q) returns $dbrBR;
if(!$dbr) return false;
$value = mysql_fetch_row($dbr);
if($debug_session) echo sess_read returning $value[0]BR;
return $value[0];
}
function sess_write($key, $val) {
global $user,$debug_session, $SESS_LIFE, $SESS_DBNAME, $SESS_DBTABLE;
$expire = time() + (60 * 30);
$value = addslashes($val);
$q = INSERT INTO $SESS_DBTABLE VALUES ('$key', $expire, '$value',
'$user[username]', '$user[location]', '$user[activity]');
$dbr = db_request($q);
if($debug_session) echo sess_write($key, $val)BRmsql($q) returns
$dbrBR;
if(!$dbr) {
$q = UPDATE $SESS_DBTABLE SET
location='$user[location]',activity='$user[activity]',username='$user[username]',expire=$expire,svalue='$value'
WHERE sesskey = '$key' AND expire . time();
$dbr = db_request($q);
}
if($debug_session) echo sess_write() returning $dbrBR;
return $dbr;
}
function sess_destroy($key) {
global $debug_session, $SESS_DBNAME, $SESS_DBTABLE;
$q = DELETE FROM $SESS_DBTABLE WHERE sesskey = '$key';
$dbr = db_request($q);
if($debug_session) echo sess_destroy($key)BRmsql($q) return
$dbrBR;
return $dbr;
}
function sess_gc($maxlifetime) {
global $SESS_DBNAME, $SESS_DBTABLE;
$q = DELETE FROM $SESS_DBTABLE WHERE expire . time();
$dbr = db_request($q);
return mysql_affected_rows();
}
function session_dump() {
$session_array = explode(';',session_encode());
$html = !-- SESSION VARIABLE DUMP\n\n;
for($x = 0; $x count($session_array); $x++) {
$html .= $session_array[$x] \n;
}
$html .= --\n\n;
echo $html;
}
function query_present($loc) {
global $SESS_DBTABLE;
$q = location='$loc' and expire .time();
$f = username,activity;
$dbr = db_array($SESS_DBTABLE, $q, $f);
if(!$dbr) return 0;
while($x = each($dbr)) {
$ret[$x['value']['username']] = $x['value']['activity'];
}
return $ret;
}
function query_num_online() {
global $SESS_DBTABLE;
$q = expire .time();
$f = count(*);
$dbr = db_single($SESS_DBTABLE, $q, $f);
return $dbr[0];
}
session_set_save_handler(sess_open, sess_close, sess_read,
sess_write, sess_destroy, sess_gc);
?
--
Edit bug report at http://bugs.php.net/?id=16044edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16044r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16044r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16044r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16044r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16044r=support
Expected behavior: http://bugs.php.net/fix.php?id=16044r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16044r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16044r=submittedtwice
Bug #16033 Updated: Can't return reference to class member variable from class method.
ID: 16033
Updated by: [EMAIL PROTECTED]
-Summary: Can't return reference to class member variable from
class method.
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: RedHat Linux 7.2, BeOS
PHP Version: 4.1.2
New Comment:
Whoops, I messed up. Sorry!
Previous Comments:
[2002-03-13 02:45:24] [EMAIL PROTECTED]
References are screwy when returned from object methods. Witness the
following (a script to illustrate the trouble):
-
class StringList
{
var $strings = array();
function AddString( $a_string )
{
$this-strings[] = $a_string;
/* return a reference to newly added item */
return( $this-strings[count($this-strings)-1] );
}
}
$stringvar = Hello World ;
$x = new StringList;
$y = $x-AddString( $stringvar );
/* this should change $x-strings[0], but does not! */
$y = I love PHP! ;
/* This should NOT fail, but it does! */
assert( $y == $x-strings[0] );
-
One could reasonably infer that because $y is a reference to
$x-strings[0], modifying $y would also cause $x-strings[0] to be
modified.
THIS IS NOT THE CASE. After the call to AddString, $y is a COPY of
$x-strings[0], which is NOT modified when we change $y's value.
Also, if I were to call AddString as $x-AddString(Some string),
$x-strings
is no longer an array and print_r($x-strings) screams *RECURSION*!
This is
weird, because I am passing in the string using copy, and returning a
reference
to the added copy.
If this is the correct behavior, I'll eat my hat.
The configure line specified --without-mysql, --without-pear, and my
prefix.
That's all.
--
Edit this bug report at http://bugs.php.net/?id=16033edit=1
Bug #16035 Updated: Printer - functionality
ID: 16035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: NT4 PHP Version: 4.1.2 New Comment: Please do not submit the same bug more than once. Previous Comments: [2002-03-13 05:39:43] [EMAIL PROTECTED] printer functions are not available in this version!! including php_printer.dll is not working! how can i activate printer functionality ??? thx -- Edit this bug report at http://bugs.php.net/?id=16035edit=1
Bug #15400 Updated: Queries Crashing PHP.EXE
ID: 15400 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: The same problem. Win2K Pro, PHP 4.1.2 ===PHP.INI error_reporting= E_ALL; display all errors, warnings and notices enable_dl=on extension_dir=c:\php\extensions extension=php_mssql.dll === ?php $h = mssql_connect(nest.rtsnet.ru,1433, wwwuser, ***); mssql_select_db(WebInfo); $rs = mssql_query(SELECT * FROM foo); ? Running from command line or as CGI results in the fatal application error. Any bug in query string results in normal PHP error message MS SQL: Query failed in . ODBC version works ok. Previous Comments: [2002-02-06 09:19:17] [EMAIL PROTECTED] the [] were just there to denote what I was putting into them [2002-02-06 09:12:58] [EMAIL PROTECTED] Well it does... Tried your way MSSQL_CONNECT(HOST:123, USER, PWD); got Warning: MS SQL: Unable to connect to server: HOST:123 in c:\inetpub\wwwroot\hello.php on line 5 Warning: MS SQL message: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. (severity 14) in c:\inetpub\wwwroot\hello.php on line 6 Warning: MS SQL: Unable to connect to server: (null) in c:\inetpub\wwwroot\hello.php on line 6 Warning: MS SQL: A link to the server could not be established in c:\inetpub\wwwroot\hello.php on line 6 Warning: MS SQL message: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. (severity 14) in c:\inetpub\wwwroot\hello.php on line 7 Warning: MS SQL: Unable to connect to server: (null) in c:\inetpub\wwwroot\hello.php on line 7 Warning: MS SQL: A link to the server could not be established in c:\inetpub\wwwroot\hello.php on line 7 Tried MSSQL_CONNECT(HOST,123, USER, PWD); and it crashes... with error stated in first posting [2002-02-06 07:35:20] [EMAIL PROTECTED] Are you calling mssql_connect() this way or did I misunderstand it? mssql_connect([localhost,123], [www], [secret]); AFAIK, you should just call mssql_connect(localhost:123, www, secret); Is that your problem? Anyway, it SHOULDN'T crash. [2002-02-06 05:50:49] [EMAIL PROTECTED] Evenin'... This morning I decided to try PHP for our company web site instead of VBScript. Imagine my delight to find PHP will handle SQL7 with the minimum of fuss... all it would take was ?php $hostname = [IPADDRESS],[PORT]; $username = [USER]; $password = [PWD]; $dbName = [DATABASENAME]; MSSQL_CONNECT($hostname,$username,$password) or DIE(DATABASE FAILED TO RESPOND.); mssql_select_db ( $dbName ); $query = SELECT * FROM [TABLE]; mssql_query ($query); ? Or even lazier ? MSSQL_CONNECT([IPADDRESS],[PORT],[USER],[PWD]); mssql_select_db ([DATABASENAME]); mssql_query (SELECT * FROM [TABLE]); ? Brilliant 15 lines of VBScript is 3 lines.. Imagine, then, my chagrin, for when I added the mssql_query(); statement I get a window saying PHP.EXE - Application Error.. The instruction at 0x00 referenced memory at 0x00, The memory could not be read... Is it me??? The setup I used was the windows installer but I put php_mssql.dll into c:\PHP and told the php.ini file where it was.. I also stuck the ntwdblib.dll into c:\windows\system32... Yes I know it should be c:\winnt but I changed it at setup... AAaaanyway... -- Edit this bug report at http://bugs.php.net/?id=15400edit=1
Bug #16020 Updated: long2ip Returns Incorrect Results
ID: 16020
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: FreeBSD 4.4-STABLE i386
PHP Version: 4.1.2
New Comment:
Strange... you script works fine for me...
Previous Comments:
[2002-03-12 10:41:44] [EMAIL PROTECTED]
I've done a little more digging to see why the problem occured. I'm
not 100% sure if it is a problem with php, or misuse of php really.
However it might be worth adding in something to make this work.
My script was getting the decimal address as a string, an integer. The
following example should illustrate it.
?
$moo = 167772161;
echo long2ip($moo);
echo BR;
$moo = 167772161;
echo long2ip($moo);
?
As a side thing you also need to add the following to get larger
numbers to work when using strings:
if ($moo 0) $moo += pow(2,32);
[2002-03-12 09:04:56] [EMAIL PROTECTED]
Sorry, I missed out a bit:
inet4oct blah;
;)
[2002-03-12 08:58:06] [EMAIL PROTECTED]
Can you provide a simple sample script with data that shows the
problem?
[2002-03-12 08:47:38] [EMAIL PROTECTED]
I have found some problems where long2ip (and I would presume ip2long
by the same token) seems to return an IP address offset by one. I'm
not sure if it is the implmentation of inet_ntoa on the platform I am
using or something else.
Even if this is a problem with a particular version of a library on my
machine, maybe it might be worth using a method other than inet_ntoa
for ease of platform independance?
Perhaps something along there lines ?
struct inet4addr {
unsigned int a:8;
unsigned int b:8;
unsigned int c:8;
unsigned int d:8;
};
typedef union {
unsigned int inet4dec;
struct inet4addr inet4oct;
} inet4oct;
blah.inet4dec = SOME LONG IP HERE;
printf(%i.%i.%i.%i\n, blah.inet4oct.a,
blah.inet4oct.b,blah.inet4oct.c,blah.inet4oct.d);
--
Edit this bug report at http://bugs.php.net/?id=16020edit=1
Bug #16045: count($array) logical error
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.1 PHP Bug Type: *General Issues Bug description: count($array) logical error Hello, Funny logical error: if we have a simple variable, say $x = 1 then count($x) == 1, which is natural (I don't think so) And if we have an array $x[0] = 1; count($x) == 1, but after UnSet($x[0]) we still have count($x) = 1! This leads to a very special kind of logical errors which are really hard to track. My suggestion: either: introduce explicit type system (with unions, structs and arrays ;) or: disable count on variables -- Edit bug report at http://bugs.php.net/?id=16045edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16045r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16045r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16045r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16045r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16045r=support Expected behavior: http://bugs.php.net/fix.php?id=16045r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16045r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16045r=submittedtwice
Bug #16020 Updated: long2ip Returns Incorrect Results
ID: 16020
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: FreeBSD 4.4-STABLE i386
PHP Version: 4.1.2
New Comment:
In which case I would suspect that this is a platform dependent bug, as
I have reproduced this on more than one FreeBSD machine, of different
versions (all 4.x) on differing processors.
Presumably as this works fine when the address is presented as an int
and not as a string, the problem lies in converting the string to an
integer value, before it is tranformed into dotted octet notation?
If this is the case then it is probably some .h file being misdetected
by the configure script??? /GUESS
Also another pointer to problems is that if you use a number that
requires more than 16 bits, then the returned address is always
127.255.255.255, which is quite a significant number.
My guess (although I am by no means an expert) is that in using some
function like strtoul we are loosing the long or the unsigned
attributes of the integer and so accidentally passing incorrect (16 bit
number instead of 32??) information about??
Previous Comments:
[2002-03-13 14:38:13] [EMAIL PROTECTED]
Strange... you script works fine for me...
[2002-03-12 10:41:44] [EMAIL PROTECTED]
I've done a little more digging to see why the problem occured. I'm
not 100% sure if it is a problem with php, or misuse of php really.
However it might be worth adding in something to make this work.
My script was getting the decimal address as a string, an integer. The
following example should illustrate it.
?
$moo = 167772161;
echo long2ip($moo);
echo BR;
$moo = 167772161;
echo long2ip($moo);
?
As a side thing you also need to add the following to get larger
numbers to work when using strings:
if ($moo 0) $moo += pow(2,32);
[2002-03-12 09:04:56] [EMAIL PROTECTED]
Sorry, I missed out a bit:
inet4oct blah;
;)
[2002-03-12 08:58:06] [EMAIL PROTECTED]
Can you provide a simple sample script with data that shows the
problem?
[2002-03-12 08:47:38] [EMAIL PROTECTED]
I have found some problems where long2ip (and I would presume ip2long
by the same token) seems to return an IP address offset by one. I'm
not sure if it is the implmentation of inet_ntoa on the platform I am
using or something else.
Even if this is a problem with a particular version of a library on my
machine, maybe it might be worth using a method other than inet_ntoa
for ease of platform independance?
Perhaps something along there lines ?
struct inet4addr {
unsigned int a:8;
unsigned int b:8;
unsigned int c:8;
unsigned int d:8;
};
typedef union {
unsigned int inet4dec;
struct inet4addr inet4oct;
} inet4oct;
blah.inet4dec = SOME LONG IP HERE;
printf(%i.%i.%i.%i\n, blah.inet4oct.a,
blah.inet4oct.b,blah.inet4oct.c,blah.inet4oct.d);
--
Edit this bug report at http://bugs.php.net/?id=16020edit=1
Bug #16046: isset empty parse error w/ objects
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.1.2
PHP Bug Type: Scripting Engine problem
Bug description: isset empty parse error w/ objects
/*
See the script below. Passing a value returned from an object function
call to isset() and empty() results in a parsing error. strlen() and other
functions don't have this problem. The code example below tests empty().
You may substitute isset() as well and get the same parse error.
This bug exists on both Apache 1.3.9/PHP 4.1.1 and Apache 1.3.23/PHP
4.1.2
*/
//first, declare a simple class with 1 function
class Foo {
function getStr() { return foo; }
}
//now make an object of that class
$foo = new Foo();
/*
* now let's test empty() with just the string
* this should evaluate false, and result in not empty
* being printed
*/
$fooStr = $foo-getStr();
if ( empty($foostr) ) {
echo empty!;
} else {
echo not empty!;
}
/*
* now test it using the object function call. This is the
* functional equivalent of the previous test, and should
* result in the same result. However it results in:
* Parse error: parse error, expecting `')''
* If you comment out this block, this script parses and
* executes successfully.
*/
if ( empty($foo-getStr()) ) {
echo empty!;
} else {
echo not empty!;
}
--
Edit bug report at http://bugs.php.net/?id=16046edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16046r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16046r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16046r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16046r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16046r=support
Expected behavior: http://bugs.php.net/fix.php?id=16046r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16046r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16046r=submittedtwice
Bug #16045 Updated: count($array) logical error
ID: 16045 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: All PHP Version: 4.1.1 New Comment: FWIW, I used the following script and got the correct results: ?php error_reporting(E_ALL); $x = array(1); echo Count: . count($x) . \n; unset($x[0]); echo Count: . count($x) . \n; ? Results: Count: 1 Count: 0 This is on version 4.2.0-dev. and 4.1.2. What does this script produce for you? Torben Previous Comments: [2002-03-13 15:11:08] [EMAIL PROTECTED] Hello, Funny logical error: if we have a simple variable, say $x = 1 then count($x) == 1, which is natural (I don't think so) And if we have an array $x[0] = 1; count($x) == 1, but after UnSet($x[0]) we still have count($x) = 1! This leads to a very special kind of logical errors which are really hard to track. My suggestion: either: introduce explicit type system (with unions, structs and arrays ;) or: disable count on variables -- Edit this bug report at http://bugs.php.net/?id=16045edit=1
Bug #16046 Updated: isset empty parse error w/ objects
ID: 16046
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.1.2
New Comment:
RTFM:
http://www.php.net/manual/en/function.empty.php
empty() only works with plain variables.
Previous Comments:
[2002-03-13 15:30:41] [EMAIL PROTECTED]
/*
See the script below. Passing a value returned from an object function
call to isset() and empty() results in a parsing error. strlen() and
other functions don't have this problem. The code example below tests
empty(). You may substitute isset() as well and get the same parse
error.
This bug exists on both Apache 1.3.9/PHP 4.1.1 and Apache 1.3.23/PHP
4.1.2
*/
//first, declare a simple class with 1 function
class Foo {
function getStr() { return foo; }
}
//now make an object of that class
$foo = new Foo();
/*
* now let's test empty() with just the string
* this should evaluate false, and result in not empty
* being printed
*/
$fooStr = $foo-getStr();
if ( empty($foostr) ) {
echo empty!;
} else {
echo not empty!;
}
/*
* now test it using the object function call. This is the
* functional equivalent of the previous test, and should
* result in the same result. However it results in:
* Parse error: parse error, expecting `')''
* If you comment out this block, this script parses and
* executes successfully.
*/
if ( empty($foo-getStr()) ) {
echo empty!;
} else {
echo not empty!;
}
--
Edit this bug report at http://bugs.php.net/?id=16046edit=1
Bug #16047: include_path does NOT default to .
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.2 PHP Bug Type: *Configuration Issues Bug description: include_path does NOT default to . Hi, Just drove my self crazy upgrading to the latest build for win32 4.1.2, as an apache module Granted I'm not very confident as to how this *should* work, I think I found a minor bug/inconsistency. If you do not set include_path it defaults to C:\php4\pear (or was it c:\php4\includes\pear ) I believe based upon reading this, include_path string Specifies a list of directories where the require(), include() and fopen_with_path() functions look for files. The format is like the system's PATH environment variable: a list of directories separated with a colon in UNIX or semicolon in Windows. Example 3-3. UNIX include_path include_path=.:/home/httpd/php-lib Example 3-4. Windows include_path include_path=.;c:\www\phplib bThe default value for this directive is . (only the current directory)/b. So... I'm guessing it should default to . instead of C:\php4\pear (or whatever) ... All of the includes on my site went bunk right after I upgraded... setting include_path = . rectified this for me. If this is obvious, and the intended effect, I apoligize in advance for my erroroneous bug report. Erik -- Edit bug report at http://bugs.php.net/?id=16047edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16047r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16047r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16047r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16047r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16047r=support Expected behavior: http://bugs.php.net/fix.php?id=16047r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16047r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16047r=submittedtwice
Bug #16047 Updated: include_path does NOT default to .
ID: 16047 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: I think someone else got the core of this issue and described it in more technical terms in Bug #15865 Sorry about the duplication, I did search before submitting, however I didn't find Bug #15865 until I browsed all the bugs for version 4.1.2 Thanks (so I guess you could close this, if the other one will get fixed) ! Erik Previous Comments: [2002-03-13 16:28:05] [EMAIL PROTECTED] Hi, Just drove my self crazy upgrading to the latest build for win32 4.1.2, as an apache module Granted I'm not very confident as to how this *should* work, I think I found a minor bug/inconsistency. If you do not set include_path it defaults to C:\php4\pear (or was it c:\php4\includes\pear ) I believe based upon reading this, include_path string Specifies a list of directories where the require(), include() and fopen_with_path() functions look for files. The format is like the system's PATH environment variable: a list of directories separated with a colon in UNIX or semicolon in Windows. Example 3-3. UNIX include_path include_path=.:/home/httpd/php-lib Example 3-4. Windows include_path include_path=.;c:\www\phplib bThe default value for this directive is . (only the current directory)/b. So... I'm guessing it should default to . instead of C:\php4\pear (or whatever) ... All of the includes on my site went bunk right after I upgraded... setting include_path = . rectified this for me. If this is obvious, and the intended effect, I apoligize in advance for my erroroneous bug report. Erik -- Edit this bug report at http://bugs.php.net/?id=16047edit=1
Bug #16046 Updated: isset empty parse error w/ objects
ID: 16046
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.1.2
New Comment:
Well, I did RTFM, quite a bit in fact. The result of the function call
*is* a plain variable, no? If not, your telling me that (from my
example) $foo-getStr() is not equal to the plain string foo? It's
just a string coming back from the call, and that should be accepted
into empty() just as if I'd typed a string in there to begin with.
Seems like the evaluation order is screwed up to me. In any case, if
this function is working as intended, a better FM might be in order
in this case.
Previous Comments:
[2002-03-13 15:53:21] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/function.empty.php
empty() only works with plain variables.
[2002-03-13 15:30:41] [EMAIL PROTECTED]
/*
See the script below. Passing a value returned from an object function
call to isset() and empty() results in a parsing error. strlen() and
other functions don't have this problem. The code example below tests
empty(). You may substitute isset() as well and get the same parse
error.
This bug exists on both Apache 1.3.9/PHP 4.1.1 and Apache 1.3.23/PHP
4.1.2
*/
//first, declare a simple class with 1 function
class Foo {
function getStr() { return foo; }
}
//now make an object of that class
$foo = new Foo();
/*
* now let's test empty() with just the string
* this should evaluate false, and result in not empty
* being printed
*/
$fooStr = $foo-getStr();
if ( empty($foostr) ) {
echo empty!;
} else {
echo not empty!;
}
/*
* now test it using the object function call. This is the
* functional equivalent of the previous test, and should
* result in the same result. However it results in:
* Parse error: parse error, expecting `')''
* If you comment out this block, this script parses and
* executes successfully.
*/
if ( empty($foo-getStr()) ) {
echo empty!;
} else {
echo not empty!;
}
--
Edit this bug report at http://bugs.php.net/?id=16046edit=1
Bug #16048: fgets/feof failure when stdin is reading from a pipe
From: [EMAIL PROTECTED]
Operating system: Solaris 2.7 2.8
PHP version: 4.1.2
PHP Bug Type: Filesystem function related
Bug description: fgets/feof failure when stdin is reading from a pipe
The fgets() function works differently when the input is a pipe.
Specifically, feof() returns true after the first line is read. The test
script and sample output follow. The test script works fine if stdin is
redirected from a file. It fails if stdin is a pipe.
Nothing special about the build:
./configure --prefix=/usr/local --with-mysql
pjm@poseidon cat test.php
#!/usr/local/bin/php -q
?php
$fd = fopen(php://stdin, r);
while (! feof($fd))
{
$buffer = fgets($fd, 4096);
echo $buffer;
}
?
pjm@poseidon test.php ./test.php
#!/usr/local/bin/php -q
?php
$fd = fopen(php://stdin, r);
while (! feof($fd))
{
$buffer = fgets($fd, 4096);
echo $buffer;
}
?
pjm@poseidon cat test.php | ./test.php
#!/usr/local/bin/php -q
--
Edit bug report at http://bugs.php.net/?id=16048edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16048r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16048r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16048r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16048r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16048r=support
Expected behavior: http://bugs.php.net/fix.php?id=16048r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16048r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16048r=submittedtwice
Bug #16050: does not set name variable in input type=image name=do..
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: does not set name variable in input type=image name=do.. the scripting engine does not set $doit when i submit input type=image name=do src=http://www.xxx.com/buttons/fund_off.jpg; sample code to test: ? if (isset($doit)) print yes; else print no; ? form name=form1 method=post action=./test.php input type=image name=doit src=http://www.xxx.com/buttons/fund_off.jpg; /form when i click on the image, i still get a no -- Edit bug report at http://bugs.php.net/?id=16050edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16050r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16050r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16050r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16050r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16050r=support Expected behavior: http://bugs.php.net/fix.php?id=16050r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16050r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16050r=submittedtwice
Bug #16049 Updated: Hidden Form fields do not POST/GET after include()
ID: 16049
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Output Control
Operating System: Linux
PHP Version: 4.1.2
New Comment:
Forgot to add something. The second variable (var2) won't even show up
as a form element. If you add a javascript to the bottom of the page
that shows the form elements (document.forms[0].var2.value), it doesn't
display.
Previous Comments:
[2002-03-13 17:01:18] [EMAIL PROTECTED]
Variables set using hidden form fields are not submitted with the form
when the INPUT tag appears AFTER an include statement.
For instance
?php
if (isset($var2)) {
echo('Var2 = '.$var2);
exit();
}
echo(form method='post' action='$PHP_SELF');
echo(input type='hidden' name='var1' value='foo');
include ('myfile.php');
echo(input type='hidden' name='var2' value='baz');
echo(input type='submit');
echo(/form);
?
...will not send $var2 on post. Same thing with GET. Var1 comes
through ok, though.
I've checked the script that is include-d. Var2 is not addressed.
Is this just me?
--
Edit this bug report at http://bugs.php.net/?id=16049edit=1
Bug #16049 Updated: Hidden Form fields do not POST/GET after include()
ID: 16049
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 4.1.2
New Comment:
double-check the html that is output by the include file. this almost
certainly has nothing to do with php.
Previous Comments:
[2002-03-13 17:04:03] [EMAIL PROTECTED]
Forgot to add something. The second variable (var2) won't even show up
as a form element. If you add a javascript to the bottom of the page
that shows the form elements (document.forms[0].var2.value), it doesn't
display.
[2002-03-13 17:01:18] [EMAIL PROTECTED]
Variables set using hidden form fields are not submitted with the form
when the INPUT tag appears AFTER an include statement.
For instance
?php
if (isset($var2)) {
echo('Var2 = '.$var2);
exit();
}
echo(form method='post' action='$PHP_SELF');
echo(input type='hidden' name='var1' value='foo');
include ('myfile.php');
echo(input type='hidden' name='var2' value='baz');
echo(input type='submit');
echo(/form);
?
...will not send $var2 on post. Same thing with GET. Var1 comes
through ok, though.
I've checked the script that is include-d. Var2 is not addressed.
Is this just me?
--
Edit this bug report at http://bugs.php.net/?id=16049edit=1
Bug #16046 Updated: isset empty parse error w/ objects
ID: 16046
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.1.2
New Comment:
From the manual (http://www.php.net/manual/en/function.empty.php):
Note that this is meaningless when used on anything which
isn't a variable; i.e. empty (addslashes ($name)) has no
meaning since it would be checking whether something which
isn't a variable is a variable with a FALSE value.
This not only explains the issue, it gives an example.
You're not using empty() on a variable in your example;
you're using it on an anonymous value (specifically, the
return value of a function).
Torben
Previous Comments:
[2002-03-13 16:56:00] [EMAIL PROTECTED]
Well, I did RTFM, quite a bit in fact. The result of the function call
*is* a plain variable, no? If not, your telling me that (from my
example) $foo-getStr() is not equal to the plain string foo? It's
just a string coming back from the call, and that should be accepted
into empty() just as if I'd typed a string in there to begin with.
Seems like the evaluation order is screwed up to me. In any case, if
this function is working as intended, a better FM might be in order
in this case.
[2002-03-13 15:53:21] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/function.empty.php
empty() only works with plain variables.
[2002-03-13 15:30:41] [EMAIL PROTECTED]
/*
See the script below. Passing a value returned from an object function
call to isset() and empty() results in a parsing error. strlen() and
other functions don't have this problem. The code example below tests
empty(). You may substitute isset() as well and get the same parse
error.
This bug exists on both Apache 1.3.9/PHP 4.1.1 and Apache 1.3.23/PHP
4.1.2
*/
//first, declare a simple class with 1 function
class Foo {
function getStr() { return foo; }
}
//now make an object of that class
$foo = new Foo();
/*
* now let's test empty() with just the string
* this should evaluate false, and result in not empty
* being printed
*/
$fooStr = $foo-getStr();
if ( empty($foostr) ) {
echo empty!;
} else {
echo not empty!;
}
/*
* now test it using the object function call. This is the
* functional equivalent of the previous test, and should
* result in the same result. However it results in:
* Parse error: parse error, expecting `')''
* If you comment out this block, this script parses and
* executes successfully.
*/
if ( empty($foo-getStr()) ) {
echo empty!;
} else {
echo not empty!;
}
--
Edit this bug report at http://bugs.php.net/?id=16046edit=1
Bug #16051: posix bug
From: [EMAIL PROTECTED]
Operating system: FreeBSD
PHP version: 4.1.2
PHP Bug Type: Scripting Engine problem
Bug description: posix bug
there is a problem in the file ext/posix/posix.c in function posix_uname,
if i read the documentation about this function i can get some
informations of the utsname struct. Well under linux you can use a machine
domain name, (not yet implemented in FreeBSD). well the 'domainname' are
not implemented on php but it's writed on the docs :
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
uname(u);
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
}
/* }}} */
i'v fix it :
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
uname(u);
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
#ifdef __USE_GNU
add_assoc_string(return_value, domainname, u.domainname, 1);
#endif
}
/* }}} */
if you don't want to correct it, please delete the wrong information in
the documentations.
Regards,
Vergoz Michael
SYSDOOR
--
Edit bug report at http://bugs.php.net/?id=16051edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16051r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16051r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16051r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16051r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16051r=support
Expected behavior: http://bugs.php.net/fix.php?id=16051r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16051r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16051r=submittedtwice
Bug #16049 Updated: Hidden Form fields do not POST/GET after include()
ID: 16049
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 4.1.2
New Comment:
The page outputs fine. The include file parses EXACTLY as it is
supposed toand code BELOW the form element also parses ok
(subsequent includes and other html elements). It's just the form
element that's affected.
Still searching
Previous Comments:
[2002-03-13 17:05:16] [EMAIL PROTECTED]
double-check the html that is output by the include file. this almost
certainly has nothing to do with php.
[2002-03-13 17:04:03] [EMAIL PROTECTED]
Forgot to add something. The second variable (var2) won't even show up
as a form element. If you add a javascript to the bottom of the page
that shows the form elements (document.forms[0].var2.value), it doesn't
display.
[2002-03-13 17:01:18] [EMAIL PROTECTED]
Variables set using hidden form fields are not submitted with the form
when the INPUT tag appears AFTER an include statement.
For instance
?php
if (isset($var2)) {
echo('Var2 = '.$var2);
exit();
}
echo(form method='post' action='$PHP_SELF');
echo(input type='hidden' name='var1' value='foo');
include ('myfile.php');
echo(input type='hidden' name='var2' value='baz');
echo(input type='submit');
echo(/form);
?
...will not send $var2 on post. Same thing with GET. Var1 comes
through ok, though.
I've checked the script that is include-d. Var2 is not addressed.
Is this just me?
--
Edit this bug report at http://bugs.php.net/?id=16049edit=1
Bug #16050 Updated: does not set name variable in input type=image name=do..
ID: 16050 Updated by: [EMAIL PROTECTED] -Summary: does not set name variable in input type=image name=do.. Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.1.2 New Comment: i meant to say does not set the variable $doit also, the button is located at a protected site, NOT at www.xxx.com (that links to a porn site, which was not the intention) Previous Comments: [2002-03-13 17:03:12] [EMAIL PROTECTED] the scripting engine does not set $doit when i submit input type=image name=do src=http://www.xxx.com/buttons/fund_off.jpg; sample code to test: ? if (isset($doit)) print yes; else print no; ? form name=form1 method=post action=./test.php input type=image name=doit src=http://www.xxx.com/buttons/fund_off.jpg; /form when i click on the image, i still get a no -- Edit this bug report at http://bugs.php.net/?id=16050edit=1
Bug #16050 Updated: does not set name variable in input type=image name=do..
ID: 16050 Updated by: [EMAIL PROTECTED] -Summary: does not set name variable in input type=image name=do.. Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.1.2 New Comment: not a bug really... see if $do_x and/or $do_y are set ($doit will certainly not be set, you're using 'do'). Derick Previous Comments: [2002-03-13 17:10:10] [EMAIL PROTECTED] i meant to say does not set the variable $doit also, the button is located at a protected site, NOT at www.xxx.com (that links to a porn site, which was not the intention) [2002-03-13 17:03:12] [EMAIL PROTECTED] the scripting engine does not set $doit when i submit input type=image name=do src=http://www.xxx.com/buttons/fund_off.jpg; sample code to test: ? if (isset($doit)) print yes; else print no; ? form name=form1 method=post action=./test.php input type=image name=doit src=http://www.xxx.com/buttons/fund_off.jpg; /form when i click on the image, i still get a no -- Edit this bug report at http://bugs.php.net/?id=16050edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
We MAY have seen a similar problem (not using Zend Optimizer, though --
whew!). We had problems with locutions like
function postprocess($buf)
{
$buf = preg_replace(/some stuff/,some other stuff,$buf);
return $buf;
}
ob_start(postprocess);
Changing the postprocess function to
function postprocess($ibuf)
{
$obuf = preg_replace(/some stuff/,some other stuff,$ibuf);
return $obuf;
}
seems to have eliminated the problem.
Previous Comments:
[2002-03-13 10:41:37] [EMAIL PROTECTED]
A question for [EMAIL PROTECTED] :
Did you try it before the patch was applied in 4.0.6
Of the pages giving me grief, some of them have forms and some of them
don't.
I don't have the access at my end to try my scripts on a different
linux version.
[2002-03-13 08:57:03] [EMAIL PROTECTED]
i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)
there were definetly problems in the past that
where RedHat-only :(
do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?
[2002-03-13 08:31:53] [EMAIL PROTECTED]
Which webserver and version do you use?
Derick
[2002-03-13 08:19:41] [EMAIL PROTECTED]
Further to my previous comment. I downgraded to 4.0.6 with the last
file upload patch and I am still getting the problem.
[2002-03-13 07:10:42] [EMAIL PROTECTED]
RH 7.2 / PHP 4.1.1 4.1.2 (tried both).
My one comment that may be useful is that I am only having this problem
on pages that include HTML forms and form elements. If I remove a few
form elements from a form it happily renders the page.
I have a few very simple pages that contain very little in the way of
PHP but keep getting truncated at certain points.
No segfault and no errors in the log files to correspond to the time of
the failure.
There doesn't seem to be a particular pattern or size issue. I've
tried other recommendations in this group but have not been able to get
any success.
There seems to be a size issue somewhere of some sort because I
stripped a page back a line at a time until it all rendered, and then
started adding in extra PHP until it started truncating again.
Please e-mail me if you would like the HTML/PHP pages that contain the
HTML forms. In the mean time I heading for PHP 4.0.6...
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/14529
--
Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #16048 Updated: fgets/feof failure when stdin is reading from a pipe
ID: 16048
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: Solaris 2.7 2.8
PHP Version: 4.1.2
New Comment:
I also tested this on Red Hat 7.2 with PHP 4.0.6 It works fine there.
Previous Comments:
[2002-03-13 17:00:20] [EMAIL PROTECTED]
The fgets() function works differently when the input is a pipe.
Specifically, feof() returns true after the first line is read. The
test script and sample output follow. The test script works fine if
stdin is redirected from a file. It fails if stdin is a pipe.
Nothing special about the build:
./configure --prefix=/usr/local --with-mysql
pjm@poseidon cat test.php
#!/usr/local/bin/php -q
?php
$fd = fopen(php://stdin, r);
while (! feof($fd))
{
$buffer = fgets($fd, 4096);
echo $buffer;
}
?
pjm@poseidon test.php ./test.php
#!/usr/local/bin/php -q
?php
$fd = fopen(php://stdin, r);
while (! feof($fd))
{
$buffer = fgets($fd, 4096);
echo $buffer;
}
?
pjm@poseidon cat test.php | ./test.php
#!/usr/local/bin/php -q
--
Edit this bug report at http://bugs.php.net/?id=16048edit=1
Bug #16052: Some predefined variables allow GET overwrite
From: [EMAIL PROTECTED]
Operating system: RH 7.2
PHP version: 4.1.2
PHP Bug Type: Apache related
Bug description: Some predefined variables allow GET overwrite
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test for
those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either of
those variables, rather than the value that should have been there from
Apache and/or PHP.
--
Edit bug report at http://bugs.php.net/?id=16052edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16052r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16052r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16052r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16052r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16052r=support
Expected behavior: http://bugs.php.net/fix.php?id=16052r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16052r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16052r=submittedtwice
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
read the manual on variables_order
Previous Comments:
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #9836 Updated: php unexpectedly ends on too long scripts
ID: 9836
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.1.0
New Comment:
I'm experiencing a similar problem on a server I use. When we upgraded
to apache 1.3.22 and php 4.1.x from 4.0.x, output sometimes(!) stops on
some pages. Not all pages, and not always! We have no idea what the
problem is, the output just stops. Any ideas?
Previous Comments:
[2002-03-05 09:44:36] [EMAIL PROTECTED]
okay. I think I described the problem well enough but I don't want
this bug closed just for 'lack of user feedback'. So do this:
create any long script. an easy (though somewhat slow) way to do this
is:
#!/bin/zsh
echo 'see this' | test.php
for i in {1..10}; do
echo '? echo ...and this\\n; ?' | test.php
done
now you put 'memory_limit = 5000' to your php.ini
run
$ php test.php
you'll get a lot of output
now change memory limit to smaller value, let's say 800.
$ php test.php
(failed with error code 1)
no warning given although 'error_reporting=E_ALL' in php.ini
[2002-03-02 21:59:17] [EMAIL PROTECTED]
Will you please provide a link to a website containing this sample
script?
Also will you share your php.ini file with us so we might debug this
further? What about your config line?
[2001-12-14 15:05:22] [EMAIL PROTECTED]
I've verified this problem when I was taking care of other bug report.
This is critical I think.
I'll look for duplicate later.
[2001-08-07 08:47:19] [EMAIL PROTECTED]
User feedback:
--
After further testing I found out it depends on memory limit.
But usually if you violate memory limit, you get a warning. The
warning
is probably not issued when parsing the script. (I am not sure about
it
as I didn't look at the sources).
---
User used the latest CVS snapshot.
--Jani
[2001-08-07 05:48:20] [EMAIL PROTECTED]
And now we have already released PHP 4.0.6. But could
you PLEASE try the latest CVS snapshot: http://snaps.php.net/
After you have tested your script with these and if
it still fails, provide the GDB backtrace I asked a long ago.
--Jani
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/9836
--
Edit this bug report at http://bugs.php.net/?id=9836edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
Previous Comments:
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #9836 Updated: php unexpectedly ends on too long scripts
ID: 9836
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.1.0
New Comment:
These two pages are great examples:
www.svenskamagic.com/index.php
www.svenskamagic.com/club_login.php
Reload the pages a couple of times and you'll notice the problem.
www.svenskamagic.com/phpinfo.php might be useful.
Previous Comments:
[2002-03-13 18:46:31] [EMAIL PROTECTED]
I'm experiencing a similar problem on a server I use. When we upgraded
to apache 1.3.22 and php 4.1.x from 4.0.x, output sometimes(!) stops on
some pages. Not all pages, and not always! We have no idea what the
problem is, the output just stops. Any ideas?
[2002-03-05 09:44:36] [EMAIL PROTECTED]
okay. I think I described the problem well enough but I don't want
this bug closed just for 'lack of user feedback'. So do this:
create any long script. an easy (though somewhat slow) way to do this
is:
#!/bin/zsh
echo 'see this' | test.php
for i in {1..10}; do
echo '? echo ...and this\\n; ?' | test.php
done
now you put 'memory_limit = 5000' to your php.ini
run
$ php test.php
you'll get a lot of output
now change memory limit to smaller value, let's say 800.
$ php test.php
(failed with error code 1)
no warning given although 'error_reporting=E_ALL' in php.ini
[2002-03-02 21:59:17] [EMAIL PROTECTED]
Will you please provide a link to a website containing this sample
script?
Also will you share your php.ini file with us so we might debug this
further? What about your config line?
[2001-12-14 15:05:22] [EMAIL PROTECTED]
I've verified this problem when I was taking care of other bug report.
This is critical I think.
I'll look for duplicate later.
[2001-08-07 08:47:19] [EMAIL PROTECTED]
User feedback:
--
After further testing I found out it depends on memory limit.
But usually if you violate memory limit, you get a warning. The
warning
is probably not issued when parsing the script. (I am not sure about
it
as I didn't look at the sources).
---
User used the latest CVS snapshot.
--Jani
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/9836
--
Edit this bug report at http://bugs.php.net/?id=9836edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
Incidentally, our variables_order flag is set to GPCS.
Previous Comments:
[2002-03-13 18:47:07] [EMAIL PROTECTED]
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #5516 Updated: $REMOTE_USER disappears when posting to a protected form
ID: 5516 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Misbehaving function Operating System: Linux PHP Version: 4.0 Latest CVS (11/07/2000) New Comment: Hi, even if I changed LIMIT get to LIMIT get post the bug still remained. I use PHP 4.0 Previous Comments: [2000-08-18 21:50:49] [EMAIL PROTECTED] Change this LIMIT get to LIMIT get post. --Jani [2000-07-27 21:55:20] [EMAIL PROTECTED] Have you tried a recent release? If so, does the problem still occur? [2000-07-11 15:18:18] [EMAIL PROTECTED] ?php print (remuser: $REMOTE_USERbrbr); ? form action=?php print($PHP_SELF); ? method=post input type=submit value='test' /form $REMOTE_USER is set the first time - but when posting - it's unset. -- Edit this bug report at http://bugs.php.net/?id=5516edit=1
Bug #16053: Unable to Load Dynamic Libraries
From: [EMAIL PROTECTED] Operating system: Windows 2000 Adv Server PHP version: 4.1.2 PHP Bug Type: Dynamic loading Bug description: Unable to Load Dynamic Libraries ok, i installed PHP4.1.2 in C:\PHP4. then i try to run the php.exe, or much less, my php scripts and i keep getting about 15 or 16 of these warning errors, PHP Warning: Unable to load dynamic library 'C:\PHP4/php_pgsql.dll' - The specified module could not be found. in Unknown on line 0 but, my dlls, are in PHP4\Extensions, so when i try to change that path in the php.ini. i get this message The dynamic link Library Libct.dll could not be found in the specified path C:\php4;.;C:\winnt\system32;C:\winnt\system;C:\winnt;C:\Program Files\InternetExplorer;;C:\winnt\system32;C:\winnt;C:\winnt\system32\wbem;C:\program files\micosoft SQL server\80\tools\binn. i get 4 of these messages missing LIBCT.dll, OCI.dll, OCIW32.dll, ISQIT09a.dll then after that i get an infinate number of these: PHP Warning: Function registration failed - duplicate name - pg_connect in Unkn own on line 0 please help, iv spent about 6 hours trying to figure this trash out. -- Edit bug report at http://bugs.php.net/?id=16053edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16053r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16053r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16053r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16053r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16053r=support Expected behavior: http://bugs.php.net/fix.php?id=16053r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16053r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16053r=submittedtwice
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
New Comment:
Have the same issue running the following config:
* Windows 2000 SP2
* Apache 1.3.23 for Windows
* PHP 4.1.2 Apache SAPI module
Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2,
sessions break. It appears possible to store session variables
INITIALLY using session_register(), but no updates to session variables
are ever stored in the session file.
Attempting to follow the PHP documentation and just use
$_SESSION--avoiding using session_register() altogether--does not work
at all. Attempting to create a session variable by doing something
like
?php
// Use $HTTP_SESSION_VARS with PHP 4.0.6 or less
if (!isset($_SESSION['count'])) {
$_SESSION['count'] = 0;
} else {
$_SESSION['count']++;
}
?
as written in the documentation fails miserably. (Note the
documentation neglects the session_start() call, which I added since I
did not have autostart enabled.)
BACKGROUND:
Here is how I swapped 4.1.2 into place to test this (what I do whenever
a new release comes out now):
* All Internet-related info is stored under \InetPub
(holdover from my IIS days)
* Apache is configured to look in \InetPub\PHP\SAPI for
the PHP4APACHE.DLL file. All appropriate settings in
HTTPD.CONF file set for running PHP as module (vs. CGI).
* When a new PHP version is released, I
1. Download the .ZIP file
2. Decompress into \InetPub (in this case creating
\InetPub\php-4.1.2-Win32\)
3. Copy PHP4TS.DLL into .\SAPI directory so it is in the
the same directory with PHP4APACHE.DLL.
4. Compare new PHP.INI-DIST and PHP.INI-RECOMMENDED
against my %SYSTEMROOT%\PHP.INI file, and make
adjustments accordingly (like the new cgi. entries).
5. Shutdown Apache service.
6. Rename '\InetPub\PHP' to '\InetPub\PHP v4.1.1'
7. Rename '\InetPub\php-4.1.2-Win32' to '\InetPub\PHP'
8. Restart Apache service.
9. Test the new config by running a VER.PHP file which
contains
?php
phpinfo();
?
10. Run various test scripts to validate sessions, etc.,
looking at the session files created to make sure
variables are created/updated/etc.
Testing an old version against a new version is then simple. I simply
1. Shutdown Apache service.
2. Rename '\InetPub\PHP' to '\InetPub\PHP_version_in_use'
3. Rename '\InetPub\PHP_version_to_test' to '\InetPub\PHP'
4. Restart Apache service.
and run the same tests.
With the introduction of PHP 4.1.0, I have started changing my PHP test
scripts to make use of $_SESSION. If you would like, I can provide a
set that may help show what's going on (or not going on in this case).
In a nutshell, currently PHP v4.1.2 is useless for session management,
at least the Apache for Windows SAPI module. Due to the various
security concerns with CGIs, etc., I am hesitant to go back to that.
If I find time to test the CGI version, I'll post here.
Previous Comments:
[2002-03-13 10:40:05] [EMAIL PROTECTED]
as title,
the global var. array $_SESSION can't use in PHP 4.1.2
(4.1.1/4.1.0 are OK)
P.S. I install PHP in Apache 1.3.23 modules
--
Edit this bug report at http://bugs.php.net/?id=16043edit=1
Bug #15959 Updated: config.status - empty case/esac statement
ID: 15959 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.4-STABLE PHP Version: 4.0CVS-2002-03-08 New Comment: This looks like the way to fix it: http://www.geocrawler.com/lists/3/GNU/402/0/7718080/ Previous Comments: [2002-03-08 13:00:25] [EMAIL PROTECTED] FreeBSD /bin/sh doesn't like empty case/esac statements. One such gets created in config.status:1472. I *think* I've seen a mail about empty case statements being patched in one of the GNU autotools, so this should probably be considered an auto* bug, but I can't for the life of me find where it was. svn-dev@ or freebsd-questions@ probably. -- Edit this bug report at http://bugs.php.net/?id=15959edit=1
Bug #15865 Updated: default PHP_INCLUDE_PATHset to c:\\php4\\pear
ID: 15865 Updated by: [EMAIL PROTECTED] -Summary: default PHP_INCLUDE_PATHset to c:\\php4\\pear Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: PHP options/info functions Operating System: Windows XP PHP Version: 4.1.2 New Comment: Fixed in CVS and fix will be in PHP 4.2.0. Previous Comments: [2002-03-04 21:19:14] [EMAIL PROTECTED] in the file php-4.1.2/main/config.w32.h there is the following definition : #define PHP_INCLUDE_PATHc:\\php4\\pear in the php-4.1.1 tree it was : #define PHP_INCLUDE_PATHNULL sometimes this causes the include() function not to work, complaining that it didnt find the included file in C:\php4\pear. I reverted back to NULL an the errors are gone. ciao, Enrico -- Edit this bug report at http://bugs.php.net/?id=15865edit=1
Bug #15369 Updated: Warning: Failed opening '/home/include/phpweb' for inclusion (include_path='.:.
ID: 15369 Updated by: [EMAIL PROTECTED] -Summary: Warning: Failed opening '/home/include/phpweb' for inclusion (include_path='.:. Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: win PHP Version: 4.1.1 New Comment: In windows systems, the path separator is ; (not :) Previous Comments: [2002-02-04 11:27:28] [EMAIL PROTECTED] can we possibly get some information that might make this bug seem slighlty less of a joke? [2002-02-04 11:23:52] [EMAIL PROTECTED] true [2002-02-04 11:23:27] [EMAIL PROTECTED] right [2002-02-04 11:22:42] [EMAIL PROTECTED] Warning: Failed opening '/home/include/phpweb' for inclusion (include_path='.:./include:../include:../../include') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=15369edit=1
Bug #16054: ldap ./configure error cannot open library
From: [EMAIL PROTECTED] Operating system: aix 4.3.3 PHP version: 4.1.2 PHP Bug Type: *Compile Issues Bug description: ldap ./configure error cannot open library gcc -o conftest -g -O2 -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT -L/webserver/ download/ldapsdk/lib -L/webserver/download/ldapsdk/lib conftest.c -lldapssl41 -lplds3 -lplc3 -lnspr3 -lcrypt -lbind -lm -ldl -lcrypt 15 ld: 0706-006 Cannot find or open library file: -l ldapssl41 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plds3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plc3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l nspr3 ld:open(): No such file or directory collect2: ld returned 255 exit status -- Edit bug report at http://bugs.php.net/?id=16054edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16054r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16054r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16054r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16054r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16054r=support Expected behavior: http://bugs.php.net/fix.php?id=16054r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16054r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16054r=submittedtwice
Bug #16051 Updated: posix bug
ID: 16051
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: FreeBSD
PHP Version: 4.1.2
New Comment:
Has been fixes in CVS already and will be in 4.2.0
Previous Comments:
[2002-03-13 17:06:46] [EMAIL PROTECTED]
there is a problem in the file ext/posix/posix.c in function
posix_uname, if i read the documentation about this function i can get
some informations of the utsname struct. Well under linux you can use a
machine domain name, (not yet implemented in FreeBSD). well the
'domainname' are not implemented on php but it's writed on the docs :
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
uname(u);
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
}
/* }}} */
i'v fix it :
/* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
PHP_FUNCTION(posix_uname)
{
struct utsname u;
uname(u);
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
add_assoc_string(return_value, sysname, u.sysname, 1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release, u.release, 1);
add_assoc_string(return_value, version, u.version, 1);
add_assoc_string(return_value, machine, u.machine, 1);
#ifdef __USE_GNU
add_assoc_string(return_value, domainname, u.domainname, 1);
#endif
}
/* }}} */
if you don't want to correct it, please delete the wrong information in
the documentations.
Regards,
Vergoz Michael
SYSDOOR
--
Edit this bug report at http://bugs.php.net/?id=16051edit=1
Bug #15959 Updated: config.status - empty case/esac statement
ID: 15959 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.4-STABLE PHP Version: 4.0CVS-2002-03-08 New Comment: Well, I just tried the patch listed in that mailing list. It fixes the problem with AC_CONFIG_COMMANDS as advertised. Unfortunately PHP is still producing empty case/esac statements in ./configure. It would be great if someone more familiar with auto* could find out what rule is causing this. php: 4.0CVS2002-03-13 autoconf: 2.53 freebsd: 4.5-STABLE Previous Comments: [2002-03-13 20:36:42] [EMAIL PROTECTED] This looks like the way to fix it: http://www.geocrawler.com/lists/3/GNU/402/0/7718080/ [2002-03-08 13:00:25] [EMAIL PROTECTED] FreeBSD /bin/sh doesn't like empty case/esac statements. One such gets created in config.status:1472. I *think* I've seen a mail about empty case statements being patched in one of the GNU autotools, so this should probably be considered an auto* bug, but I can't for the life of me find where it was. svn-dev@ or freebsd-questions@ probably. -- Edit this bug report at http://bugs.php.net/?id=15959edit=1
Bug #16055: Running 4.1.2 as module in Apache 1.3.2 crashes Apache.exe
From: [EMAIL PROTECTED] Operating system: Windows XP Pro PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: Running 4.1.2 as module in Apache 1.3.2 crashes Apache.exe This has been a problem in 4.1.0 and 4.1.2. A simple ?php session_start(); ? will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module -- Edit bug report at http://bugs.php.net/?id=16055edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16055r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16055r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16055r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16055r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16055r=support Expected behavior: http://bugs.php.net/fix.php?id=16055r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16055r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16055r=submittedtwice
Bug #16055 Updated: Running 4.1.2 as module in Apache 1.3.2 crashes Apache.exe
ID: 16055 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Reproducible crash +Bug Type: Session related Operating System: Windows XP Pro PHP Version: 4.1.2 New Comment: This has been a problem in 4.1.0 and 4.1.2. A simple ?php session_start(); ? will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module Previous Comments: [2002-03-13 22:28:31] [EMAIL PROTECTED] This has been a problem in 4.1.0 and 4.1.2. A simple ?php session_start(); ? will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module -- Edit this bug report at http://bugs.php.net/?id=16055edit=1
Bug #15062 Updated: apache crash in php4ts.dll
ID: 15062
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Reproducible crash
Operating System: Windows 2000 + Apache
PHP Version: 4.1.1
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
Previous Comments:
[2002-01-16 07:19:56] [EMAIL PROTECTED]
Are you sure this isn't a dupe of #14453???
Anyway, can you simplify the script and make it self-contained?
[2002-01-15 20:12:42] [EMAIL PROTECTED]
i am running latest stable 1.3 apache on my windows 2000 machine
here.
When i execute the following code (both $f_user and $f_pass are
populated)
?php
require_once(global.php);
if (isset ($f_user) isset ($f_pass)) {
/* so the user [form] needs to be logged in... */
$sql = SELECT * FROM login WHERE user = ' . addslashes($f_user) .
';
$userchk = db_connect($sql, Y);
if ( isset($userchk) ($userchk != )) {
if ( $userchk-pass = $f_pass ) {
$icauser = true;
session_register(icauser);
}
}
}
?
it causes apache.exe to crash.
when restarting the service, i get the following message 3 times:
titlebar: apache.exe Entry Point Not Found
message: The procedure entry point wrong_param_count could not be
located in the dynamic link library php4ts.dll.
I will get/give more info as requested.
--
Edit this bug report at http://bugs.php.net/?id=15062edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
are you sure? HTTP_* variables are environment variables. the
variables_order is normally set to EGCPS (if not, change it) where S
is not Server Variables but SESSION Variables. this behaviour thus
looks intentional - first HTTP_ACCEPT_CHARSET is set by the
environment, then you overwrite it with a GET.
Previous Comments:
[2002-03-13 18:56:56] [EMAIL PROTECTED]
Incidentally, our variables_order flag is set to GPCS.
[2002-03-13 18:47:07] [EMAIL PROTECTED]
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: RH 7.2
PHP Version: 4.1.2
New Comment:
sorry, it's EGPCS by default.
Previous Comments:
[2002-03-14 02:08:47] [EMAIL PROTECTED]
are you sure? HTTP_* variables are environment variables. the
variables_order is normally set to EGCPS (if not, change it) where S
is not Server Variables but SESSION Variables. this behaviour thus
looks intentional - first HTTP_ACCEPT_CHARSET is set by the
environment, then you overwrite it with a GET.
[2002-03-13 18:56:56] [EMAIL PROTECTED]
Incidentally, our variables_order flag is set to GPCS.
[2002-03-13 18:47:07] [EMAIL PROTECTED]
Been there, done that. So, why don't any of the other variables from
purportedly the same source (s/b S, yes?) change when I request this
on the command line? The point is that either (a) the docs are broken
here and the two variables in question aren't from the server, or (b)
the EGPCS processing is broken, take your pick.
[2002-03-13 18:27:06] [EMAIL PROTECTED]
read the manual on variables_order
[2002-03-13 17:52:15] [EMAIL PROTECTED]
It is possible to overwrite some predefined variables using GET URI
variables (also, I would imagine, POST vars, but it's harder to test
for those). Consider the following as foo.php:
?
$varlist = array('DOCUMENT_ROOT',
'GATEWAY_INTERFACE',
'HTTP_ACCEPT',
'HTTP_ACCEPT_CHARSET',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CONNECTION',
'HTTP_COOKIE_VARS',
'HTTP_ENV_VARS',
'HTTP_GET_VARS',
'HTTP_HOST',
'HTTP_POST_FILES',
'HTTP_POST_VARS',
'HTTP_REFERER',
'HTTP_SERVER_VARS',
'HTTP_USER_AGENT',
'PATH_TRANSLATED',
'PHP_SELF',
'QUERY_STRING',
'REMOTE_ADDR',
'REMOTE_PORT',
'REQUEST_METHOD',
'REQUEST_URI',
'SCRIPT_FILENAME',
'SERVER_ADMIN',
'SERVER_NAME',
'SERVER_PORT',
'SERVER_PROTOCOL',
'SERVER_SIGNATURE',
'SERVER_SOFTWARE');
foreach ($varlist as $i)
print $i = '.${$i}.'br\n;
?
=
If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or
http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get blarg for either
of those variables, rather than the value that should have been there
from Apache and/or PHP.
--
Edit this bug report at http://bugs.php.net/?id=16052edit=1
Bug #16056: Please use reception of *any* cookie to signal PHP that cookies are enabled
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: Please use reception of *any* cookie to signal PHP that cookies are enabled This is just a simple request. When you visit a PHP site using sessions, on the first page view the PHPSESSID appears in all URLs, because at that point PHP supposedly does not know whether cookies are enabled. However, if the site had, on an earlier visit, set a long-term cookie (with some dummy value), then now on my first page-view of a session, the PHP site should be able to know that cookies are enabled, since this one long-term cookie would have been sent. Currently, PHP doesn't allow this -- it only checks for the PHPSESSID cookie. I think it would be an easy change, and make many people happy, to simply have it check whether any cookie was received by the server, and if so then take that as a sign that cookies are enabled and thus don't modify the links on the page. Perhaps this could be an option in the php.ini if you were worried it is not safe enough. Thanks for your time, Matt -- Edit bug report at http://bugs.php.net/?id=16056edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16056r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16056r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16056r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16056r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16056r=support Expected behavior: http://bugs.php.net/fix.php?id=16056r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16056r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16056r=submittedtwice
Bug #16056 Updated: Please use reception of *any* cookie to signal PHP that cookies are enabled
ID: 16056 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: fixed my email address. Previous Comments: [2002-03-14 02:14:02] [EMAIL PROTECTED] This is just a simple request. When you visit a PHP site using sessions, on the first page view the PHPSESSID appears in all URLs, because at that point PHP supposedly does not know whether cookies are enabled. However, if the site had, on an earlier visit, set a long-term cookie (with some dummy value), then now on my first page-view of a session, the PHP site should be able to know that cookies are enabled, since this one long-term cookie would have been sent. Currently, PHP doesn't allow this -- it only checks for the PHPSESSID cookie. I think it would be an easy change, and make many people happy, to simply have it check whether any cookie was received by the server, and if so then take that as a sign that cookies are enabled and thus don't modify the links on the page. Perhaps this could be an option in the php.ini if you were worried it is not safe enough. Thanks for your time, Matt -- Edit this bug report at http://bugs.php.net/?id=16056edit=1
