#22182 [Fbk->NoF]: apd segfaults with auto_prepend_file

From: 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

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