#21424 [NEW]: Terminal type=vt100 on a new build
From: [EMAIL PROTECTED] Operating system: RedHat 7.3 PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: Terminal type=vt100 on a new build I have a machine with apache 1.3.26 and php 4.1.2 and the term type reports "dumb". I downloaded apache 1.3.27 source and php 4.3.0 source (as well as support sources - ssl, imap, perl, etc). Compiled and ran just fine. The problem is that for some reason the phpinfo is reporting that the term type is VT100 and pulling some extra environmental variables as well. These variables are not present on the other box. I compiled php without apache support first (so I could possible run local scripts) then did a make clean and finally configured it will apache support. Here is the compile script. make clean > /dev/null ./configure --with-mysql=/usr/local/mysql --with-xml --enable-ftp make make test make install make clean > /dev/null ./configure --with-apache=../apache_1.3.27 --with-imap=../imap-2001a --with-gettext --enable-track-vars --with-mysql=/usr/local/mysql --with-xml --enable-ftp make make install Everything besides the terminal type and the extra environmental variables seem to be working fine. The biggest noticable problem is the environmental variable LS_COLORS which mangles the tables. Though this isn't a show stopper it just pointed out to me that something was different and I wasn't sure if this different shell is a security issue or could pose other runtime problems. -- Edit bug report at http://bugs.php.net/?id=21424&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21424&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21424&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21424&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21424&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21424&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21424&r=support Expected behavior: http://bugs.php.net/fix.php?id=21424&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21424&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21424&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21424&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21424&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21424&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21424&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21424&r=gnused
#21443 [Com]: get_browser still has problems with browsecap.ini from www.garykeith.com
ID: 21443 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 New Comment: Ilia, I am the developer of the browscap.ini file that PHP recommends to its users. Respectfully, this issue does appear to be a bug in PHP. The user agent in question, Mozilla/4.8 [en] (Windows NT 5.0; U), is in my browscap.ini file and it is recognized when Serge visits my website which uses IIS. To me that suggests a bug in get_browser(). I am suspicious that in certain situations get_browser() has a problem dealing with multiple question marks in a user agent. In an attempt to prove my theory I changed the definition for the user agent in question and asked Serge to see if it works. I'll report back here on his results. Previous Comments: [2003-01-05 15:41:02] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Contact the developer mantaining the browsecap.ini, this is not a PHP bug. [2003-01-05 15:29:07] [EMAIL PROTECTED] PHP does not detect Netscape for Windows ua: Mozilla/4.8 [en] (Windows NT 5.0; U) It did detect Mozilla 1.2 and IE 6 for Windows and Mozilla 1.1 and Netscape 4.7 in Linux. The latest verion (downloaded January 5 2003) of browsecap.ini was used. -- Edit this bug report at http://bugs.php.net/?id=21443&edit=1
#21443 [Com]: get_browser still has problems with browsecap.ini from www.garykeith.com
ID: 21443 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 New Comment: Thanks, Serge. Ilia, I think this is fairly solid proof that my suspicions are correct about get_browser() having a problem dealing with multiple question marks in the user agent. The old definition in my browscap.ini file: Mozilla/4.8 (Windows NT 5.0; U) fails while the updated definition: Mozilla/4.8*(Windows NT 5.0; U) works fine. Both definitions work fine with browscap.dll therefore I suspect a problem with get_browser(). Previous Comments: [2003-01-05 22:25:51] [EMAIL PROTECTED] I updated the browscap.ini and the detection works fine now with Netscape for windows: ua: Mozilla/4.8 [en] (Windows NT 5.0; U) pattern match: browser_name_pattern Mozilla/4\.8.*(Windows NT 5\.0; U) [2003-01-05 21:49:27] [EMAIL PROTECTED] Ilia, I am the developer of the browscap.ini file that PHP recommends to its users. Respectfully, this issue does appear to be a bug in PHP. The user agent in question, Mozilla/4.8 [en] (Windows NT 5.0; U), is in my browscap.ini file and it is recognized when Serge visits my website which uses IIS. To me that suggests a bug in get_browser(). I am suspicious that in certain situations get_browser() has a problem dealing with multiple question marks in a user agent. In an attempt to prove my theory I changed the definition for the user agent in question and asked Serge to see if it works. I'll report back here on his results. [2003-01-05 15:41:02] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Contact the developer mantaining the browsecap.ini, this is not a PHP bug. [2003-01-05 15:29:07] [EMAIL PROTECTED] PHP does not detect Netscape for Windows ua: Mozilla/4.8 [en] (Windows NT 5.0; U) It did detect Mozilla 1.2 and IE 6 for Windows and Mozilla 1.1 and Netscape 4.7 in Linux. The latest verion (downloaded January 5 2003) of browsecap.ini was used. -- Edit this bug report at http://bugs.php.net/?id=21443&edit=1
#21468 [NEW]: get_browser() still has bugs
From: [EMAIL PROTECTED] Operating system: Various PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: get_browser() still has bugs I am the developer who maintains the browscap.ini file that is recommended by PHP. Despite some recent bug fixes there still seems to be at least one bug in the get_browser() function. Simply put, multiple question marks surrounded by white space in a user agent definition in browscap.ini creates some sort of error that results in a valid user agent not being recognized by get_browser(). Here's a more detailed example of what I mean. user agent: Mozilla/4.8 [en] (Windows NT 5.0; U) original browscap.ini definition: Mozilla/4.8 (Windows NT 5.0; U) updated browscap.ini definition: Mozilla/4.8*(Windows NT 5.0; U) The original definition resulted in the user agent not being found and the Default browser being returned. The updated definition works fine. This forms the basis of my theory about multiple question marks surrounded by white space. By the way, both definitions are valid and both work just fine on other platforms such as ASP. With the help of a fellow developer we did some further testing to confirm my theory. The following user agent definitions did not result in a match when presented with a user agent that should have created a match: Mozilla/4.76C-CCK-MCD (X11; ?; SunOS 5.? sun4u) Mozilla/4.76C-CCK-MCD vg_472 (X11; ?; SunOS 5.8 sun4u) Mozilla/4.76C-SGI (X11; ?; IRIX64 6.5 IP30) Mozilla/4.79C-CCK-MCD (X11; ?; SunOS 5.6 sun4u) But these did result in matches: Mozilla/4.79 *(Win95; ?) Mozilla/4.78 (Windows 2000; U) Opera 6.05 Mozilla/5.0 (BeOS; ?; BeOS BePC; ?; rv:1.0.?) Gecko/ This seems to suggest a problem only when multiple question marks are surrounded on both sides by white space. I hope this is enough information for someone to attempt a fix. -- Edit bug report at http://bugs.php.net/?id=21468&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21468&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21468&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21468&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21468&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21468&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21468&r=support Expected behavior: http://bugs.php.net/fix.php?id=21468&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21468&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21468&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21468&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21468&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21468&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21468&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21468&r=gnused
Bug #15601: Mail Function not working
From: [EMAIL PROTECTED] Operating system: Mac OS X PHP version: 4.0.6 PHP Bug Type: Mail related Bug description: Mail Function not working Is there a known problem running the Mail function on Mac OS X? My syslog reports the following message. Feb 18 17:03:53 localhost sendmail[350]: My unqualified host name (localhost) unknown; sleeping for retry Feb 18 17:04:53 localhost sendmail[350]: unable to qualify my own domain name (localhost) -- using short name Feb 18 17:04:53 localhost sendmail[350]: NOQUEUE: SYSERR(www): /etc/mail/sendmail.cf: line 81: fileclass: cannot open /etc/mail/local-host-names: Group writable directory -- Edit bug report at http://bugs.php.net/?id=15601&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15601&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15601&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15601&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15601&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15601&r=support Expected behavior: http://bugs.php.net/fix.php?id=15601&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15601&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15601&r=submittedtwice
Bug #15601 Updated: Mail Function not working
ID: 15601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Mail related -Operating System: Mac OS X +Operating System: Mac OS X 10.1 PHP Version: 4.0.6 Previous Comments: [2002-02-18 12:11:49] [EMAIL PROTECTED] Is there a known problem running the Mail function on Mac OS X? My syslog reports the following message. Feb 18 17:03:53 localhost sendmail[350]: My unqualified host name (localhost) unknown; sleeping for retry Feb 18 17:04:53 localhost sendmail[350]: unable to qualify my own domain name (localhost) -- using short name Feb 18 17:04:53 localhost sendmail[350]: NOQUEUE: SYSERR(www): /etc/mail/sendmail.cf: line 81: fileclass: cannot open /etc/mail/local-host-names: Group writable directory -- Edit this bug report at http://bugs.php.net/?id=15601&edit=1
Bug #15601 Updated: Mail Function not working
ID: 15601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Mail related Operating System: Mac OS X 10.1 PHP Version: 4.0.6 New Comment: Don't work I have found a workaround solution. Previous Comments: [2002-02-18 12:11:49] [EMAIL PROTECTED] Is there a known problem running the Mail function on Mac OS X? My syslog reports the following message. Feb 18 17:03:53 localhost sendmail[350]: My unqualified host name (localhost) unknown; sleeping for retry Feb 18 17:04:53 localhost sendmail[350]: unable to qualify my own domain name (localhost) -- using short name Feb 18 17:04:53 localhost sendmail[350]: NOQUEUE: SYSERR(www): /etc/mail/sendmail.cf: line 81: fileclass: cannot open /etc/mail/local-host-names: Group writable directory -- Edit this bug report at http://bugs.php.net/?id=15601&edit=1
Bug #15601 Updated: Mail Function not working
ID: 15601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Mail related Operating System: Mac OS X 10.1 PHP Version: 4.0.6 Previous Comments: [2002-02-19 11:19:12] [EMAIL PROTECTED] Don't work I have found a workaround solution. [2002-02-18 12:11:49] [EMAIL PROTECTED] Is there a known problem running the Mail function on Mac OS X? My syslog reports the following message. Feb 18 17:03:53 localhost sendmail[350]: My unqualified host name (localhost) unknown; sleeping for retry Feb 18 17:04:53 localhost sendmail[350]: unable to qualify my own domain name (localhost) -- using short name Feb 18 17:04:53 localhost sendmail[350]: NOQUEUE: SYSERR(www): /etc/mail/sendmail.cf: line 81: fileclass: cannot open /etc/mail/local-host-names: Group writable directory -- Edit this bug report at http://bugs.php.net/?id=15601&edit=1
#23354 [Com]: Use of variable before registration problem
ID: 23354
Comment by: gary at akos dot net
Reported By: bill dot macallister at prideindustries dot com
Status: Closed
Bug Type: Session related
Operating System: Linux 2.4.18-27.7.xsmp
PHP Version: 4-STABLE-200304281330
New Comment:
This problem still exists in the release
version of 4.3.2 put up recently. I cant
test without register_globals on but it
seeems that *not* using session_register(),
(ie working directly with $_SESSION) will
cause desync of the $_SESSION object. I am
using only the stock php session handler.
Previous Comments:
[2003-05-28 15:48:35] downsize at edwardsconsultants dot com
I have been able to reproduce a SESSION (I believe to be the same bug)
error with the following test case:
using a GET request (example: $_GET['some_name'], setup any variable
assigning it some value (I tested string, array, and int) then
serialize the variables into the SESSION. Submit a form and I loose
the Session vars. sample code:
if(isset($_GET['some_var'])){
//..validate some_var
//..I used it to query a db and now I have some data
$some_data = "test";
$data_array = array("some_data" => $some_data);
$test_int = 6510864;
$_SESSION['test1'] = serialize($some_data);
$_SESSION['test2'] = serialize($data_array);
$_SESSION['test3'] = $test_int; //no serialize necessary
echo '
';
}
if you were to use that code with phpv4.3.1 in a page that you arrived
at from a GET request, then submit a POST to another page, var_dump the
$_SESSION to find it empty.
I changed my GET request to POST (not what I wanted to do since I have
to setup a form with buttons as opposed to href's) and I successfully
retain my SESSION vars.
In both cases I use the variable *before* I register it.
later,
downsize
[2003-05-23 11:23:24] bill dot macallister at prideindustries dot com
While the test case that caused this failure was solved with RC4 we are
stilling seeing an intermittent problem with session information
disappearing. Unfortunately we cannot reproduce the problem at will
and see it once or twice is several hundred accesses to this
application. We are working on getting more details, but at this point
that looks like a slow process. I just wanted to let you know in case
you notice something that might be causing this.
Thanks again for you efforts,
Bill
[2003-05-18 11:50:28] [EMAIL PROTECTED]
Fix will be in PHP 4.3.2.
[2003-05-17 17:40:06] bill dot macallister at prideindustries dot com
Looks like that fixed the problem. Initial tests are good.
Thanks a lot,
Bill
[2003-05-15 13:19:28] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
This might be fixed now.
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/23354
--
Edit this bug report at http://bugs.php.net/?id=23354&edit=1
#25529 [NEW]: Segmentation fault
From: gary at isohunt dot com Operating system: Redhat 8.0 PHP version: 4.3.3 PHP Bug Type: Compile Failure Bug description: Segmentation fault Description: /usr/local/src/php-4.3.3/ext/standard/sha1.c:371: internal error: Segmentation fault Last lines of output during make pasted below in Actual results This is on Redhat 8.0 with gcc 3.2. I'm trying to compile PHP as a module in Apache 2.0.47 Actual result: -- /bin/sh /usr/local/src/php-4.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/usr/local/src/php-4.3.3/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src/php-4.3.3/include -I/usr/local/src/php-4.3.3/main -I/usr/local/src/php-4.3.3 -I/usr/local/src/php-4.3.3/Zend -I/usr/local/src/php-4.3.3/ext/xml/expat -I/usr/local/src/php-4.3.3/TSRM -g -O2 -prefer-pic -c /usr/local/src/php-4.3.3/ext/standard/sha1.c -o ext/standard/sha1.lo /usr/local/src/php-4.3.3/ext/standard/sha1.c: In function `SHA1Transform': /usr/local/src/php-4.3.3/ext/standard/sha1.c:371: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla/> for instructions. make: *** [ext/standard/sha1.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=25529&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25529&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25529&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25529&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25529&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25529&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25529&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25529&r=support Expected behavior: http://bugs.php.net/fix.php?id=25529&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25529&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25529&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25529&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25529&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25529&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25529&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25529&r=gnused
#25529 [Bgs->Csd]: ext/standard/sha1.c:371: internal error: Segmentation fault
ID: 25529 User updated by: gary at isohunt dot com Reported By: gary at isohunt dot com -Status: Bogus +Status: Closed Bug Type: Compile Failure Operating System: Redhat 8.0 PHP Version: 4.3.3 New Comment: Compiled 3 times didn't work, but doing a ./configure and make again worked.. Previous Comments: [2003-09-14 03:12:47] [EMAIL PROTECTED] If GCC crashes, it's definately not any PHP bug. (Compiles fine with GCC 2.95.3 for example) [2003-09-13 22:26:42] gary at isohunt dot com Description: /usr/local/src/php-4.3.3/ext/standard/sha1.c:371: internal error: Segmentation fault Last lines of output during make pasted below in Actual results This is on Redhat 8.0 with gcc 3.2. I'm trying to compile PHP as a module in Apache 2.0.47 Actual result: -- /bin/sh /usr/local/src/php-4.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/usr/local/src/php-4.3.3/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src/php-4.3.3/include -I/usr/local/src/php-4.3.3/main -I/usr/local/src/php-4.3.3 -I/usr/local/src/php-4.3.3/Zend -I/usr/local/src/php-4.3.3/ext/xml/expat -I/usr/local/src/php-4.3.3/TSRM -g -O2 -prefer-pic -c /usr/local/src/php-4.3.3/ext/standard/sha1.c -o ext/standard/sha1.lo /usr/local/src/php-4.3.3/ext/standard/sha1.c: In function `SHA1Transform': /usr/local/src/php-4.3.3/ext/standard/sha1.c:371: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla/> for instructions. make: *** [ext/standard/sha1.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=25529&edit=1
#25529 [Bgs]: ext/standard/sha1.c:371: internal error: Segmentation fault
ID: 25529 User updated by: gary at isohunt dot com Reported By: gary at isohunt dot com Status: Bogus Bug Type: Compile Failure Operating System: Redhat 8.0 PHP Version: 4.3.3 New Comment: Sorry for asking in the wrong place. But I didn't know what was causing the seg fault, PHP, GCC or a combo. I works now, but the way it sometimes compile and sometimes doesn't on the same system without rebooting is still strange. Previous Comments: [2003-09-14 07:14:54] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Still not our problem [2003-09-14 07:09:22] gary at isohunt dot com Compiled 3 times didn't work, but doing a ./configure and make again worked.. [2003-09-14 03:12:47] [EMAIL PROTECTED] If GCC crashes, it's definately not any PHP bug. (Compiles fine with GCC 2.95.3 for example) [2003-09-13 22:26:42] gary at isohunt dot com Description: /usr/local/src/php-4.3.3/ext/standard/sha1.c:371: internal error: Segmentation fault Last lines of output during make pasted below in Actual results This is on Redhat 8.0 with gcc 3.2. I'm trying to compile PHP as a module in Apache 2.0.47 Actual result: -- /bin/sh /usr/local/src/php-4.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/usr/local/src/php-4.3.3/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src/php-4.3.3/include -I/usr/local/src/php-4.3.3/main -I/usr/local/src/php-4.3.3 -I/usr/local/src/php-4.3.3/Zend -I/usr/local/src/php-4.3.3/ext/xml/expat -I/usr/local/src/php-4.3.3/TSRM -g -O2 -prefer-pic -c /usr/local/src/php-4.3.3/ext/standard/sha1.c -o ext/standard/sha1.lo /usr/local/src/php-4.3.3/ext/standard/sha1.c: In function `SHA1Transform': /usr/local/src/php-4.3.3/ext/standard/sha1.c:371: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla/> for instructions. make: *** [ext/standard/sha1.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=25529&edit=1
#27465 [NEW]: using ereg and odbc in a script causes odbc driver error message
From: gary at koning dot com
Operating system: win2k
PHP version: 4.3.4
PHP Bug Type: ODBC related
Bug description: using ereg and odbc in a script causes odbc driver error message
Description:
I am converting an application to win2k/mssql from linux/mysql. Using ereg
to validate form field data.
Getting unuasual error message from the win2k odbc driver.
Reproduce code:
---
Validation code:
if( !ereg("^([EMAIL PROTECTED],18})$",$stmp) )
Using odbc_do(), almost any simple query returning rows
will result in the driver throwing an error message
like:
"Error converting data type varchar to numeric"
I say almost because sometimes a row of data was returned.
But even then, reloading the script would give the above error.
Expected result:
Valid data from the odbc driver or a known error message.
Actual result:
--
Removing the call to ereg() will cause the query to return proper data.
No further info at this time. (Took me 2 days to track this down). I
beleive an old copy of active perl is installed on this box, if that has
any bearing.
--
Edit bug report at http://bugs.php.net/?id=27465&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27465&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27465&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27465&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27465&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27465&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27465&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27465&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27465&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27465&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27465&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27465&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27465&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27465&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27465&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27465&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27465&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27465&r=float
#27465 [Fbk->Bgs]: using ereg and odbc in a script causes odbc driver error message
ID: 27465
User updated by: gary at koning dot com
Reported By: gary at koning dot com
-Status: Feedback
+Status: Bogus
Bug Type: ODBC related
Operating System: win2k
PHP Version: 4.3.4
New Comment:
after more testing, ereg() does not seem to be the problem
Previous Comments:
[2004-03-02 13:35:40] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-03-02 13:31:55] gary at koning dot com
Description:
I am converting an application to win2k/mssql from linux/mysql. Using
ereg to validate form field data.
Getting unuasual error message from the win2k odbc driver.
Reproduce code:
---
Validation code:
if( !ereg("^([EMAIL PROTECTED],18})$",$stmp) )
Using odbc_do(), almost any simple query returning rows
will result in the driver throwing an error message
like:
"Error converting data type varchar to numeric"
I say almost because sometimes a row of data was returned.
But even then, reloading the script would give the above error.
Expected result:
Valid data from the odbc driver or a known error message.
Actual result:
--
Removing the call to ereg() will cause the query to return proper
data.
No further info at this time. (Took me 2 days to track this down). I
beleive an old copy of active perl is installed on this box, if that
has any bearing.
--
Edit this bug report at http://bugs.php.net/?id=27465&edit=1
#29462 [NEW]: lost post data
From: gary at garyslittlecompany dot com Operating system: wxp PHP version: 4.3.9 PHP Bug Type: CGI related Bug description: lost post data Description: Please see my last note to bug #22427. I am experiencing the same problem, I would not submit this again, except, it appears that I can not change the status to open again, since I am not the owner, so I added this to one to point to that. -- Edit bug report at http://bugs.php.net/?id=29462&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29462&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29462&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29462&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29462&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29462&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29462&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29462&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29462&r=support Expected behavior: http://bugs.php.net/fix.php?id=29462&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29462&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29462&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29462&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29462&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29462&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29462&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29462&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29462&r=float
#22427 [Com]: Missing Form Post Data
ID: 22427
Comment by: gary at garyslittlecompany dot com
Reported By: jroland at uow dot edu dot au
Status: No Feedback
Bug Type: *General Issues
Operating System: Windows XP / 2000
PHP Version: 4.2.3
New Comment:
I too am experiencing what has been described in the this submission.
I think I have isolated it to php on windows. I summarize it thus
because I have an xp, w2k3 and wme servers that experience the same
problem.
Yes I have used the latest version as of today 4.3.9 build date
7/30/04.
I have scripts that have alot of post data, a table full of input
objects, the table can be quite large. If I exceed a certain amount (I
know it is not an arbitrary size, but I don't know what the size is, but
I can duplicate it). Below are my scripts.
';
for ($l = 0; $l < 100; ++$l)
{
print "First Name\r\n";
print "Last Name\r\n";
print "City\r\n";
print "State\r\n";
}
print '';
?>
This simply provides my form with a lot of input elements in my html.
When submitted it will call the following script
";
print_r($_POST);
?>
Here is the output
6559
Array ( )
Now if I change my script (action = "cgi-bin\post.ext") to call the
following c compiled script...
#include
#include
#include
main()
{
char *endptr;
int i;
double contentlength;
char buff[1];
char a,b;
const char *len1 = getenv("CONTENT_LENGTH");
contentlength=strtol(len1, &endptr, 10);
fread(buff, contentlength, 1, stdin);
printf("Content-type: text/html\n\n%s",buff);
}
to do the same thing essentially I will get the following
5B95%5D=&lastname%5B95%5D=&city%5B95%5D=&state%5B95%5D=&firstname%5B96%5D=&lastname%5B96%5D=&city%5B96%5D=&state%5B96%5D=&firstname%5B97%5D=&lastname%5B97%5D=&city%5B97%5D=&state%5B97%5D=&firstname%5B98%5D=&lastname%5B98%5D=&city%5B98%5D=&state%5B98%5D=&firstname%5B99%5D=&lastname%5B99%5D=&city%5B99%5D=&state%5B99%5D=
This is just a portion of the data that I get, it happens to be the
last of the output do demonstrate that I do get the last of the input
elements, notice city%5b99%5d, this is the 99th city element, the loop
goes from 0-99.
Now if you reduce the loop to be 0-5 for example
(for ($l = 0; $l < 5; ++$l)) I get the following output when I use the
first script (action = "post.php").
309firstname%5B0%5D=&lastname%5B0%5D=&city%5B0%5D=&state%5B0%5D=&firstname%5B1%5D=&lastname%5B1%5D=&city%5B1%5D=&state%5B1%5D=&firstname%5B2%5D=&lastname%5B2%5D=&city%5B2%5D=&state%5B2%5D=&firstname%5B3%5D=&lastname%5B3%5D=&city%5B3%5D=&state%5B3%5D=&firstname%5B4%5D=&lastname%5B4%5D=&city%5B4%5D=&state%5B4%5D=
Array ( [firstname] => Array ( [0] => [1] => [2] => [3] => [4] => )
[lastname] => Array ( [0] => [1] => [2] => [3] => [4] => ) [city] =>
Array ( [0] => [1] => [2] => [3] => [4] => ) [state] => Array ( [0] =>
[1] => [2] => [3] => [4] => ) )
The first part is the raw post data, the last is the $_POST variable.
I did the c compiled script, simply to rule out my webserver (apache
1.3.27).
Previous Comments:
[2004-07-17 17:51:19] c dot neise at gmx dot de
I have also the first of these problems.
The script below reproduces the bug.
When entering a small amount of data, the data is displayed.
With a large amount of data (e.g. a screen full of letters pasted into
the text area) the data is lost.
I am using gentoo linux, php 4.3.8 and Apache 2.0.50.
If anything is missing please let me know.
Best regards,
Christian Neise.
[2004-02-20 08:07:17] vincentfinet at hotmail dot com
Hi,
Don't know if it helps but I found out that informations about the file
uploaded from a form using "multipart/form-data" like in the example
below is not in the $_POST array but in the $_FILES array
After hitting the submit button, the second script (in my example,
"WinnyReader.php") will look for informations about the file in
$_FILES["fWinnyFile"] (and not in $_POST["fWinnyFile"] even if the
method of the form is POST!!).
That will do something like this:
if (isset($_FILES["fWinnyFile"]))
{
$arWinnyFile = $_FILES["fWinnyFile"];
echo "name : " . $arWinnyFile["name"] . "\n";
echo "type : " . $arWinnyFile["type"] . "\n";
echo "tmp_name : " . $arWinnyFile["tmp_name"] . "\n&quo
#34140 [NEW]: Bug # 28444 is back again in 5.0.4
From: gary at garycarr dot net
Operating system: Linux
PHP version: 5.0.4
PHP Bug Type: Unknown/Other Function
Bug description: Bug # 28444 is back again in 5.0.4
Description:
bug #28444 is back again, it was fixed in 5.0.3, but now is back again in
5.0.4. This is a duplicate bug, but it has been fixed and now is problem
again, resubmitting for that reason.
Reproduce code:
---
$query = '//menus';
$nodelist = $xpath->query($query);
if (isset($nodelist)) {
foreach ($nodelist as $node){
if ($node->hasAttributes()){
foreach ($node->attributes as $attribute) {
echo nl2br(print_r($attribute,true));
}
}
}
}
Expected result:
the details of each $attribute;
Actual result:
--
PHP Error "Cannot access undefined property for object with overloaded
property access" on foreach line...
--
Edit bug report at http://bugs.php.net/?id=34140&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34140&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34140&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34140&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34140&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34140&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34140&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34140&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34140&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34140&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34140&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34140&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34140&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34140&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34140&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34140&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34140&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34140&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34140&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34140&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34140&r=mysqlcfg
#34140 [Fbk->Opn]: Bug # 28444 is back again in 5.0.4
ID: 34140
User updated by: gary at garycarr dot net
Reported By: gary at garycarr dot net
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.0.4
New Comment:
ok here is the complete test code :
$xml='Learn more about our
companyabout.gif';
$domdoc = new domDocument;
$domdoc->loadxml($xml);
$xpath = new domXPath($domdoc);
$query = '//menus/menu';
$nodelist = $xpath->query($query);
if (isset($nodelist)) {
foreach ($nodelist as $node){
if ($node->hasAttributes()){
foreach ($node->attributes as $attribute) {
echo nl2br("$attribute->name = $attribute->value\n");
}
}
}
}
Previous Comments:
[2005-08-15 22:10:40] [EMAIL PROTECTED]
#28444 was fixed exactly in *5.0.4*.
Please provide a short but complete reproduce script that doesn't
require any external resources. It would be good if the script would
fit in max 20 lines.
----
[2005-08-15 22:07:19] gary at garycarr dot net
Description:
bug #28444 is back again, it was fixed in 5.0.3, but now is back again
in 5.0.4. This is a duplicate bug, but it has been fixed and now is
problem again, resubmitting for that reason.
Reproduce code:
---
$query = '//menus';
$nodelist = $xpath->query($query);
if (isset($nodelist)) {
foreach ($nodelist as $node){
if ($node->hasAttributes()){
foreach ($node->attributes as $attribute) {
echo nl2br(print_r($attribute,true));
}
}
}
}
Expected result:
the details of each $attribute;
Actual result:
--
PHP Error "Cannot access undefined property for object with overloaded
property access" on foreach line...
--
Edit this bug report at http://bugs.php.net/?id=34140&edit=1
#34140 [Fbk->Opn]: Bug # 28444 is back again in 5.0.4
ID: 34140
User updated by: gary at garycarr dot net
Reported By: gary at garycarr dot net
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.0.4
New Comment:
ok thx Tony, we will recompile our 5.0.4 release and try it again. The
exact code that we got the error with is a little more involved than
this code, but I gave you a small snippet that is very similar, we will
recompile and run this script and see what our results are. I will
update ASAP.
Previous Comments:
[2005-08-15 22:39:03] [EMAIL PROTECTED]
This code works fine with:
5.0.3
5.0.4
5.1-dev
6.0-dev
(I get "id = 1 name = about" in all cases)
Are you sure you've posted the right code?
[2005-08-15 22:34:03] gary at garycarr dot net
ok here is the complete test code :
$xml='Learn more about our
companyabout.gif';
$domdoc = new domDocument;
$domdoc->loadxml($xml);
$xpath = new domXPath($domdoc);
$query = '//menus/menu';
$nodelist = $xpath->query($query);
if (isset($nodelist)) {
foreach ($nodelist as $node){
if ($node->hasAttributes()){
foreach ($node->attributes as $attribute) {
echo nl2br("$attribute->name = $attribute->value\n");
}
}
}
}
[2005-08-15 22:10:40] [EMAIL PROTECTED]
#28444 was fixed exactly in *5.0.4*.
Please provide a short but complete reproduce script that doesn't
require any external resources. It would be good if the script would
fit in max 20 lines.
[2005-08-15 22:07:19] gary at garycarr dot net
Description:
bug #28444 is back again, it was fixed in 5.0.3, but now is back again
in 5.0.4. This is a duplicate bug, but it has been fixed and now is
problem again, resubmitting for that reason.
Reproduce code:
---
$query = '//menus';
$nodelist = $xpath->query($query);
if (isset($nodelist)) {
foreach ($nodelist as $node){
if ($node->hasAttributes()){
foreach ($node->attributes as $attribute) {
echo nl2br(print_r($attribute,true));
}
}
}
}
Expected result:
the details of each $attribute;
Actual result:
--
PHP Error "Cannot access undefined property for object with overloaded
property access" on foreach line...
--
Edit this bug report at http://bugs.php.net/?id=34140&edit=1
#32225 [Com]: Tokenizer fails after fatal error until timeout or apache restart
ID: 32225 Comment by: gary dot every at ingramentertainment dot com Reported By: paul dot laughlin at ingramentertainment dot com Status: Open Bug Type: Reproducible crash Operating System: Gentoo Linux 2.6.10 PHP Version: PHP 5.1.0-dev (built: Mar 22 2005 15:40:32) New Comment: The token_get_all seems to still be broken. We are developing a site that will be promoted into production in September. Is anyone else experiencing this problem? Gary Every Previous Comments: [2005-04-12 20:29:59] gary dot every at ingramentertainment dot com There has been no input on this bug for over a month. Is anyone looking into it? We're depending heavily on the tokenizer to parse our template, and this could easily cause serious issues with our next major release of our B2B website. Gary Every [2005-03-22 22:55:29] paul dot laughlin at ingramentertainment dot com Tested this problem with the snapshot as instructed. This is still a problem in the snapshot. THank you [2005-03-20 18:11:55] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-03-07 20:04:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-03-07 19:23:37] paul dot laughlin at ingramentertainment dot com Description: If you have a fatal error it breaks token_get_all until an apache restart... Reproduce code: --- -- Sample Token file Some HTML Some More HTML More HTML -- End Sample Token File -- PHP Script -- '; print_r($token); echo ''; } ?> -- End PHP Script -- If you introduce a parse error as follows, fix the error and reload you get broken output until apache restart. '; print_r($token); echo ''; } ?> Expected result: Array ( [0] => 310 [1] => Some HTML ) Array ( [0] => 365 [1] => Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => TEST_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => Some More HTML ) Array ( [0] => 365 [1] => Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => Another_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => More HTML ) Actual result: -- Array ( [0] => 306 [1] => Some ) Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => HTML ) Array ( [0] => 368 [1] => ) < ? Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => TEST_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => Some More HTML ) Array ( [0] => 365 [1] => Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => Another_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => More HTML ) -- Edit this bug report at http://bugs.php.net/?id=32225&edit=1
#31271 [NEW]: $_SERVER no longer contains SSL_PROTOCOL_VERSION
From: gary dot every at ingramentertainment dot com
Operating system: Gentoo Linux
PHP version: 4.3.10
PHP Bug Type: OpenSSL related
Bug description: $_SERVER no longer contains SSL_PROTOCOL_VERSION
Description:
I've been using $_SERVER['SSL_PROTOCOL_VERSION'] since php3 and after
updating from 4.3.6 to 4.3.10 that particular variable is no longer
available.
We've been using it to check to see if the user is currently on our https:
site, and if not, redirect them to it.
I've overcome the issue, but it took some head-scratching. Below is the
source, both what I had, and what I needed to do to fix it:
Reproduce code:
---
if(!isset($_SERVER['SSL_PROTOCOL_VERSION'])) {
Header("Location: https://www.url.com";);
}
// Code that replaced it
if($_SERVER['SERVER_PORT'] != 443) {
Header("Location: https://www.url.com";);
}
Expected result:
Was expecting the SSL_PROTOCOL_VERSION to be set once they were on the
https site, but it didn't, which put me in an endless loop attempting to
redirect to the https site.
Actual result:
--
Again, put me in an endless loop because $_SERVER['SSL_PROTOCOL_VERSION']
was never set.
--
Edit bug report at http://bugs.php.net/?id=31271&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31271&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31271&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31271&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31271&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31271&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31271&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31271&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31271&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31271&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31271&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31271&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31271&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31271&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31271&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31271&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31271&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31271&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31271&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31271&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31271&r=mysqlcfg
#31271 [Fbk->Opn]: $_SERVER no longer contains SSL_PROTOCOL_VERSION
ID: 31271
User updated by: gary dot every at ingramentertainment dot com
Reported By: gary dot every at ingramentertainment dot com
-Status: Feedback
+Status: Open
Bug Type: OpenSSL related
Operating System: Gentoo Linux
PHP Version: 4.3.10
New Comment:
It's true that the apache server was upgraded as well, so I'll check
their site for any relevant information and get back to you.
Thanks so much for your quick response.
G.
Previous Comments:
[2004-12-23 18:26:16] [EMAIL PROTECTED]
Are you sure you didn't change anything else? $_SERVER variables are
set by your web server, not by PHP. So I would be surprised if just
changing PHP and not anything related to whatever web server you are
using would affect this.
[2004-12-23 18:22:30] gary dot every at ingramentertainment dot com
Description:
I've been using $_SERVER['SSL_PROTOCOL_VERSION'] since php3 and after
updating from 4.3.6 to 4.3.10 that particular variable is no longer
available.
We've been using it to check to see if the user is currently on our
https: site, and if not, redirect them to it.
I've overcome the issue, but it took some head-scratching. Below is the
source, both what I had, and what I needed to do to fix it:
Reproduce code:
---
if(!isset($_SERVER['SSL_PROTOCOL_VERSION'])) {
Header("Location: https://www.url.com";);
}
// Code that replaced it
if($_SERVER['SERVER_PORT'] != 443) {
Header("Location: https://www.url.com";);
}
Expected result:
Was expecting the SSL_PROTOCOL_VERSION to be set once they were on the
https site, but it didn't, which put me in an endless loop attempting
to redirect to the https site.
Actual result:
--
Again, put me in an endless loop because
$_SERVER['SSL_PROTOCOL_VERSION'] was never set.
--
Edit this bug report at http://bugs.php.net/?id=31271&edit=1
#31271 [Opn->Csd]: $_SERVER no longer contains SSL_PROTOCOL_VERSION
ID: 31271
User updated by: gary dot every at ingramentertainment dot com
Reported By: gary dot every at ingramentertainment dot com
-Status: Open
+Status: Closed
Bug Type: OpenSSL related
Operating System: Gentoo Linux
PHP Version: 4.3.10
New Comment:
Apache did change their $_SERVER variable names, and the compatibility
can be found here:
http://httpd.apache.org/docs-2.1/ssl/ssl_compat.html
They changed from SSL_PROTOCOL_VERSION to SSL_PROTOCOL
I'm closing this bug report and thanks so much!
Previous Comments:
[2004-12-23 18:45:41] gary dot every at ingramentertainment dot com
It's true that the apache server was upgraded as well, so I'll check
their site for any relevant information and get back to you.
Thanks so much for your quick response.
G.
[2004-12-23 18:26:16] [EMAIL PROTECTED]
Are you sure you didn't change anything else? $_SERVER variables are
set by your web server, not by PHP. So I would be surprised if just
changing PHP and not anything related to whatever web server you are
using would affect this.
[2004-12-23 18:22:30] gary dot every at ingramentertainment dot com
Description:
I've been using $_SERVER['SSL_PROTOCOL_VERSION'] since php3 and after
updating from 4.3.6 to 4.3.10 that particular variable is no longer
available.
We've been using it to check to see if the user is currently on our
https: site, and if not, redirect them to it.
I've overcome the issue, but it took some head-scratching. Below is the
source, both what I had, and what I needed to do to fix it:
Reproduce code:
---
if(!isset($_SERVER['SSL_PROTOCOL_VERSION'])) {
Header("Location: https://www.url.com";);
}
// Code that replaced it
if($_SERVER['SERVER_PORT'] != 443) {
Header("Location: https://www.url.com";);
}
Expected result:
Was expecting the SSL_PROTOCOL_VERSION to be set once they were on the
https site, but it didn't, which put me in an endless loop attempting
to redirect to the https site.
Actual result:
--
Again, put me in an endless loop because
$_SERVER['SSL_PROTOCOL_VERSION'] was never set.
--
Edit this bug report at http://bugs.php.net/?id=31271&edit=1
#32225 [Com]: Tokenizer fails after fatal error until timeout or apache restart
ID: 32225 Comment by: gary dot every at ingramentertainment dot com Reported By: paul dot laughlin at ingramentertainment dot com Status: Open Bug Type: Reproducible crash Operating System: Gentoo Linux 2.6.10 PHP Version: PHP 5.1.0-dev (built: Mar 22 2005 15:40:32) New Comment: There has been no input on this bug for over a month. Is anyone looking into it? We're depending heavily on the tokenizer to parse our template, and this could easily cause serious issues with our next major release of our B2B website. Gary Every Previous Comments: [2005-03-22 22:55:29] paul dot laughlin at ingramentertainment dot com Tested this problem with the snapshot as instructed. This is still a problem in the snapshot. THank you [2005-03-20 18:11:55] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-03-07 20:04:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-03-07 19:23:37] paul dot laughlin at ingramentertainment dot com Description: If you have a fatal error it breaks token_get_all until an apache restart... Reproduce code: --- -- Sample Token file Some HTML Some More HTML More HTML -- End Sample Token File -- PHP Script -- '; print_r($token); echo ''; } ?> -- End PHP Script -- If you introduce a parse error as follows, fix the error and reload you get broken output until apache restart. '; print_r($token); echo ''; } ?> Expected result: Array ( [0] => 310 [1] => Some HTML ) Array ( [0] => 365 [1] => Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => TEST_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => Some More HTML ) Array ( [0] => 365 [1] => Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => Another_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => More HTML ) Actual result: -- Array ( [0] => 306 [1] => Some ) Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => HTML ) Array ( [0] => 368 [1] => ) < ? Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => TEST_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => Some More HTML ) Array ( [0] => 365 [1] => Array ( [0] => 368 [1] => ) Array ( [0] => 306 [1] => Another_TAG ) Array ( [0] => 368 [1] => ) Array ( [0] => 367 [1] => ?> ) Array ( [0] => 310 [1] => More HTML ) -- Edit this bug report at http://bugs.php.net/?id=32225&edit=1
#36795 [Com]: Inappropriate "unterminated entity reference" in DOMElement->setAttribute
ID: 36795
Comment by: gary dot malcolm at gmail dot com
Reported By: john at carney dot id dot au
Status: No Feedback
Bug Type: DOM XML related
Operating System: Windows/Linux
PHP Version: 5.1.2
New Comment:
I'm running PHP 5.2.9 on Linux and this bug is still alive and well
making SimpleXml absolutely inappropriate for XML communications between
systems.
$safe_value = preg_replace('/&(?!\w+;)/', '&', $value);
return $sxml->addChild($name, $safe_value);
Is just plain wrong. I'm communicating user input directly to a bank as
I can't know how the third party will parse their xml.
Previous Comments:
[2008-04-03 23:15:04] rob at electronicinsight dot com
A little hack to get around this bug:
function &safe_add_child(&$sxml, $name, $value) {
$safe_value = preg_replace('/&(?!\w+;)/', '&', $value);
return $sxml->addChild($name, $safe_value);
}
[2008-02-08 20:09:37] moshe at varien dot com
PHP 5.2.4
Looks like the problem appears when there's node already exists being
overwritten
// works ok, doesn't require encoding:
$a = simplexml_load_string('');
$a->b = "& < ' ";
// doesn't work, requires encoding:
$a = simplexml_load_string('test');
$a->b = "& < ' ";
// doesn't work, always requires encoding
$a->addChild('b', "& < '");
$a->addAttribute('b', "& < '");
// works ok, never requires encoding
$a['b'] = "& < '";
[2007-11-27 14:03:55] oscar at cdcovers dot to
I tried the workaround below and it seems to work:
$xml->addChild('element', '');
$xml->element = str_replace("&", "&", "value of the element");
[2007-09-28 06:40:20] ocus51 at gail dot com
Hi,
I'm still experiencing this problem :
- PHP Version 5.2.0-8+etch7
- DOM/XML API Version 20031129
- libxml Version 2.6.27
[2006-12-06 11:49:37] philippe dot levan_nospam at kitpages dot fr
Hi,
I have the same problem. My config is :
- PHP 5.2
- libxml Version 2.6.16
-
";
$xml = new SimpleXMLElement($xmlStr);
$xml->addChild("foo",utf8_encode("start < > end"));
echo "foo tag added ok";
$xml->addChild("bar",utf8_encode("start & end"));
echo "error on bar tag because of &";
$result = $xml->asXML();
echo "".htmlentities($result)."";
?>
-
you can run this script at :
http://www.kitpages.fr/test/bugSimpleXml.php
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36795
--
Edit this bug report at http://bugs.php.net/?id=36795&edit=1
#44645 [NEW]: php5ts.dll Crash (x86_64 base machines)
From: gary dot wilson at coull dot biz Operating system: Windows Server 2003 PHP version: 5.2.5 PHP Bug Type: Reproducible crash Bug description: php5ts.dll Crash (x86_64 base machines) Description: Failure case: Making 8 (or more) concurrent requests to Apache/php requesting XML causes php5ts.dll to throw an application error. Event Type: Information Event Source: Application Error Event Category: (100) Event ID: 1004 Date: 02/04/2008 Time: 17:47:03 User: N/A Computer: COULL-WEB01 Description: Reporting queued error: faulting application Apache.exe, version 2.0.55.0, faulting module php5ts.dll, version 5.1.6.6, fault address 0x926a. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 41 70 61 ure Apa 0018: 63 68 65 2e 65 78 65 20 che.exe 0020: 32 2e 30 2e 35 35 2e 30 2.0.55.0 0028: 20 69 6e 20 70 68 70 35in php5 0030: 74 73 2e 64 6c 6c 20 35 ts.dll 5 0038: 2e 31 2e 36 2e 36 20 61 .1.6.6 a 0040: 74 20 6f 66 66 73 65 74 t offset 0048: 20 30 30 30 30 39 32 36926 0050: 61a # Event Type: Information Event Source: Application Error Event Category: (100) Event ID: 1004 Date: 05/04/2008 Time: 09:21:48 User: N/A Computer: MEDIAPROC02 Description: Reporting queued error: faulting application httpd.exe, version 2.2.8.0, faulting module php5ts.dll, version 5.2.5.5, fault address 0xacb9. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 68 74 74 ure htt 0018: 70 64 2e 65 78 65 20 32 pd.exe 2 0020: 2e 32 2e 38 2e 30 20 69 .2.8.0 i 0028: 6e 20 70 68 70 35 74 73 n php5ts 0030: 2e 64 6c 6c 20 35 2e 32 .dll 5.2 0038: 2e 35 2e 35 20 61 74 20 .5.5 at 0040: 6f 66 66 73 65 74 20 30 offset 0 0048: 30 30 30 61 63 62 39 000acb9 Hardware Manufacture: Dell, HP Machine base: 64 bit Operating System: Windows Server 2003 SP2 (32 bit) Apache versions: 2.0.55, 2.0.59, 2.2.4, 2.2.8 php Versions: 5.1.6, 5.2.5, 5.3.dev Description: This problem was reproducible every time with a combination all the above components. This was reproduced on 3 separate servers, 2 Dell and 1 HP. The failure case CANNOT be reproduced on a machine with the same OS, Apache/php versions/config and code base that is running on a 32 bit base machine this was verified on 5 servers. In our failure case we are generating XML output on every request. It would seem like this is a issue when running 32 bit Win OS on 64 bit base machine. Unfortunately, I am unable to test this on 64 bit Windows 2003, however, I did retrograde a 64 bit OS a few months ago due to a very similar problem (not certain if it was exactly the same). Reproduce code: --- Not a developer. I will try and get our development team to create some code to reproduce, but they are very busy, so it may take some time. -- Edit bug report at http://bugs.php.net/?id=44645&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44645&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44645&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44645&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44645&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44645&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44645&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44645&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44645&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44645&r=support Expected behavior:http://bugs.php.net/fix.php?id=44645&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44645&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44645&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44645&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44645&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44645&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44645&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44645&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44645&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44645&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44645&r=mysqlcfg
#36550 [NEW]: FATAL: emalloc(): Unable to allocate
From: gary dot wilson at coull dot biz Operating system: Windows Server 2000 PHP version: 5.1.2 PHP Bug Type: *General Issues Bug description: FATAL: emalloc(): Unable to allocate Description: We are running Apache 2.0.55 (with OpenSSL 0.9.8a), Drupal 4.6 with MySQL 5.0. We run two hardware load balanced servers of identical spec and configuration and are seeing an error on both servers (not at the same times though). A file that is available within the CMS on network attached storage is downloadable, however on intermittent occasions the client download hangs and well see the following in the Apache error log: FATAL: emalloc(): Unable to allocate 2629871 bytes Apache then restarts. This is a fairly intermittent problem and is sometimes reproducible on some networks but not consistently reproducible. Our memory_limit is set to 8M and the downloadable file is 2.6Mb. I have up-ed this to 32M (as some similar bug reports suggested this). Research and many articles have pointed to php as the candidate, however knowing where to begin is the problem. Just a point in the right direction would be extremely helpful. Regards Gary -- Edit bug report at http://bugs.php.net/?id=36550&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36550&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36550&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36550&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36550&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36550&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36550&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36550&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36550&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36550&r=support Expected behavior:http://bugs.php.net/fix.php?id=36550&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36550&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36550&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36550&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36550&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36550&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36550&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36550&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36550&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36550&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36550&r=mysqlcfg
#36550 [Fbk->Opn]: FATAL: emalloc(): Unable to allocate
ID: 36550 User updated by: gary dot wilson at coull dot biz Reported By: gary dot wilson at coull dot biz -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows Server 2000 PHP Version: 5.1.2 New Comment: The memory_limit increase has resulted in the FATAL: emalloc(): Unable to allocate to not occur again. However, now we have experienced: FATAL: erealloc(): Unable to allocate 1572864 bytes [Tue Feb 28 14:36:12 2006] [notice] Parent: child process exited with status 1 -- Restarting. I do not have a sample script as I do not know what it causing this. Previous Comments: [2006-02-28 09:27:41] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-02-27 21:22:41] gary dot wilson at coull dot biz Description: We are running Apache 2.0.55 (with OpenSSL 0.9.8a), Drupal 4.6 with MySQL 5.0. We run two hardware load balanced servers of identical spec and configuration and are seeing an error on both servers (not at the same times though). A file that is available within the CMS on network attached storage is downloadable, however on intermittent occasions the client download hangs and well see the following in the Apache error log: FATAL: emalloc(): Unable to allocate 2629871 bytes Apache then restarts. This is a fairly intermittent problem and is sometimes reproducible on some networks but not consistently reproducible. Our memory_limit is set to 8M and the downloadable file is 2.6Mb. I have up-ed this to 32M (as some similar bug reports suggested this). Research and many articles have pointed to php as the candidate, however knowing where to begin is the problem. Just a point in the right direction would be extremely helpful. Regards Gary -- Edit this bug report at http://bugs.php.net/?id=36550&edit=1
#36550 [Fbk->Opn]: FATAL: emalloc(): Unable to allocate
ID: 36550 User updated by: gary dot wilson at coull dot biz Reported By: gary dot wilson at coull dot biz -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows Server 2000 PHP Version: 5.1.2 New Comment: Thanks for your honesty, if I can identify the code and provide a script, I will submit it soon as :) Regards Gary Previous Comments: [2006-03-01 19:43:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Gary: I am sorry, I really am. But without proper reproducable script there is just no way we can even start guessing what is causing this. [2006-03-01 16:54:09] gary dot wilson at coull dot biz The memory_limit increase has resulted in the FATAL: emalloc(): Unable to allocate to not occur again. However, now we have experienced: FATAL: erealloc(): Unable to allocate 1572864 bytes [Tue Feb 28 14:36:12 2006] [notice] Parent: child process exited with status 1 -- Restarting. I do not have a sample script as I do not know what it causing this. [2006-02-28 09:27:41] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-02-27 21:22:41] gary dot wilson at coull dot biz Description: We are running Apache 2.0.55 (with OpenSSL 0.9.8a), Drupal 4.6 with MySQL 5.0. We run two hardware load balanced servers of identical spec and configuration and are seeing an error on both servers (not at the same times though). A file that is available within the CMS on network attached storage is downloadable, however on intermittent occasions the client download hangs and well see the following in the Apache error log: FATAL: emalloc(): Unable to allocate 2629871 bytes Apache then restarts. This is a fairly intermittent problem and is sometimes reproducible on some networks but not consistently reproducible. Our memory_limit is set to 8M and the downloadable file is 2.6Mb. I have up-ed this to 32M (as some similar bug reports suggested this). Research and many articles have pointed to php as the candidate, however knowing where to begin is the problem. Just a point in the right direction would be extremely helpful. Regards Gary -- Edit this bug report at http://bugs.php.net/?id=36550&edit=1
#49012 [NEW]: Spurious fatal error on require() statement
From: gary dot barnes at is-networks dot co dot uk Operating system: Linux version 2.6.10-1.766_FC3 PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: Spurious fatal error on require() statement Description: After installing 5.3.0 some site scripts fail with the message: PHP Fatal error: Unknown: Failed opening required in Unknown on line 0. This is only some sites, and is intermittent, and can appear after several refreshes of the web page (maybe memory/file handle related?) Versions 5.2.9, 5.2.8 work fine with the same scripts. Also appears not to be obeying error_reporting statement in php.ini -- Edit bug report at http://bugs.php.net/?id=49012&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49012&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49012&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49012&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49012&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49012&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49012&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49012&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49012&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49012&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49012&r=support Expected behavior: http://bugs.php.net/fix.php?id=49012&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49012&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49012&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49012&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49012&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49012&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49012&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49012&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49012&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49012&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49012&r=mysqlcfg
#49012 [Fbk->Opn]: Spurious fatal error on require() statement
ID: 49012 User updated by: gary dot barnes at is-networks dot co dot uk Reported By: gary dot barnes at is-networks dot co dot uk -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Linux version 2.6.10-1.766_FC3 PHP Version: 5.3.0 New Comment: Found some out of date PHP4 extensions which were failing to load (mysql and ldap). However, these aren't required and obviously failed to load with previous PHP5 versions with no detrimental affects. I can now confirm there is no problem with 5.2.10, so it seems only with 5.3.0 I get this problem. Previous Comments: [2009-07-22 07:04:02] ras...@php.net Any 3rd-party extensions? [2009-07-22 06:58:47] gary dot barnes at is-networks dot co dot uk Description: After installing 5.3.0 some site scripts fail with the message: PHP Fatal error: Unknown: Failed opening required in Unknown on line 0. This is only some sites, and is intermittent, and can appear after several refreshes of the web page (maybe memory/file handle related?) Versions 5.2.9, 5.2.8 work fine with the same scripts. Also appears not to be obeying error_reporting statement in php.ini -- Edit this bug report at http://bugs.php.net/?id=49012&edit=1
#49012 [Fbk->Opn]: Spurious fatal error on require() statement
ID: 49012 User updated by: gary dot barnes at is-networks dot co dot uk Reported By: gary dot barnes at is-networks dot co dot uk -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Linux version 2.6.10-1.766_FC3 PHP Version: 5.3.0 New Comment: Thanks for this. Unfortunately, the make fails with this error: /bin/sh /home/rpm/php5.3-200907290430/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/openssl/ -I/home/rpm/php5.3-200907290430/ext/openssl/ -DPHP_ATOM_INC -I/home/rpm/php5.3-200907290430/include -I/home/rpm/php5.3-200907290430/main -I/home/rpm/php5.3-200907290430 -I/home/rpm/php5.3-200907290430/ext/date/lib -I/home/rpm/php5.3-200907290430/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/home/rpm/php5.3-200907290430/ext/mbstring/oniguruma -I/home/rpm/php5.3-200907290430/ext/mbstring/libmbfl -I/home/rpm/php5.3-200907290430/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/home/rpm/php5.3-200907290430/ext/sqlite3/libsqlite -I/home/rpm/php5.3-200907290430/TSRM -I/home/rpm/php5.3-200907290430/Zend-I/usr/include -g -O2 -prefer-non-pic -c /home/rpm/php5.3-200907290430/ext/openssl/openssl.c -o ext/openssl/openssl.lo /home/rpm/php5.3-200907290430/ext/openssl/openssl.c: In function `php_openssl_x509_from_zval': /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: `d2i_of_void' undeclared (first use in this function) /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: (Each undeclared identifier is reported only once /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: for each function it appears in.) /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: syntax error before ')' token make: *** [ext/openssl/openssl.lo] Error 1 Previous Comments: [2009-07-28 16:51:27] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And do not try loading any 3rd party extensions, or outdated ones either. :) [2009-07-27 10:52:04] gary dot barnes at is-networks dot co dot uk Found some out of date PHP4 extensions which were failing to load (mysql and ldap). However, these aren't required and obviously failed to load with previous PHP5 versions with no detrimental affects. I can now confirm there is no problem with 5.2.10, so it seems only with 5.3.0 I get this problem.) [2009-07-22 07:04:02] ras...@php.net Any 3rd-party extensions? ---- [2009-07-22 06:58:47] gary dot barnes at is-networks dot co dot uk Description: After installing 5.3.0 some site scripts fail with the message: PHP Fatal error: Unknown: Failed opening required in Unknown on line 0. This is only some sites, and is intermittent, and can appear after several refreshes of the web page (maybe memory/file handle related?) Versions 5.2.9, 5.2.8 work fine with the same scripts. Also appears not to be obeying error_reporting statement in php.ini -- Edit this bug report at http://bugs.php.net/?id=49012&edit=1
#49012 [Fbk->Opn]: Spurious fatal error on require() statement
ID: 49012 User updated by: gary dot barnes at is-networks dot co dot uk Reported By: gary dot barnes at is-networks dot co dot uk -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Linux version 2.6.10-1.766_FC3 PHP Version: 5.3.0 Assigned To: pajoye New Comment: OK, thanks for that. OpenSSL version is 0.9.7a Previous Comments: [2009-07-29 23:30:11] j...@php.net And I stand corrected. Apparently Pierre broke it. What openssl version are you compiling PHP with? [2009-07-29 06:05:12] gary dot barnes at is-networks dot co dot uk Thanks for this. Unfortunately, the make fails with this error: /bin/sh /home/rpm/php5.3-200907290430/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/openssl/ -I/home/rpm/php5.3-200907290430/ext/openssl/ -DPHP_ATOM_INC -I/home/rpm/php5.3-200907290430/include -I/home/rpm/php5.3-200907290430/main -I/home/rpm/php5.3-200907290430 -I/home/rpm/php5.3-200907290430/ext/date/lib -I/home/rpm/php5.3-200907290430/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/home/rpm/php5.3-200907290430/ext/mbstring/oniguruma -I/home/rpm/php5.3-200907290430/ext/mbstring/libmbfl -I/home/rpm/php5.3-200907290430/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/home/rpm/php5.3-200907290430/ext/sqlite3/libsqlite -I/home/rpm/php5.3-200907290430/TSRM -I/home/rpm/php5.3-200907290430/Zend-I/usr/include -g -O2 -prefer-non-pic -c /home/rpm/php5.3-200907290430/ext/openssl/openssl.c -o ext/openssl/openssl.lo /home/rpm/php5.3-200907290430/ext/openssl/openssl.c: In function `php_openssl_x509_from_zval': /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: `d2i_of_void' undeclared (first use in this function) /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: (Each undeclared identifier is reported only once /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: for each function it appears in.) /home/rpm/php5.3-200907290430/ext/openssl/openssl.c:1170: error: syntax error before ')' token make: *** [ext/openssl/openssl.lo] Error 1) [2009-07-28 16:51:27] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And do not try loading any 3rd party extensions, or outdated ones either. :) [2009-07-27 10:52:04] gary dot barnes at is-networks dot co dot uk Found some out of date PHP4 extensions which were failing to load (mysql and ldap). However, these aren't required and obviously failed to load with previous PHP5 versions with no detrimental affects. I can now confirm there is no problem with 5.2.10, so it seems only with 5.3.0 I get this problem.) [2009-07-22 07:04:02] ras...@php.net Any 3rd-party extensions? 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/49012 -- Edit this bug report at http://bugs.php.net/?id=49012&edit=1
