From: [EMAIL PROTECTED]
Operating system: Solaris 2.7
PHP version: 4CVS-2003-02-07 (stable)
PHP Bug Type: DBM/DBA related
Bug description: With-flatfile compile option causes core dumps during make test
Compiled with GCC 3.2.1 on Solaris 2.7 to work with Apache 2.0.40. Apache
compiled with same GCC.
Testing with CLI version in sapi/cli via make test.
The SISSEGV segmentation core dump occurs with the "tests/func/005a.phpt"
only when I include the --with-flatfile option in the configure script, by
itself or in combination with any other option. Absent this flatfile
setting, no core dump occurs. I've confirmed this with numerous clean,
right from scratch reconfigures and compiles.
Within the failing test, the register_shutdown_function() call works ok.
It appears that the dump is being triggered when the time limit set by
set_time_limit() expires within the infinite for loop. I varied the time
value to set_time_limit(), but still got the core dumps. Using GDB
4.1.18, I got this backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1
(gdb) bt
#0 0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 #1
0xfeffbdfc in __sighndlr () from /usr/lib/libthread.so.1 #2 <signal
handler called>
#3 execute (op_array=0x2890b0, tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/Zend/zend_execute.c:1350
#4 0x1395fc in zend_execute_scripts (type=8, tsrm_ls=0x1dbbd0,
retval=0x0,
file_count=3) at
/opt/src/php/php4-STABLE-200302021630/Zend/zend.c:864
#5 0x1078ac in php_execute_script (primary_file=0xffbef110,
tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/main/main.c:1582
#6 0x14da14 in main (argc=2, argv=0xffbef19c)
at /opt/src/php/php4-STABLE-200302021630/sapi/cli/php_cli.c:753
Due to the infinite for loop in the failing test, subseqent core dumps
will backtrace differently depending on just where in the loop cycle the
dump occurs at. Inother words, don't expect execute in frame 3 to look
the same from trace to trace. Though its a bit of a chameleon to chase
down, I'm still on the prowl to locate exact where this is happening at.
---dave
--
Edit bug report at http://bugs.php.net/?id=22109&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22109&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22109&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22109&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22109&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22109&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=22109&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22109&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=22109&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=22109&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22109&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22109&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22109&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22109&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=22109&r=gnused
