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]
