#47920 [Bgs]: how about changing...
ID: 47920 User updated by: odarcan at gmail dot com Reported By: odarcan at gmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.3.0RC1 New Comment: i suggest you rethink this is a feature request. if all lines end with ; except for one.. and php is about to give a syntax error for the next line, you can be damn sure that a ; is missing. submit=send Previous Comments: [2009-04-08 17:59:40] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php That's not that easy, you might also miss a + or something completely different. [2009-04-08 02:44:07] odarcan at gmail dot com Description: the Parse error: syntax error, unexpected T_VARIABLE in C:\Lighty\HTDOCS\3.php on line 58 to: You forgot a ';' dear user! Reproduce code: --- ?php $a=5 $b=4; Expected result: You forgot a ';' dear user! Actual result: -- Parse error: syntax error, unexpected T_VARIABLE in C:\Lighty\HTDOCS\3.php on line 58 -- Edit this bug report at http://bugs.php.net/?id=47920edit=1
#47920 [NEW]: how about changing...
From: odarcan at gmail dot com Operating system: all PHP version: 5.3.0RC1 PHP Bug Type: Feature/Change Request Bug description: how about changing... Description: the Parse error: syntax error, unexpected T_VARIABLE in C:\Lighty\HTDOCS\3.php on line 58 to: You forgot a ';' dear user! Reproduce code: --- ?php $a=5 $b=4; Expected result: You forgot a ';' dear user! Actual result: -- Parse error: syntax error, unexpected T_VARIABLE in C:\Lighty\HTDOCS\3.php on line 58 -- Edit bug report at http://bugs.php.net/?id=47920edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47920r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47920r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47920r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47920r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47920r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47920r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47920r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47920r=needscript Try newer version: http://bugs.php.net/fix.php?id=47920r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47920r=support Expected behavior: http://bugs.php.net/fix.php?id=47920r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47920r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47920r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47920r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47920r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47920r=dst IIS Stability: http://bugs.php.net/fix.php?id=47920r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47920r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47920r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47920r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47920r=mysqlcfg
#28761 [NEW]: lines drawn with imageline() are ugly
From: odarcan at hotmail dot com Operating system: win xp PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: lines drawn with imageline() are ugly Description: i dont think this is a bug, it may be, and i dont know if reporting this here will do any good, when drawing lines in gd, other than 90degree angles; the endings of the lines always become horisontal and it looks really, REALLY cheap! it doesnt show when the lines are 1 pixel wide but when drawing thicker lines, it becomes VERY obvious, this is my greatest obstacle in my project right now, ive emailed boutell.com but got no answer. thanks, Osman Darcan Reproduce code: --- ? $im = imagecreate(400, 400) or die (Cannot Initialize new GD image stream); header (Content-type: image/png); $grey = imagecolorallocate ($im, 155, 155, 155); $blue = imagecolorallocate ($im, 0, 0, 255); $green = imagecolorallocate ($im, 0, 155, 0); imagesetthickness($im,9); imageline($im,5,5,50,50,$blue); imageline($im,50,50,100,300,$blue); imageline($im,100,300,300,40,$blue); imageline($im,5+20,5+20,50+20,50+20,$green); imageline($im,50+20,50+20,60+20,300+20,$green); imageline($im,100+20,300+20,300+20,40+20,$green); imagepng($im,,60); ? Expected result: try different values for imagesetthickness Actual result: -- you'll see that some lines look very weird.. im not sure its a bug but it's sure ugly allright.. php and gd deserves something as simple as a decent option to set thickness to lines.. shouldnt be so hard to implement? -- Edit bug report at http://bugs.php.net/?id=28761edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28761r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28761r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28761r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28761r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28761r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28761r=needscript Try newer version: http://bugs.php.net/fix.php?id=28761r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28761r=support Expected behavior: http://bugs.php.net/fix.php?id=28761r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28761r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28761r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28761r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28761r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28761r=dst IIS Stability: http://bugs.php.net/fix.php?id=28761r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28761r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28761r=float
#28761 [Opn]: lines drawn with imageline() are ugly
ID: 28761 User updated by: odarcan at hotmail dot com Reported By: odarcan at hotmail dot com Status: Open Bug Type: Feature/Change Request Operating System: win xp PHP Version: Irrelevant New Comment: clarification: the uglyness appears in the junctions of different lines when the first one's ending coords. is the second one's beginning coords., the drawn lines should be more seamless Previous Comments: [2004-06-13 06:13:25] odarcan at hotmail dot com Description: i dont think this is a bug, it may be, and i dont know if reporting this here will do any good, when drawing lines in gd, other than 90degree angles; the endings of the lines always become horisontal and it looks really, REALLY cheap! it doesnt show when the lines are 1 pixel wide but when drawing thicker lines, it becomes VERY obvious, this is my greatest obstacle in my project right now, ive emailed boutell.com but got no answer. thanks, Osman Darcan Reproduce code: --- ? $im = imagecreate(400, 400) or die (Cannot Initialize new GD image stream); header (Content-type: image/png); $grey = imagecolorallocate ($im, 155, 155, 155); $blue = imagecolorallocate ($im, 0, 0, 255); $green = imagecolorallocate ($im, 0, 155, 0); imagesetthickness($im,9); imageline($im,5,5,50,50,$blue); imageline($im,50,50,100,300,$blue); imageline($im,100,300,300,40,$blue); imageline($im,5+20,5+20,50+20,50+20,$green); imageline($im,50+20,50+20,60+20,300+20,$green); imageline($im,100+20,300+20,300+20,40+20,$green); imagepng($im,,60); ? Expected result: try different values for imagesetthickness Actual result: -- you'll see that some lines look very weird.. im not sure its a bug but it's sure ugly allright.. php and gd deserves something as simple as a decent option to set thickness to lines.. shouldnt be so hard to implement? -- Edit this bug report at http://bugs.php.net/?id=28761edit=1
#24782 [Bgs-Opn]: fread'ing with large buffers from slow pages does not work
ID: 24782 User updated by: odarcan at hotmail dot com Reported By: odarcan at hotmail dot com -Status: Bogus +Status: Open Bug Type: Network related Operating System: win xp PHP Version: 4.3.2 New Comment: i already know that the data received from the pointer can be less than given buffersize (EOF or size whichever comes first), and believe me this has absolutely NOTHING to do with my bug report. I have used php with network functions for 2.5 years and this is the first time i've come across this, read carefully. the 'page' is a slow opening php script the body of the page is not returned when doing a single fread, only headers are returned. only when putting several freads after eachother OR when sleeping before a single fread, is the body fetched. keep up the food work.. Previous Comments: [2003-07-23 19:35:18] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php reading from sockets will give you a packet sized chunk which can be less than the buffer size you requested. This is documented in the manual and has been the behaviour since sockets were introduced to PHP. Note that 4.3.0 and 4.3.1 were broken in that they would block your whole script to try to fulfill your request - breaking other peoples scripts. [2003-07-23 19:22:46] odarcan at hotmail dot com Description: $pcstring=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); is NOT the same as $string=fread ($pcpointer,5000); at least not in slow opening pages (as php scripts doing calculations) the second code only gives the headers while skipping the rest while the first shows echoed results from the php script (as it did with previous versions of php) putting a sleep(1); before the fread also solves this (for me at least). sleep(1); $string=fread ($pcpointer,5000); it has taken me 5 days to figure out what was wrong, FIVE DAYS... -- Edit this bug report at http://bugs.php.net/?id=24782edit=1
#24782 [NEW]: fread'ing with large buffers from slow pages does not work
From: odarcan at hotmail dot com Operating system: win xp PHP version: 4.3.2 PHP Bug Type: Network related Bug description: fread'ing with large buffers from slow pages does not work Description: $pcstring=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); $pcstring.=fread ($pcpointer,1000); is NOT the same as $string=fread ($pcpointer,5000); at least not in slow opening pages (as php scripts doing calculations) the second code only gives the headers while skipping the rest while the first shows echoed results from the php script (as it did with previous versions of php) putting a sleep(1); before the fread also solves this (for me at least). sleep(1); $string=fread ($pcpointer,5000); it has taken me 5 days to figure out what was wrong, FIVE DAYS... -- Edit bug report at http://bugs.php.net/?id=24782edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24782r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24782r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24782r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24782r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24782r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24782r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24782r=support Expected behavior: http://bugs.php.net/fix.php?id=24782r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24782r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24782r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24782r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24782r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24782r=dst IIS Stability: http://bugs.php.net/fix.php?id=24782r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24782r=gnused
#21319 [Fbk-Csd]: the PHP Script Interpreter crashes.
ID: 21319 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 4.3.0 New Comment: the crashes seem to have ended! nice talking to you all.. Previous Comments: [2003-01-29 15:11:39] [EMAIL PROTECTED] Hey guys, thank you for checking into this. I just tryed the latest snapshot (2003-01-29 12:00 GMT-8) and... [drumroll...] the problem seems fixed! I even used an ob_start() and ob_end_flush() whithin the for loop and got a clean execution. As for me, you can close this one out! Thanks again, and keep up the good work. - Alex, http://alexnow.com [2003-01-29 00:03:18] [EMAIL PROTECTED] You should be using ..edit=2 (the 'Edit Submission' link) Anyway, did the snapshot fix the problem for you or not? [2003-01-28 11:00:25] [EMAIL PROTECTED] I've memorized the url :) (didn't look at the email) and if i'd edit the submission the status would be set to something other than what you recently set it to.. [2003-01-28 05:06:55] [EMAIL PROTECTED] Okay..btw. Why did you again use that 'Add comment' link? The URL in the email you get does not point there..? (just curious :) And close this if your stuff also works with the snapshot.. [2003-01-28 03:16:01] [EMAIL PROTECTED] Alex' script does not crash with the latest snapshot, checking my own code.. 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/21319 -- Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [Com]: the PHP Script Interpreter crashes.
ID: 21319
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: windows xp
PHP Version: 4.3.0
New Comment:
Alex' script does not crash with the latest snapshot,
checking my own code..
Previous Comments:
[2003-01-27 02:50:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-01-27 02:18:59] [EMAIL PROTECTED]
in order to set the status, i seem to have to edit this...
thank you alex, this does crash php, i hope it's the same problem.
[2003-01-25 03:31:31] [EMAIL PROTECTED]
Hello, I've run into what seems to be the same problem.
I also have a way to reproduce it:
WinXP HE (NT 5.1), Apache 1.3.27, PHP 4.3.0 on CGI-FCGI
?php
error_reporting(E_ALL ^ E_WARNING);
set_time_limit(10);
for($x=1;$x1;$x++){
$f = fsockopen('127.0.0.1',$x,$errno,$errstr,1);
print Port $x: ;
print($f)?'Success!':'Failed!';
print br /;
}
?
Almost every single time it causes an HTTP 500 Error
This from the server's log:
[Sat Jan 25 01:00:23 2003] [error] [client 127.0.0.1] Premature end of
script headers: {PATH TO PHP}/php.exe
[Sat Jan 25 01:00:23 2003] [error] [client 127.0.0.1] FATAL:
erealloc(): Unable to allocate 10 bytes
You may need to refresh that page a few times to get the Program has
crashed and needs to close/Report to MS window. When this happens, the
browser hangs until you click something on that dialog box.
btw, I've also increased the timeout to fsockopen(), while the error
still occures, it seems easier to reproduce with lower timeouts.
I have the files appcompat.txt, manifest.txt and php.exe.mdmp generated
by the error reporting app available upon request.
Could this also be related to http://bugs.php.net/bug.php?id=21262 ?
Thank you for your time.
- Alex, http://alexnow.com
[2003-01-24 01:00:02] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2003-01-08 13:34:41] [EMAIL PROTECTED]
Hi,
sorry I haven't been able to isolate in sort, but I found out this much
:
Installing 4.3.0 by default enables the php_iisfunc.dll extension in
the php.ini file. (Using Windows XP and IIS).
I'm not aware of using this functionality and when I remove the use of
the php_iisfunc.dll (comment the line) the error doen't occur.
Hopefully this can be of some use.
/Rene'
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/21319
--
Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [Com]: the PHP Script Interpreter crashes.
ID: 21319
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: windows xp
PHP Version: 4.3.0
New Comment:
I've memorized the url :) (didn't look at the email) and if i'd edit
the submission the status would be set to something other than what you
recently set it to..
Previous Comments:
[2003-01-28 05:06:55] [EMAIL PROTECTED]
Okay..btw. Why did you again use that 'Add comment' link?
The URL in the email you get does not point there..?
(just curious :)
And close this if your stuff also works with the snapshot..
[2003-01-28 03:16:01] [EMAIL PROTECTED]
Alex' script does not crash with the latest snapshot,
checking my own code..
[2003-01-27 02:50:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-01-27 02:18:59] [EMAIL PROTECTED]
in order to set the status, i seem to have to edit this...
thank you alex, this does crash php, i hope it's the same problem.
[2003-01-25 03:31:31] [EMAIL PROTECTED]
Hello, I've run into what seems to be the same problem.
I also have a way to reproduce it:
WinXP HE (NT 5.1), Apache 1.3.27, PHP 4.3.0 on CGI-FCGI
?php
error_reporting(E_ALL ^ E_WARNING);
set_time_limit(10);
for($x=1;$x1;$x++){
$f = fsockopen('127.0.0.1',$x,$errno,$errstr,1);
print Port $x: ;
print($f)?'Success!':'Failed!';
print br /;
}
?
Almost every single time it causes an HTTP 500 Error
This from the server's log:
[Sat Jan 25 01:00:23 2003] [error] [client 127.0.0.1] Premature end of
script headers: {PATH TO PHP}/php.exe
[Sat Jan 25 01:00:23 2003] [error] [client 127.0.0.1] FATAL:
erealloc(): Unable to allocate 10 bytes
You may need to refresh that page a few times to get the Program has
crashed and needs to close/Report to MS window. When this happens, the
browser hangs until you click something on that dialog box.
btw, I've also increased the timeout to fsockopen(), while the error
still occures, it seems easier to reproduce with lower timeouts.
I have the files appcompat.txt, manifest.txt and php.exe.mdmp generated
by the error reporting app available upon request.
Could this also be related to http://bugs.php.net/bug.php?id=21262 ?
Thank you for your time.
- Alex, http://alexnow.com
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/21319
--
Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [NoF-Opn]: the PHP Script Interpreter crashes.
ID: 21319
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: windows xp
PHP Version: 4.3.0
New Comment:
in order to set the status, i seem to have to edit this...
thank you alex, this does crash php, i hope it's the same problem.
Previous Comments:
[2003-01-25 03:31:31] [EMAIL PROTECTED]
Hello, I've run into what seems to be the same problem.
I also have a way to reproduce it:
WinXP HE (NT 5.1), Apache 1.3.27, PHP 4.3.0 on CGI-FCGI
?php
error_reporting(E_ALL ^ E_WARNING);
set_time_limit(10);
for($x=1;$x1;$x++){
$f = fsockopen('127.0.0.1',$x,$errno,$errstr,1);
print Port $x: ;
print($f)?'Success!':'Failed!';
print br /;
}
?
Almost every single time it causes an HTTP 500 Error
This from the server's log:
[Sat Jan 25 01:00:23 2003] [error] [client 127.0.0.1] Premature end of
script headers: {PATH TO PHP}/php.exe
[Sat Jan 25 01:00:23 2003] [error] [client 127.0.0.1] FATAL:
erealloc(): Unable to allocate 10 bytes
You may need to refresh that page a few times to get the Program has
crashed and needs to close/Report to MS window. When this happens, the
browser hangs until you click something on that dialog box.
btw, I've also increased the timeout to fsockopen(), while the error
still occures, it seems easier to reproduce with lower timeouts.
I have the files appcompat.txt, manifest.txt and php.exe.mdmp generated
by the error reporting app available upon request.
Could this also be related to http://bugs.php.net/bug.php?id=21262 ?
Thank you for your time.
- Alex, http://alexnow.com
[2003-01-24 01:00:02] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2003-01-08 13:34:41] [EMAIL PROTECTED]
Hi,
sorry I haven't been able to isolate in sort, but I found out this much
:
Installing 4.3.0 by default enables the php_iisfunc.dll extension in
the php.ini file. (Using Windows XP and IIS).
I'm not aware of using this functionality and when I remove the use of
the php_iisfunc.dll (comment the line) the error doen't occur.
Hopefully this can be of some use.
/Rene'
[2003-01-08 13:27:31] [EMAIL PROTECTED]
Don't quote me on this, but I believe this bug is related to several
other bugs which have been reported since 4.3.0.
There *appears* to be an issue with garbage collection when the
interpreter is in the final stages of shutdown (script exit).
I can't be more specific because it's related to a portion of the PHP
Core which I'm not qualified to debug and is a heisenbug in the most
classical sense.
Rest assured though that there ARE developers working on this issue.
Any additional information you can provide such as backtraces and
short, simple pieces of code which reproduce the error will aid in the
isolation and irradication of this bug.
[2003-01-07 17:46:07] [EMAIL PROTECTED]
In order to look into the problem we would need a short and complete
script that reproduces the problem. Without that there is very little
information to go on.
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/21319
--
Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [Com]: the PHP Script Interpreter crashes.
ID: 21319 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 4.3.0 New Comment: i withdraw my speculation about the die construct beeing the problem; i have a script that does.. something (checks urls downloads them via fsockopen) 20 times in a for loop from 1 to 20.. sometimes there is an error when downloading, and naturally, to move on to the next url, i use the continue construct (or whatever it's called). I run my scripts from the command prompt with a batch script that runs PHP SCRIPTNAME.PHP over and over in an infinite loop.. since the php script is executed in a loop, it wouldn't really matter if you call continue or die since the next url in the database would be processed either way.. Now this should be interesting; NOT A SINGLE CRASH, has ever occurred ever since i've started using die instead of continue on download errors.. and you're still not responding.. osman darcan Previous Comments: [2003-01-07 13:56:48] [EMAIL PROTECTED] I am using Apache and yes, it may be the same problem, what i don't understand is why these guys dont respond, i would really like to know if they're into the problem or if they haven't even read my messages yet.. a simple we're looking into the problem would be fine.. but nooo.. [2003-01-07 03:19:18] [EMAIL PROTECTED] Hi, i'm getting the same errors on two different Windows XP Pro installations. I'll try to get some more information (xp related addresses from the crash) but from the head i remember that the problem is php_iisfunc.dll. The web'server (PWS) serves seems the pages correctly but at the end of the session the error occurs. I can reproduce the error everytime in multiple scenarios. I know there is another reported bug related to Apache under WinXP (php_apachefunc.dll) and i won't be surprised if this is actually a related issue. [2003-01-04 05:08:38] [EMAIL PROTECTED] Hi, i've just upgraded to php 4.3.0 and i'm pleased the fsockopen timeout problem has been fixed.. but now to something more serious: the php script interpreter crashes, windows takes over command and says PHP Script Interpreter has encountered a problem and needs to close. We are sorry for the inconvenience. and you get to choose to send or dont send an error report to microsoft (please tell microsoft about this problem it says) this happens very often... i suspect this has something to do with the die() construct and/or the mysql interface... because the crash often comes directly after a erroneus mysql query a it's die-error-message... but not always.. i think.. sometimes no error is produced by php at all.. i want to be of more help by telling you how to reproduce the error but i haven't figured out how to figure out how to tell you to reproduce the error.. [2003-01-02 15:52:59] [EMAIL PROTECTED] i have by the way only 500 MB of ram [2003-01-02 15:51:55] [EMAIL PROTECTED] FATAL: emalloc(): Unable to allocate 1936028514 bytes is this php's fault or the os'? 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/21319 -- Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [Com]: the PHP Script Interpreter crashes.
ID: 21319 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 4.3.0 New Comment: I am using Apache and yes, it may be the same problem, what i don't understand is why these guys dont respond, i would really like to know if they're into the problem or if they haven't even read my messages yet.. a simple we're looking into the problem would be fine.. but nooo.. Previous Comments: [2003-01-07 03:19:18] [EMAIL PROTECTED] Hi, i'm getting the same errors on two different Windows XP Pro installations. I'll try to get some more information (xp related addresses from the crash) but from the head i remember that the problem is php_iisfunc.dll. The web'server (PWS) serves seems the pages correctly but at the end of the session the error occurs. I can reproduce the error everytime in multiple scenarios. I know there is another reported bug related to Apache under WinXP (php_apachefunc.dll) and i won't be surprised if this is actually a related issue. [2003-01-04 05:08:38] [EMAIL PROTECTED] Hi, i've just upgraded to php 4.3.0 and i'm pleased the fsockopen timeout problem has been fixed.. but now to something more serious: the php script interpreter crashes, windows takes over command and says PHP Script Interpreter has encountered a problem and needs to close. We are sorry for the inconvenience. and you get to choose to send or dont send an error report to microsoft (please tell microsoft about this problem it says) this happens very often... i suspect this has something to do with the die() construct and/or the mysql interface... because the crash often comes directly after a erroneus mysql query a it's die-error-message... but not always.. i think.. sometimes no error is produced by php at all.. i want to be of more help by telling you how to reproduce the error but i haven't figured out how to figure out how to tell you to reproduce the error.. [2003-01-02 15:52:59] [EMAIL PROTECTED] i have by the way only 500 MB of ram [2003-01-02 15:51:55] [EMAIL PROTECTED] FATAL: emalloc(): Unable to allocate 1936028514 bytes is this php's fault or the os'? [2003-01-02 15:24:33] [EMAIL PROTECTED] this just in: FATAL: erealloc(): Unable to allocate 59 bytes and then again: BOOM cool eh? 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/21319 -- Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [Sus]: the PHP Script Interpreter crashes.
ID: 21319 User updated by: [EMAIL PROTECTED] -Summary: the PHP Script Interpreter crashes Reported By: [EMAIL PROTECTED] Status: Suspended Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 4.3.0 New Comment: Hi, i've just upgraded to php 4.3.0 and i'm pleased the fsockopen timeout problem has been fixed.. but now to something more serious: the php script interpreter crashes, windows takes over command and says PHP Script Interpreter has encountered a problem and needs to close. We are sorry for the inconvenience. and you get to choose to send or dont send an error report to microsoft (please tell microsoft about this problem it says) this happens very often... i suspect this has something to do with the die() construct and/or the mysql interface... because the crash often comes directly after a erroneus mysql query a it's die-error-message... but not always.. i think.. sometimes no error is produced by php at all.. i want to be of more help by telling you how to reproduce the error but i haven't figured out how to figure out how to tell you to reproduce the error.. Previous Comments: [2003-01-02 15:52:59] [EMAIL PROTECTED] i have by the way only 500 MB of ram [2003-01-02 15:51:55] [EMAIL PROTECTED] FATAL: emalloc(): Unable to allocate 1936028514 bytes is this php's fault or the os'? [2003-01-02 15:24:33] [EMAIL PROTECTED] this just in: FATAL: erealloc(): Unable to allocate 59 bytes and then again: BOOM cool eh? [2003-01-02 11:51:16] [EMAIL PROTECTED] I AM STILL WAITING FOR YOUR COMMENTS WAKE UP PLEASE [2003-01-02 07:07:18] [EMAIL PROTECTED] what kind of information do you need additionally, i dont know if i may be able to reproduce the crash (my script DOES crash all the time but i dont know what causes it) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21319 -- Edit this bug report at http://bugs.php.net/?id=21319edit=1
#21319 [NEW]: the PHP Script Interpreter crashes
From: [EMAIL PROTECTED] Operating system: windows xp PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: the PHP Script Interpreter crashes Hi, i've just upgraded to php 4.3.0 and i'm pleased the fsockopen timeout problem has been fixed.. but now to something more serious: the php script interpreter crashes, windows takes over command and says PHP Script Interpreter has encountered a problem and needs to close. We are sorry for the inconvenience. and you get to choose to send or dont send an error report to microsoft (please tell microsoft about this problem it says) this happens very often... i suspect this has something to do with the die() construct and/or the mysql interface... because the crash often comes directly after a erroneus mysql query a it's die-error-message... but not always.. i think.. sometimes no error is produced by php at all.. i want to be of more help by telling you how to reproduce the error but i haven't figured out how to figure out how to tell you to reproduce the error.. -- Edit bug report at http://bugs.php.net/?id=21319edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21319r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21319r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21319r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21319r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21319r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21319r=support Expected behavior: http://bugs.php.net/fix.php?id=21319r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21319r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21319r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21319r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21319r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21319r=dst IIS Stability: http://bugs.php.net/fix.php?id=21319r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21319r=gnused
#21193 [NEW]: fsockopen timeout does not work
From: [EMAIL PROTECTED] Operating system: not interesting PHP version: 4.2.3 PHP Bug Type: Sockets related Bug description: fsockopen timeout does not work Hi, this problem has been reported SEVERAL times here but they have almost always been closed because of no feedback there's also this big problem with fsockopen, it hangs.. while it hangs the timeout doesn't work.. and neither does the php script timeout.. if the php script timout worked.. the fsockopen hanging wouldnt be a very big problem (for me) since the script exection would stop.. but just so that you know: i'm using php 4.2.3 and since the last 1-2 years, the fsockopen has hanged the script, and for the last year (1-2) the timeout has not been working either. it is now December 26, 2002 and the both the hanging and infunctional timeout still haunts me today. i have used several versions of php (4.0.6(?)-4.2.3) and several computers (mostly windows xp, but i think the problem exists on linux as well), and the hanging has been around all the time. and today before i even write code that involves fsockopen, i start considering every other option so that i dont have to write a program that i know will be crippled from birth. thank you for your time, Osman Darcan look at: http://bugs.php.net/bug.php?id=10765 http://bugs.php.net/bug.php?id=7420 http://bugs.php.net/bug.php?id=12360 -- Edit bug report at http://bugs.php.net/?id=21193edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21193r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21193r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21193r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21193r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21193r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21193r=support Expected behavior: http://bugs.php.net/fix.php?id=21193r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21193r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21193r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21193r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21193r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21193r=dst IIS Stability: http://bugs.php.net/fix.php?id=21193r=isapi
#21194 [NEW]: compiler time constant $_BUG_ROWNUMBER
From: [EMAIL PROTECTED] Operating system: windows xp PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: compiler time constant $_BUG_ROWNUMBER Hi, bug tracking can be very difficult when you dont know where the problem is. i propose that you create a special constant or variable like: $_BUG_ROWNUMBER and this variable (or const) will be given (at execution time) a value that represents the position OF the variable IN the php document. for example, here the output from the die contstruct would be error on line 3 ? echo blabla; mysql_query(wrong query) or die (error on line .$_BUG_ROWNUMBER); ? as you can see this would be very useful when debugging as you otherwise have to change every error message so that they will become a unique message and that you can be sure on which line it is.. thanks for your time, Osman Darcan -- Edit bug report at http://bugs.php.net/?id=21194edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21194r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21194r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21194r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21194r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21194r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21194r=support Expected behavior: http://bugs.php.net/fix.php?id=21194r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21194r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21194r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21194r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21194r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21194r=dst IIS Stability: http://bugs.php.net/fix.php?id=21194r=isapi
