#40971 [Opn->Bgs]: Unexpected T_Variable (New to This)
ID: 40971
Updated by: [EMAIL PROTECTED]
Reported By: MSIHelper at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Variables related
Operating System: WinXP
PHP Version: 5.2.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
.
Previous Comments:
[2007-04-01 05:46:40] MSIHelper at gmail dot com
Description:
Hello - THANK YOU SO MUCH FOR YOUR ASSISTANCE. (I am NEW to ALL
this, so PLEASE
excuse my inability to explain the Right Details)
An aquaintance, Mr. Lyles ([EMAIL PROTECTED]) who is a Great
Computer Networker/Repair/etc.
is helping me to Automate the SignUP & Login of my NEW site
www.IncomeGains.Bravehost.com
_
PROBLEM w/ IGcreate.php (www.IncomeGains.Bravehost.com/IGcreate.php)
IGcreate.php (i believe) collects or recieves the inputed data and
1.) EMAILS the New Member with a Message and their access info.
2.) EMAILS Admin with the New Member info.
Parse error: syntax error, unexpected T_VARIABLE in
/incomegains.bravehost.com/IGcreate.php on line 31
Line 31 starts with $MSImsg
ALSO, we are using www.Bravenet.com as the Professional Host Server,
but I think it is PHP ready, because
it at least reads upto line 31 RIGHT? or do we need to install
PHP5?
Here is the Code:
(Do we need to add a Recipient)
(Do we need ' before/after names in []), like: $_POST['Email']
(Do we need to take-out .'s and ".s between all the and $_POST)
_
";
echo "Try again";
exit;
} else {
// insert the data into database
$insert = mysql_query("insert into $table values ('NULL',
'".$_POST[Email]."', '".$_POST[Password]."')")
or die("Could not insert data because ".mysql_error());
// send the emails
$msg = "WELCOME to the Income Gains," . $_POST[FirstName] . " " .
$_POST[LastName] . "!"; //!Message that will be emailed to
user!!!
$subject = "WELCOME to the Income Gains." //Subject of message emailed
to user. After this is the stuff that is emailed to you.
$MSImsg = "Email: $_POST[Email] Name: $_POST[FirstName] . " " .
$_POST[LastName] Zip: $_POST[Zip] Password: $_POST[Password] .
"!";
$MSIsubj = "New Member";
mail("[EMAIL PROTECTED]", $MSIsubj, $MSImsg);
mail($_POST[Email], $subject, $msg);
// print a success message
echo "Your user account has been created!";
echo "Now you can log in";
*
THANKS FOR ALL YOUR HELP contact info: [EMAIL PROTECTED] I
REALLY APPRECIATE IT
Reproduce code:
---
www.IncomeGains.Bravehost.com/IGcreate.php
Expected result:
He made 4 files: config.php, IGcreate.php, createtable.php,
login.php
When people Register/SignUp (i believe): it goes to the config.php -->
IGcreate.php --> then
createtable.php inputs information into the SQL Database - we made,
so (Login Page's SUBMIT)
login.php can verify and let them have access.
*
THANKS FOR ALL YOUR HELP contact info: [EMAIL PROTECTED] I
REALLY APPRECIATE IT
--
Edit this bug report at http://bugs.php.net/?id=40971&edit=1
#40970 [Opn->Bgs]: filemtime slower on PHP5 vs PHP4
ID: 40970
Updated by: [EMAIL PROTECTED]
Reported By: php at edwardk dot info
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
This is only the case when stat() fails.
If you change stat('.'); to stat(''); you will se that PHP5
is faster than php4. Almost 2x.
Previous Comments:
[2007-04-01 00:16:16] php at edwardk dot info
Description:
filemtime and other related functions are slower on php5 vs php4
Using PHP 5.2.1 and PHP 4.4.6 on Athlon X2 3800+, Windows 2003
the speed difference is about 50-100x slower.
Reproduce code:
---
Expected result:
Speeds should be similar
Actual result:
--
On PHP 4.4.6, it took about 1.6ms
On PHP 5.2.1 it took about 130ms
--
Edit this bug report at http://bugs.php.net/?id=40970&edit=1
#40923 [Asn]: mb_send_mail does not encode subject correctly
ID: 40923 Updated by: [EMAIL PROTECTED] Reported By: quasar at aero dot ist dot utl dot pt Status: Assigned Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.1 Assigned To: moriyoshi New Comment: For the record, could you tell me the name of the e-mail client(s) your end of people used at the time of the problem? Previous Comments: [2007-03-27 00:44:59] quasar at aero dot ist dot utl dot pt After further reading of RFC2047 (http://www.ietf.org/rfc/rfc2047.txt) i have found this: Ordinary ASCII text and 'encoded-word's may appear together in the same header field. However, an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'. This implies that the function's behavior is actually correct, however it still creates problems with some e-mail clients. I have filled this bug report following several bug reports on my end of people having e-mail clients inserting encoding tags in the middle of the subject. For example (verified in pine): "hello [UTF-8]ãll". Although it is now clear to me that the behaviour is in fact RFC2047 compliant, should it not be tweaked to make it more widely compatible with a greater variety e-mail clients? (Perhaps this should be moved to a feature request, and i am sorry for the "false positive", i should have done my homework more carefully) [2007-03-26 19:18:26] [EMAIL PROTECTED] Could you please point me to an RFC which says the actual result is incorrect? [2007-03-26 16:34:46] quasar at aero dot ist dot utl dot pt Description: When trying to send an e-mail with international character in the subject, mb_send_mail is expected to fully encode the subject string. However it only encodes the string form the first word containing the interantional characters on. Reproduce code: --- // Assuming $to, $message and $headers already defined $subject = "hello ãll"; mb_send_mail($to, $subject, $message, $headers); Expected result: A fully encoded Subject header, in the form: Subject: ?UTF-8?B?SOMETHING?= Actual result: -- Received e-mail relevant headers, as you can see the hello part of the string, which has no international, characters is left unencoded: Subject: hello =?UTF-8?B?w6NsbA==?= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 -- Edit this bug report at http://bugs.php.net/?id=40923&edit=1
#40973 [NEW]: session don't work if used $_SERVER in any way
From: krassesache at gmx dot net
Operating system: WinXP SP2
PHP version: 5.2.1
PHP Bug Type: Session related
Bug description: session don't work if used $_SERVER in any way
Description:
if i use $_SERVER in any way but with pdo statements [
$stmt->execute(array($_SERVER['REMOTE_ADDR'])) ] a session will not work.
in my example i first open foobar.php and then foobar2.php. if remove the
4th line in foobar2.php [ $var = $_SERVER['REMOTE_ADDR']; ] the the text
"bar" appears but with the line, nothing happens. in other case is used
preg_match('#MSIE#',$_SERVER['HTTP_USER_AGENT']) with the result that the
website will be shown but the session dont work (the original problem).
Reproduce code:
---
=> foobar.php
=> foobar2.php
Expected result:
bar
Actual result:
--
--
Edit bug report at http://bugs.php.net/?id=40973&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40973&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40973&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40973&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40973&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40973&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40973&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40973&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40973&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40973&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40973&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40973&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40973&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40973&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40973&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40973&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40973&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40973&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40973&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40973&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40973&r=mysqlcfg
#40923 [Asn]: mb_send_mail does not encode subject correctly
ID: 40923 User updated by: quasar at aero dot ist dot utl dot pt Reported By: quasar at aero dot ist dot utl dot pt Status: Assigned Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.1 Assigned To: moriyoshi New Comment: Currently the problem has only been reported in pine (4.64) which is the default e-mail client for our system (300+ users). It appends an encoding tag to the email subject, which appears in the middle of the subject if it is not fully encoded. I know this isn't a real bug and you don't really have to "fix it", but i browsed through thousands of e-mail subjects on my own account and found out only the ones sent via our php interface show this subject encoding glitch. According to RFC it is corect to only encode the part that needs to be encoded, however it does not appear to be the "standard policy" with all the e-mail sending software available. Thanks for looking into this :) Previous Comments: [2007-04-01 15:23:42] [EMAIL PROTECTED] For the record, could you tell me the name of the e-mail client(s) your end of people used at the time of the problem? [2007-03-27 00:44:59] quasar at aero dot ist dot utl dot pt After further reading of RFC2047 (http://www.ietf.org/rfc/rfc2047.txt) i have found this: Ordinary ASCII text and 'encoded-word's may appear together in the same header field. However, an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'. This implies that the function's behavior is actually correct, however it still creates problems with some e-mail clients. I have filled this bug report following several bug reports on my end of people having e-mail clients inserting encoding tags in the middle of the subject. For example (verified in pine): "hello [UTF-8]ãll". Although it is now clear to me that the behaviour is in fact RFC2047 compliant, should it not be tweaked to make it more widely compatible with a greater variety e-mail clients? (Perhaps this should be moved to a feature request, and i am sorry for the "false positive", i should have done my homework more carefully) [2007-03-26 19:18:26] [EMAIL PROTECTED] Could you please point me to an RFC which says the actual result is incorrect? [2007-03-26 16:34:46] quasar at aero dot ist dot utl dot pt Description: When trying to send an e-mail with international character in the subject, mb_send_mail is expected to fully encode the subject string. However it only encodes the string form the first word containing the interantional characters on. Reproduce code: --- // Assuming $to, $message and $headers already defined $subject = "hello ãll"; mb_send_mail($to, $subject, $message, $headers); Expected result: A fully encoded Subject header, in the form: Subject: ?UTF-8?B?SOMETHING?= Actual result: -- Received e-mail relevant headers, as you can see the hello part of the string, which has no international, characters is left unencoded: Subject: hello =?UTF-8?B?w6NsbA==?= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 -- Edit this bug report at http://bugs.php.net/?id=40923&edit=1
#40974 [NEW]: PDO::PARAM_NULL not inserting NULL in MySQL
From: justin dot hendrickson+pecl at gmail dot com
Operating system: Ubuntu 6.10
PHP version: 5.2.1
PHP Bug Type: PDO related
Bug description: PDO::PARAM_NULL not inserting NULL in MySQL
Description:
Using PDO::PARAM_NULL when doing a bindParam()/bindValue() does not insert
a NULL value. It appears to insert the default value instead. '' in
(var)char/text fields, 0 in boolean fields, ect.
Reproduce code:
---
$stmt = 'INSERT INTO table (field) VALUES (:placeholder)';
$stmt->bindValue(':placeholder', PDO::PARAM_NULL);
$stmt->execute();
Expected result:
`field` in `table` set to NULL
Actual result:
--
`field` in `table` set to default value
--
Edit bug report at http://bugs.php.net/?id=40974&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40974&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40974&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40974&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40974&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40974&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40974&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40974&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40974&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40974&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40974&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40974&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40974&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40974&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40974&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40974&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40974&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40974&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40974&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40974&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40974&r=mysqlcfg
#40974 [Opn->Bgs]: whoops
ID: 40974
User updated by: justin dot hendrickson+pecl at gmail dot com
-Summary: PDO::PARAM_NULL not inserting NULL in MySQL
Reported By: justin dot hendrickson+pecl at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Ubuntu 6.10
PHP Version: 5.2.1
New Comment:
PEBKAC
Previous Comments:
[2007-04-01 18:31:47] justin dot hendrickson+pecl at gmail dot com
Description:
Using PDO::PARAM_NULL when doing a bindParam()/bindValue() does not
insert a NULL value. It appears to insert the default value instead. ''
in (var)char/text fields, 0 in boolean fields, ect.
Reproduce code:
---
$stmt = 'INSERT INTO table (field) VALUES (:placeholder)';
$stmt->bindValue(':placeholder', PDO::PARAM_NULL);
$stmt->execute();
Expected result:
`field` in `table` set to NULL
Actual result:
--
`field` in `table` set to default value
--
Edit this bug report at http://bugs.php.net/?id=40974&edit=1
#40921 [Asn->Csd]: exceed post_max_size and php_default_post_reader seg faults apache
ID: 40921 Updated by: [EMAIL PROTECTED] Reported By: trickie at gmail dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: Gentoo Linux PHP Version: 5.2.1 Assigned To: iliaa New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2007-03-26 14:09:25] trickie at gmail dot com Description: If you POST a request that triggers the default post reader (php_default_post_reader), and that request exceeds post_max_size then apache will segmentation fault. I first found this using the SOAP extension. Reproduce code: --- I have not been able to come up with a simple reproduce code, i can submit some of the more complex soap code i am using if necessary Expected result: Normal processing of a POST request Actual result: -- Patch available: http://trickie.org/code/max_post_fix.patch GDB backtrace: Starting program: /usr/sbin/apache2 -X -D DEFAULT_VHOST -D PHP5 -f /etc/apache2/httpd.conf -k start (no debugging symbols found) Failed to read a valid object file image from memory. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1213380944 (LWP 4640)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1213380944 (LWP 4640)] 0xb7747565 in _estrndup (s=0x0, length=743, __zend_filename=0xb7a05214 "/var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/main/php_content_types.c", __zend_lineno=49, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/Zend/zend_alloc.c:2351 2351 /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/Zend/zend_alloc.c: No such file or directory. in /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/Zend/zend_alloc.c (gdb) bt #0 0xb7747565 in _estrndup (s=0x0, length=743, __zend_filename=0xb7a05214 "/var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/main/php_content_types.c", __zend_lineno=49, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/Zend/zend_alloc.c:2351 #1 0xb771d24a in php_default_post_reader () at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/main/php_content_types.c:49 #2 0xb7717e32 in sapi_read_post_data () at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/main/SAPI.c:190 #3 0xb77185e8 in sapi_activate () at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/main/SAPI.c:372 #4 0xb77108d6 in php_request_startup () at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/main/main.c:1105 #5 0xb77dc3c8 in php_apache_request_ctor (r=0x8254238, ctx=0x8255700) at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/sapi/apache2handler/sapi_apache2.c:458 #6 0xb77dc989 in php_handler (r=0x8254238) at /var/tmp/portage/dev-lang/php-5.2.1-r300/work/php5.2-200703260630/sapi/apache2handler/sapi_apache2.c:574 #7 0x0806a4f8 in ap_run_handler () #8 0x0806d5c1 in ap_invoke_handler () #9 0x0806735e in ap_process_request () #10 0x0806116b in _start () -- Edit this bug report at http://bugs.php.net/?id=40921&edit=1
#40897 [Asn->Csd]: error_log file not locked
ID: 40897
Updated by: [EMAIL PROTECTED]
Reported By: david at acz dot org
-Status: Assigned
+Status: Closed
Bug Type: Filesystem function related
Operating System: Any
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-03-26 14:17:38] david at acz dot org
O_APPEND is atomic for a single write. php_log_err uses stdio, so a
log entry longer than the stdio buffer size will cause non-atomic
writes.
Try this:
for x in A B; do php -r
'ini_set("error_log","/tmp/test.log");for($i=0;$i<1;$i++)error_log(str_repeat("'$x'",5000));'
& done
[2007-03-25 14:22:20] [EMAIL PROTECTED]
Append is atomic and does not require locking.
[2007-03-22 20:39:21] david at acz dot org
Description:
The internal php_log_err function does not lock the output file. This
causes long messages to get mixed together.
--
Edit this bug report at http://bugs.php.net/?id=40897&edit=1
#40970 [Bgs]: filemtime slower on PHP5 vs PHP4
ID: 40970
User updated by: php at edwardk dot info
Reported By: php at edwardk dot info
Status: Bogus
Bug Type: Performance problem
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
I have modified the code to use, $blah = stat('.htaccess');
This file does exist, it is 161 bytes on NTFS.
PHP 4.4.6: 1.641ms
PHP 5.1.2: 108.29ms
Normally, I would be using the commands on many small files (400ish) in
the current folder to determine if any of them had changed. This was
fast enough on PHP4, but on PHP5, the same code takes much longer.
Previous Comments:
[2007-04-01 14:44:02] [EMAIL PROTECTED]
This is only the case when stat() fails.
If you change stat('.'); to stat(''); you will se that PHP5
is faster than php4. Almost 2x.
[2007-04-01 00:16:16] php at edwardk dot info
Description:
filemtime and other related functions are slower on php5 vs php4
Using PHP 5.2.1 and PHP 4.4.6 on Athlon X2 3800+, Windows 2003
the speed difference is about 50-100x slower.
Reproduce code:
---
Expected result:
Speeds should be similar
Actual result:
--
On PHP 4.4.6, it took about 1.6ms
On PHP 5.2.1 it took about 130ms
--
Edit this bug report at http://bugs.php.net/?id=40970&edit=1
#40967 [Com]: 500 Server Error on array_merge of func return
ID: 40967
Comment by: judas dot iscariote at gmail dot com
Reported By: Webbed dot Pete at gmail dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.1
New Comment:
Then tell use what the.. the getarray() function does **exactly**
Previous Comments:
[2007-03-31 15:06:34] Webbed dot Pete at gmail dot com
Description:
If I do
{
$from=getarray();
$tgt=array_merge($to,$from);
}
all is well. But if I do
{
$tgt=array_merge($to,getarray());
}
then the page blows up with a 500 internal server error (and getarray()
is never called).
I can't (yet) duplicate this as a simple test case; it only happens in
the middle of a large site source base.
This is on an Apache server (1.3.37) with PHP 5.2.1 running as CGI.
The *really* painful part is the 500 Internal Server Error, with no PHP
error messages of any kind. Made it incredibly painful to track this
down ;)
Reproduce code:
---
See above. I've not yet got a simple test case. All of the following
produce the 500 error:
$tgt=array_merge($to,getarray());
$tgt=array_merge($to,$from=getarray());
$tgt=array_merge($to,(array)getarray());
Only if the getarray() call is outside the array_merge() does it
succeed.
Expected result:
a) No error
b) Better debugability of 500 Internal Server Errors caused by PHP
Actual result:
--
500 Internal Server Error with no other message.
--
Edit this bug report at http://bugs.php.net/?id=40967&edit=1
#40954 [Opn]: Apache conection lost during php
ID: 40954 User updated by: gbasco at gmail dot com Reported By: gbasco at gmail dot com Status: Open Bug Type: Output Control Operating System: Linux 2.6.9-42.ELsmp PHP Version: 4.4.6 New Comment: PHP Version 5.2.1 System Linux xx 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 Build Date Mar 30 2007 04:29:37 Configure Command './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql' Server API Apache 2.0 Handler Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled IPv6 Support enabled Registered PHP Streams php, file, data, http, ftp Registered Stream Socket Transports tcp, udp, unix, udg Registered Stream Filters string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.* [EMAIL PROTECTED] conf]# ../bin/httpd -V Server version: Apache/2.2.4 (Unix) Server built: Mar 30 2007 04:24:59 Server's Module Magic Number: 20051115:4 Server loaded: APR 1.2.8, APR-Util 1.2.8 Compiled using: APR 1.2.8, APR-Util 1.2.8 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/usr/local/apache2" -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" Previous Comments: [2007-03-29 21:53:06] gbasco at gmail dot com I miss spelled the Apache Server version, its Apache/2.0.52 [2007-03-29 21:51:53] gbasco at gmail dot com Description: Apache Webserver 20.52 with PHP lib4 4.4.6 works fine serving large images and normal html pages. But when it executes medium large , even a file only with phpinfo(); in it, its starts displaying the page then resets and the browser clear the page giving a no conection error. In the error_log a broken pipe msg appears at the same time. [Thu Mar 29 16:21:00 2007] [info] (32)Broken pipe: core_output_filter: writing data to the network -- Edit this bug report at http://bugs.php.net/?id=40954&edit=1
