php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22182 apd segfaults with auto_prepend_file
Submitted: 2003-02-12 03:41 UTC Modified: 2003-05-25 21:54 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: chregu@php.net Assigned: gschlossnagle (profile)
Status: No Feedback Package: PEAR related
PHP Version: 4.3.0 OS: Linux
Private report: No CVE-ID: None
 [2003-02-12 03:41 UTC] chregu@php.net
The subject says it.

If I have a auto_prepend_file ini directive in .htaccess (didn't check in php.ini), apd segfaults.

It's the latest released apd-version (0.4p2)

If I move the to-be-prepended file to the php file and do "include()", it works without problems

Otherwise: great product :)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-12 14:34 UTC] gschlossnagle@php.net
A very trivial test doesn't reproduce for me.  Can you 
supply a minimal testcase and or a gdb backtrace?
 [2003-02-16 10:00 UTC] chregu@php.net
here we go:

the 2 php files just have 
print "hello world";

.htaccess:
php_value auto_prepend_file "config.inc.php"

backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402a009e in zend_get_executed_lineno ()
    at /opt/cvs/php4.3/Zend/zend_execute_API.c:269
269                     return active_opline->lineno;

(gdb) bt
#0  0x402a009e in zend_get_executed_lineno ()
    at /opt/cvs/php4.3/Zend/zend_execute_API.c:269
#1  0x40315a15 in apd_execute (op_array=0x81851a4)
    at /root/tmp/apd-0.4p2/php_apd.c:738
#2  0x402a7a43 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /opt/cvs/php4.3/Zend/zend.c:925
#3  0x40282588 in php_execute_script (primary_file=0xbffff840)
    at /opt/cvs/php4.3/main/main.c:1582
#4  0x402b80be in apache_php_module_main (r=0x817f11c, display_source_mode=0)
    at /opt/cvs/php4.3/sapi/apache/sapi_apache.c:55
#5  0x402b8b03 in send_php (r=0x817f11c, display_source_mode=0, filename=0x0)
    at /opt/cvs/php4.3/sapi/apache/mod_php4.c:610
#6  0x402b8ca2 in send_parsed_php (r=0x817f11c)
    at /opt/cvs/php4.3/sapi/apache/mod_php4.c:625
#7  0x08073e79 in ap_invoke_handler ()
#8  0x0808964f in process_request_internal ()
#9  0x080896b6 in ap_process_request ()
#10 0x080800c6 in child_main ()
#11 0x08080281 in make_child ()
#12 0x080803fc in startup_children ()
#13 0x08080a8d in standalone_main ()
#14 0x080812fc in main ()
#15 0x400b29f1 in __libc_start_main () from /lib/libc.so.6


if I do an include in the first php, it works fine.

chregu






 [2003-04-28 03:22 UTC] arnaud@php.net
Assigning to georges whois already monitoring it.
 [2003-04-28 03:41 UTC] arnaud@php.net
As pointed out by alan, assign to username and not email.
 [2003-04-28 03:59 UTC] arnaud@php.net
changing status (alan got me again ;)
 [2003-05-13 10:33 UTC] dholmes at jccc dot net
I'm getting this as well, but I don't have any auto_prepend_file set.  For example, my hello.php looks like this:

<?php
apd_set_pprof_trace();
print "auto_prepend_file = ";
var_dump(ini_get('auto_prepend_file'));
print "hello world\n";
?>

runnning it gives me:
auto_prepend_file = bool(false)
hello world

Yet, here is my gdb session (as apache module)
(gdb) file /usr/local/bin/php
Reading symbols from /usr/local/bin/php...done.
(gdb) set args ./pprofp -u  /tmp/dump_dir/dholmes/pprof.22140
(gdb) run
Starting program: /vol1/local/bin/php ./pprofp -u  /tmp/dump_dir/dholmes/pprof.22140
[New Thread 16384 (LWP 22752)]

Trace for /vol1/home/dholmes/site_html/www.remote-clean/htdocs/hello.php
Total Elapsed Time =    0.01
Total System Time  =    0.00
Total User Time    =    0.00


         Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
100.0  0.00  0.00   0.00  0.00   0.00  0.00     1   0.0000    0.0000           88 var_dump
100.0  0.01  0.01   0.00  0.00   0.00  0.00     1   0.0000    0.0000          160 ini_get
100.0  0.00  0.00   0.00  0.00   0.00  0.00     1   0.0000    0.0000            0 main

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22752)]
0x0811a65e in zend_get_executed_lineno () at /vol1/home/dholmes/build/php-4.3.1/Zend/zend_execute_API.c:269
269                     return active_opline->lineno;
(gdb) bt
#0  0x0811a65e in zend_get_executed_lineno () at /vol1/home/dholmes/build/php-4.3.1/Zend/zend_execute_API.c:269
#1  0x40017dec in apd_execute () from /usr/local/lib/php/extensions/no-debug-non-zts-20020429/apd.so
#2  0x0811af0f in call_user_function_ex (function_table=0x81788c0, object_pp=0x0, function_name=0x81fe5dc, retval_ptr_ptr=0xbfffe838, 
    param_count=0, params=0x81be39c, no_separation=1, symbol_table=0x0) at /vol1/home/dholmes/build/php-4.3.1/Zend/zend_execute_API.c:557
#3  0x0811aa1f in call_user_function (function_table=0x8178d08, object_pp=0x0, function_name=0x81fe5dc, retval_ptr=0xbfffe870, param_count=0, 
    params=0x81c3090) at /vol1/home/dholmes/build/php-4.3.1/Zend/zend_execute_API.c:399
#4  0x080a09f8 in user_shutdown_function_call (shutdown_function_entry=0x81fe764)
    at /vol1/home/dholmes/build/php-4.3.1/ext/standard/basic_functions.c:2013
#5  0x08125e39 in zend_hash_apply (ht=0x81fecbc, apply_func=0x80a09bc <user_shutdown_function_call>)
    at /vol1/home/dholmes/build/php-4.3.1/Zend/zend_hash.c:688
#6  0x080a0c8d in php_call_shutdown_functions () at /vol1/home/dholmes/build/php-4.3.1/ext/standard/basic_functions.c:2094
#7  0x080fc3bf in php_request_shutdown (dummy=0x0) at /vol1/home/dholmes/build/php-4.3.1/main/main.c:924
#8  0x08132df5 in main (argc=4, argv=0xbffff054) at /vol1/home/dholmes/build/php-4.3.1/sapi/cli/php_cli.c:803
#9  0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6

I'm using RH 8.0 and PHP 4.3.1 (custom build, obviously).

I get the same thing when I call it with my cli version of php. ( /usr/local/bin/php -e -f ./hello.php ) I even commented out every line of my php.in and it still segfaults.  

Here is my trace file as well....maybe there is something special about it?
$ cat  pprof.22927
#Pprof [APD] v0.9
hz=100
caller=/vol1/home/dholmes/site_html/www.remote-clean/htdocs/hello.php

END_HEADER
! 1 /vol1/home/dholmes/site_html/www.remote-clean/htdocs/hello.php
& 1 main 2
+ 1 1 2
- 2 20008
& 3 ini_get 1
+ 3 1 4
- 3 20152
& 4 var_dump 1
+ 4 1 4
@ 1 0 0
- 4 20264
- 5 20320
END_TRACE
total_user=1
total_sys=0
total_wall=9
END_FOOTER

All that said...it's still giving me a TON of great info that I didn't have before.  THANKS!!!
 [2003-05-13 15:02 UTC] dholmes at jccc dot net
Don't know why, but adding an exit(0); anywhere AFTER the main loop gets rid of the segfault.  In other words if the file just runs out of script it segfaults. If it dies with "reason" it's OK. ;-)

I've tried:
  Moving all functions to the top.
  Adding whitespace AFTER the last ?>
  Using adb (in socket mode) to break...step...segfault
  changing /usr/bin/env php to /usr/local/bin/php

The only thing I found to work was adding exit(0); to the script.  Any idea why?  I can run other things (like that hello world) from cli and segfault.  Hmmm...

P.S. Now that I have played with the breakpoint/echo/continue/ stuff...I LOVE IT!!!
 [2003-05-13 15:04 UTC] dholmes at jccc dot net
Oh, shoot...That's:
I can run other things (like that hello world) from cli and
_NOT_ segfault. 

Sorry about that.
 [2003-05-15 14:35 UTC] gschlossnagle@php.net
Strange.  I can't get this to duplicate.  But what I find 
more curious is that you seem to be saying that your script 
that dumps trace works fine, but that it is pprofp that 
segfaults.  pprofp is just a userspace php program (it 
doesn't interact with the engine at all).  Is this correct?

Can you try upgrading your php to current cvs (4.3.2rc2) 
and recompiling apd?
 [2003-05-20 12:31 UTC] sniper@php.net
And time goes by.. :)

 [2003-05-25 21:54 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-2024 The PHP Group
All rights reserved.
Last updated: Sun Oct 06 13:01:27 2024 UTC