#22182 [Fbk->NoF]: apd segfaults with auto_prepend_file
| From: | sniper@php.net | Date: | Mon, 26 May 2003 02:54:57 +0000 |
| Subject: | #22182 [Fbk->NoF]: apd segfaults with auto_prepend_file | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-16694@lists.php.net to get a copy of this message | ||
ID: 22182
Updated by: sniper@php.net
Reported By: chregu@php.net
-Status: Feedback
+Status: No Feedback
Bug Type: PEAR related
Operating System: Linux
PHP Version: 4.3.0
Assigned To: gschlossnagle
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-05-20 12:31:27] sniper@php.net
And time goes by.. :)
------------------------------------------------------------------------
[2003-05-15 14:35:01] 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-13 15:04:17] 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-13 15:02:51] 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 10:33:01] 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!!!
------------------------------------------------------------------------
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/22182
--
Edit this bug report at http://bugs.php.net/?id=22182&edit=1