ID:               22109
 Comment by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 Status:           Open
 Bug Type:         DBM/DBA related
 Operating System: Solaris 2.7
 PHP Version:      4CVS-2003-02-07 (stable)
 New Comment:

Here is the ldd output you asked for:

        libcrypt_i.so.1 =>       /usr/lib/libcrypt_i.so.1
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.1 =>     /usr/lib/libm.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libthread.so.1 =>        /usr/lib/libthread.so.1
        /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1

I tried to run your print_r( dba_handlers() ) but I got an undefined
function error.  That only shows up in the code with the --enable-dba
option, an option not used in my configure script.  I included it, then
re-configured and did a full re-compile.  Still had the core dump
afterwards.

The output from the print_r command is:

Array
( [flatfile] => 1.0, $Revision: 1.5.2.3 $ ) )

Side question:  is there a configure reference or rule that states if
one option is present, these other options should be as well.  As in
the above, is the enable-dba option required in the presence of the
--with-dbXX or --with-flatfile options. Without the --enable-dba
present, I saw the message "checking whether DBA interface is
enabled=yes" in the config output.  This led me to believe that DBA was
enabled.  That was not the case based on your email and the subsequent
config output "checking whether DBA is enabled=yes" showed up right
before the earlier mentioned one.  I'm new to PHP so this seems
ambiguous to me!


Previous Comments:
------------------------------------------------------------------------

[2003-02-07 14:03:25] [EMAIL PROTECTED]

Could you please send the outputs of "ldd php" and if
you used shared builds then the ldd output of any loaded
php module, too. And then i'd like to see the ouput of
"php -r 'print_r(dba_handlers(1));'" if you did not use 
a cvs version then you must omit the parameter "1".


------------------------------------------------------------------------

[2003-02-07 09:01:33] [EMAIL PROTECTED]

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 this bug report at http://bugs.php.net/?id=22109&edit=1

Reply via email to