php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #26846 fpassthru() segfaults on certain files
Submitted: 2004-01-08 13:16 UTC Modified: 2004-01-19 14:12 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: djones at xtreme-eda dot com Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 4.3.4 OS: FreeBSD 4.8-RELEASE
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: djones at xtreme-eda dot com
New email:
PHP Version: OS:

 

 [2004-01-08 13:16 UTC] djones at xtreme-eda dot com 
Description:
------------
PHP configuration:

http://www.inode.org/test.php

I am running an application that sends files to the user using fpassthru().  With certain files, Apache exits with signal 11.  There does not seem to be any distinguishing characteristic between files that are sent OK and files that are not.

Reproduce code:
---------------
See http://www.inode.org/passthru.php_

The trailing underscore prevents execution so you can view the source.  The code contains paths to two files; one of which can be transferred and one that cannot.  You may transfer these files to your system to attempt reproduction. (Instructions for said transfer are provided in passthru.php)

Running the BAD file from the PHP command line appears to work correctly so this might be a PHP-Apache interaction issue.

Expected result:
----------------
With the GOOD file: you can save the document and view it.

With the BAD file: I would expect to be able to save it too.

Actual result:
--------------
With the BAD file: Apache segfaults signal 11.

I'm not sure how I can get a GDB backtrace from a running Apache instance.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-08 14:34 UTC] sniper@php.net 
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.
 [2004-01-08 20:38 UTC] iliaa@php.net 
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

Cannot verify crash with latest CVS.
 [2004-01-12 16:08 UTC] djones at xtreme-eda dot com 
I believe the problem to be at line 84 in sapi_apache2.c: 
 
    copy_str = apr_pmemdup( r->pool, str, str_length+1); 
 
This function appears to copy one more byte than required.  
It is not clear to me why this is required, as the length 
is passed explicitly (and we ought to be able to pass 
null-terminated data, e.g. Word documents!) 
 
The problem: if the source is mmap()ped and the file in 
question is exactly a multiple of the page size, then the 
extra byte refers to a page just beyond the mapping.  When 
this final byte is accessed you get a segmentation fault.  
I have verified that the segfault occurs in FreeBSD's 
memcpy() at a point where the address is at the end of the 
mapping and the remaining byte count is 1.
 [2004-01-13 05:20 UTC] sniper@php.net 
did you try the snapshot or not?
 [2004-01-19 14:12 UTC] sniper@php.net 
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.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 01:00:01 2025 UTC