|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22109 With-flatfile compile option causes core dumps during make test
Submitted: 2003-02-07 09:01 UTC Modified: 2003-02-10 13:54 UTC
From: dwkoehler at comcast dot net Assigned:
Status: Closed Package: DBM/DBA related
PHP Version: 4CVS-2003-02-07 (stable) OS: Solaris 2.7
Private report: No CVE-ID: None
 [2003-02-07 09:01 UTC] dwkoehler at comcast dot net
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/
(gdb) bt
#0  0xff165758 in aiosigcancelhndlr () from /usr/lib/ #1  0xfeffbdfc in __sighndlr () from /usr/lib/ #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.



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-07 14:03 UTC]
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 20:03 UTC] dwkoehler at comcast dot net
Here is the ldd output you asked for: =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/ =>	 /usr/lib/

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:

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

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!
 [2003-02-10 12:54 UTC] dwkoehler at comcast dot net
I downloaded a late Sunday evening snapshot and did not receive any of the mentioned core dumps as in previous posts.  I've also reviewed the information provided at and learned that the flatfile interface is deprecated.  Based on this, there seems no need to persist with this as a bug report.  Go ahead and close it.
 [2003-02-10 13:04 UTC]
Closed per user-request. (and seems like fixed too..?)

 [2003-02-10 13:54 UTC]
Just another question what is your system: 32 or 64bit?

To dba switches: You can see that information by either
the function "dba_handlers()" or "php -i" or the output of 
the function "phpinfo()" (the last one creates layoted 
html output if called from your internet browser).

And --with-dbXXX or other related dba switch turns DBA
extension on. If you add --enable-dba then all default
submodules which do not require external libraries are
used, too (flatfile, cdb, cdb_make).

Hope this helps.

Maybe i reorganize the configure messages so that they
do not confuse in the way you described it.

 [2003-02-10 14:49 UTC] dwkoehler at comcast dot net
The system is a 32 bit Sun Ultra 1 168 MHz Sparc workstation loaded with 32 bit Solaris 7, 256MB memory, and 2 internal 2GB SCSI disks.  All development software loaded on machine such as compilers and configuration ( autoconf stuff ) came either from the Sunfreeware site as a package or as a tarballs from GNU's site.  

Would appreciate the re-org'g of the configure messages.

Note I have other questions regarding configure option usage and would like to know how or to whom I should submit them.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 28 01:01:31 2024 UTC