ID: 6827 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: mSQL related Operating System: Sun Solaris 5.7 PHP Version: 4.0.2 Assigned To: zeev New Comment: Fixed in the CVS Previous Comments: ------------------------------------------------------------------------ [2000-12-13 10:29:04] [EMAIL PROTECTED] A backtrace of the crash, snapshot from yesterday. Program received signal SIGSEGV, Segmentation fault. zend_hash_find (ht=0x1bf5d0, arKey=0x0,nKeyLength=1,pData=0xffbec764) at zend_hash.c:852 852 zend_hash.c: No such file or directory. (gdb) bt #0 zend_hash_find (ht=0x1bf5d0, arKey=0x0, nKeyLength=1,pData=0xffbec764) at zend_hash.c:852 #1 0xf1ac4 in zend_fetch_dimension_address_inner () #2 0xe5828 in zend_fetch_dimension_address () #3 0xe8960 in execute () #4 0xedeb4 in execute () #5 0xb6bb0 in zend_execute_scripts (type=8, file_count=3) at zend.c:729 #6 0x33110 in php_execute_script (primary_file=0xffbef9e8) at main.c:1221 #7 0x31060 in main (argc=1, argv=0xffbefa74) at cgi_main.c:738 (gdb) ------------------------------------------------------------------------ [2000-12-12 18:31:09] [EMAIL PROTECTED] User feedback: ----------- I just downloaded and installed the latest snapshot - php 4.0.5-dev, and the result is the same - fails at the same location with a segmentation fault and core dump. Is it possible that there's an overflow of some sort created when msql_result gets a NULL value for a particular column? The NULL value in this case is retrieved much earlier than the point of failure, and that value is not used in the final piece of executed code. However, it does fail processing an msql_result loop when the row pointer is 0, so perhaps the previous msql_result with the NULL value caused an overflow that somehow affected a later msql_result even with a different table. ------------ There is another bug report of this, #7301 which is now marked as duplicate for this one. It has example scripts. --Jani ------------------------------------------------------------------------ [2000-12-07 11:40:38] [EMAIL PROTECTED] Assigning this to me as I'm trying to figure out this one.. --Jani ------------------------------------------------------------------------ [2000-11-03 20:26:53] [EMAIL PROTECTED] Does this still happen when using latest snapshot from snaps.php.net ?? (and without the optimizer) --Jani ------------------------------------------------------------------------ [2000-10-10 19:08:58] [EMAIL PROTECTED] User feedback: ----------- Sorry, but I'm unable to create a short script that reproduces the problem, but it continues to fail consistently when I use php4 to display information from certain rows in a database even though those same rows display fine with php3. I've looked them over and see no special characters or anything else to make the failing rows look unusual. In fact if I change 1 specific column from a NULL to any single character value, the script works fine with php4 as well. Other rows containing even more data display properly, but any row that has a NULL in that 1 specific column displays incorrectly at a point before the data from that column is referenced. If I try to reproduce just that small piece of the script in a test script, it works ok. Any other suggestions? ------------- No suggestions at the moment. --Jani ------------------------------------------------------------------------ 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/?id=6827 Edit this bug report at http://bugs.php.net/?id=6827&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]