#22182 [Fbk]: apd segfaults with auto_prepend_file

From: Date: Tue, 20 May 2003 17:31:28 +0000
Subject: #22182 [Fbk]: apd segfaults with auto_prepend_file
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-16529@lists.php.net to get a copy of this message
ID: 22182 Updated by: sniper@php.net Reported By: chregu@php.net Status: Feedback Bug Type: PEAR related Operating System: Linux PHP Version: 4.3.0 Assigned To: gschlossnagle New Comment: And time goes by.. :) Previous Comments: ------------------------------------------------------------------------ [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!!! ------------------------------------------------------------------------ [2003-04-28 03:59:15] arnaud@php.net changing status (alan got me again ;) ------------------------------------------------------------------------ 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

« previous php.pear.dev (#16529) next »