#31048 [Com]: PHP crashes if fpassthru() is used along with fseek()

2005-04-12 Thread thomas at mbox371 dot swipnet dot se 
 ID:   31048
 Comment by:   thomas at mbox371 dot swipnet dot se
 Reported By:  john dot wellesz at teaser dot fr
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.9 STABLE and WINXPSP2
 PHP Version:  5.0.2
 New Comment:

It works now. It might have been fix of bug 32553 that did it for me.


Previous Comments:


[2005-04-01 14:04:31] thomas at mbox371 dot swipnet dot se

I am having this problem as well with 5.0.4 and latest apache2 on
windows 2003. I also have the problem that even without fseek the file
submission stops after a minute or so (streaming mp3).
I wanted 5.0.4 for the bugfix of the XML parser but there always seems
to be one or more new bugs that stops me from upgrading :( file
passthru has been broken several times now :( I have debuged my
passthru/readfile code several hours in total now and i'm not doing it
again. I cant even make myself to diagnose the problem, just hoping
that someone else does it.. I will revert to 5.0.3 instead. PHP is too
confusing :(



[2004-12-24 01:00:07] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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.



[2004-12-16 09:51:27] [EMAIL PROTECTED]

You can actually, type bt on the GDB prompt after it crashed. That
will make a backtrace which is very useful for us.

Thanks



[2004-12-16 00:02:19] john dot wellesz at teaser dot fr

OK, The bug doesn't happen in php 5.0.3 (at least on windows XP sp2).

I've been able to generate a core dump but without the --enable-debug
parameter, plus I've made a kdump.

First the kdump (I've called ob_start() just before the call to 
fpassthru() since it didn't change anything and make the trace
shorter):

ktrace is launched just before the line:

$handle = fopen($loginfo, rb);

Kdump Result:

67985 php  RET   read 0
 67985 php  CALL  close(0x3)
 67985 php  RET   close 0
 67985 php  CALL  wait4(0x10994,0xbfbfd9dc,0,0)
 67985 php  RET   wait4 67988/0x10994
 67985 php  CALL  nanosleep(0xbfbfdab8,0xbfbfdab0)
 67985 php  RET   nanosleep 0
 67985 php  CALL  __getcwd(0xbfbfd5d0,0x400)
 67985 php  RET   __getcwd 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2/j2072
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2/j2072/pub
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2/j2072/pub/www.2072productions.com
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/
_j2/j2072/pub/www.2072productions.com/fpassthru_crash_test_file
 67985 php  RET   lstat 0
 67985 php  CALL  open(0x8205e8c,0,0x1b6)
 67985 php  NAMI  /home/
_j2/j2072/pub/www.2072productions.com/fpassthru_crash_test_file
 67985 php  RET   open 3
 67985 php  CALL  fstat(0x3,0x817892c)
 67985 php  RET   fstat 0
 67985 php  CALL  lseek(0x3,0,0,0,0x1)
 67985 php  RET   lseek 0
 67985 php  CALL  lseek(0x3,0,0x30d40,0,0)
 67985 php  RET   lseek 20/0x30d40
 67985 php  CALL  break(0x8222000)
 67985 php  RET   break 0
 67985 php  CALL  fstat(0x3,0x817892c)
 67985 php  RET   fstat 0
 67985 php  CALL  mmap(0,0x493e3,0x1,0x1,0x3,0,0x30d40,0)
 67985 php  RET   mmap 677834048/0x2866ed40
 67985 php  CALL  break(0x826e000)
 67985 php  RET   break 0
 67985 php  PSIG  SIGBUS SIG_DFL
 67985 php  NAMI  /var/cores/php


Now the result of GDB:

#0  0x284212a6 in memcpy () from /usr/lib/libc.so.4
(gdb) #0  0x284212a6 in memcpy () from /usr/lib/libc.so.4
Cannot access memory at address 0xbfbfba2c.
(gdb) 


I can't do better, I hope this will be sufficient :-)



[2004-12-14 02:18:24] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.

Read the link

#31048 [Com]: PHP crashes if fpassthru() is used along with fseek()

2005-04-01 Thread thomas at mbox371 dot swipnet dot se 
 ID:   31048
 Comment by:   thomas at mbox371 dot swipnet dot se
 Reported By:  john dot wellesz at teaser dot fr
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.9 STABLE and WINXPSP2
 PHP Version:  5.0.2
 New Comment:

I am having this problem as well with 5.0.4 and latest apache2 on
windows 2003. I also have the problem that even without fseek the file
submission stops after a minute or so (streaming mp3).
I wanted 5.0.4 for the bugfix of the XML parser but there always seems
to be one or more new bugs that stops me from upgrading :( file
passthru has been broken several times now :( I have debuged my
passthru/readfile code several hours in total now and i'm not doing it
again. I cant even make myself to diagnose the problem, just hoping
that someone else does it.. I will revert to 5.0.3 instead. PHP is too
confusing :(


Previous Comments:


[2004-12-24 01:00:07] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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.



[2004-12-16 09:51:27] [EMAIL PROTECTED]

You can actually, type bt on the GDB prompt after it crashed. That
will make a backtrace which is very useful for us.

Thanks



[2004-12-16 00:02:19] john dot wellesz at teaser dot fr

OK, The bug doesn't happen in php 5.0.3 (at least on windows XP sp2).

I've been able to generate a core dump but without the --enable-debug
parameter, plus I've made a kdump.

First the kdump (I've called ob_start() just before the call to 
fpassthru() since it didn't change anything and make the trace
shorter):

ktrace is launched just before the line:

$handle = fopen($loginfo, rb);

Kdump Result:

67985 php  RET   read 0
 67985 php  CALL  close(0x3)
 67985 php  RET   close 0
 67985 php  CALL  wait4(0x10994,0xbfbfd9dc,0,0)
 67985 php  RET   wait4 67988/0x10994
 67985 php  CALL  nanosleep(0xbfbfdab8,0xbfbfdab0)
 67985 php  RET   nanosleep 0
 67985 php  CALL  __getcwd(0xbfbfd5d0,0x400)
 67985 php  RET   __getcwd 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2/j2072
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2/j2072/pub
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/_j2/j2072/pub/www.2072productions.com
 67985 php  RET   lstat 0
 67985 php  CALL  lstat(0xbfbfd180,0xbfbfd0d0)
 67985 php  NAMI  /home/
_j2/j2072/pub/www.2072productions.com/fpassthru_crash_test_file
 67985 php  RET   lstat 0
 67985 php  CALL  open(0x8205e8c,0,0x1b6)
 67985 php  NAMI  /home/
_j2/j2072/pub/www.2072productions.com/fpassthru_crash_test_file
 67985 php  RET   open 3
 67985 php  CALL  fstat(0x3,0x817892c)
 67985 php  RET   fstat 0
 67985 php  CALL  lseek(0x3,0,0,0,0x1)
 67985 php  RET   lseek 0
 67985 php  CALL  lseek(0x3,0,0x30d40,0,0)
 67985 php  RET   lseek 20/0x30d40
 67985 php  CALL  break(0x8222000)
 67985 php  RET   break 0
 67985 php  CALL  fstat(0x3,0x817892c)
 67985 php  RET   fstat 0
 67985 php  CALL  mmap(0,0x493e3,0x1,0x1,0x3,0,0x30d40,0)
 67985 php  RET   mmap 677834048/0x2866ed40
 67985 php  CALL  break(0x826e000)
 67985 php  RET   break 0
 67985 php  PSIG  SIGBUS SIG_DFL
 67985 php  NAMI  /var/cores/php


Now the result of GDB:

#0  0x284212a6 in memcpy () from /usr/lib/libc.so.4
(gdb) #0  0x284212a6 in memcpy () from /usr/lib/libc.so.4
Cannot access memory at address 0xbfbfba2c.
(gdb) 


I can't do better, I hope this will be sufficient :-)



[2004-12-14 02:18:24] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.

Read the link; it tells you how to make a backtrace; without one we
can't fix the bug.



[2004-12-13 20:21:27] john dot wellesz at teaser dot fr

#29801 [Com]: Using readfile() to send large files causes PHP to hang

2004-09-13 Thread thomas at mbox371 dot swipnet dot se 
 ID:   29801
 Comment by:   thomas at mbox371 dot swipnet dot se
 Reported By:  WPinegar at healthtech dot net
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows Server 2003
 PHP Version:  5.0.1
 New Comment:

the problem exists in php 4.3.8 as well.


Previous Comments:


[2004-08-24 20:14:31] thomas at mbox371 dot swipnet dot se

latest apache2, Windows 2000 server,  php 5.0.0/5.0.1/5.0.2-cvs.. same
problem with all these configurations. When streaming files  5mb thru
php there is timeouts. Also, it seems not to work to stream these files
over a slower connections (0.5mbit) at all (stops after a few seconds)
when it works better on a 100mbit lan.



[2004-08-23 19:47:40] WPinegar at healthtech dot net

Description:

Attempting to use readfile() to send large (over 250MB) binary objects
causes PHP 5.0.1 to hang or the web server to send a 302 error. 
Reverting back to PHP 4.3.8 resolves the issue.

Using fopen() and fpassthru() only makes the issue worse.

We are using IIS 6 and the PHP ISAPI script engine.

Reproduce code:
---
header(Content-Type: application/force-download);
header(Content-Type: application/octet-stream);
header(Content-Type: application/download);
header(Content-Disposition: attachment;
filename=.basename($filename).;);
header(Content-Transfer-Encoding: binary);
header(Content-Length: .filesize($filename));

readfile($filename); 
exit(); 


Expected result:

PHP 5 has an issue with sending large binary files.  This should be
resolved.






-- 
Edit this bug report at http://bugs.php.net/?id=29801edit=1

#29801 [Com]: Using readfile() to send large files causes PHP to hang

2004-08-24 Thread thomas at mbox371 dot swipnet dot se 
 ID:   29801
 Comment by:   thomas at mbox371 dot swipnet dot se
 Reported By:  WPinegar at healthtech dot net
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows Server 2003
 PHP Version:  5.0.1
 New Comment:

latest apache2, Windows 2000 server,  php 5.0.0/5.0.1/5.0.2-cvs.. same
problem with all these configurations. When streaming files  5mb thru
php there is timeouts. Also, it seems not to work to stream these files
over a slower connections (0.5mbit) at all (stops after a few seconds)
when it works better on a 100mbit lan.


Previous Comments:


[2004-08-23 19:47:40] WPinegar at healthtech dot net

Description:

Attempting to use readfile() to send large (over 250MB) binary objects
causes PHP 5.0.1 to hang or the web server to send a 302 error. 
Reverting back to PHP 4.3.8 resolves the issue.

Using fopen() and fpassthru() only makes the issue worse.

We are using IIS 6 and the PHP ISAPI script engine.

Reproduce code:
---
header(Content-Type: application/force-download);
header(Content-Type: application/octet-stream);
header(Content-Type: application/download);
header(Content-Disposition: attachment;
filename=.basename($filename).;);
header(Content-Transfer-Encoding: binary);
header(Content-Length: .filesize($filename));

readfile($filename); 
exit(); 


Expected result:

PHP 5 has an issue with sending large binary files.  This should be
resolved.






-- 
Edit this bug report at http://bugs.php.net/?id=29801edit=1