php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #1513 segfault... malloc related
Submitted: 1999-06-08 22:18 UTC Modified: 1999-06-18 11:57 UTC
From: tbrown at baremetal dot com Assigned:
Status: Closed Package: Reproducible Crash
PHP Version: 3.0.9 OS: linux 2.0.x (redhat 5.2)
Private report: No CVE-ID: None
 [1999-06-08 22:18 UTC] tbrown at baremetal dot com
./configure --with-msql=/usr/local/Minerva --with-mysql=/usr/ --with-dbase=yes -
-enable-debug=yes --enable-track-vars=yes --enable-magic-quotes=yes --enable-for
ce-cgi-redirect=yes --enable-memory-limit=yes

(yup, that's a CGI based compile...)

backtrack (ignore the jdk paths...)

#0  0x400946a1 in ?? () from /usr/lib/jdk-1.1.6/i686/green_threads/libc.so.6
#1  0x400956df in ?? () from /usr/lib/jdk-1.1.6/i686/green_threads/libc.so.6
#2  0x400b92f5 in ?? () from /usr/lib/jdk-1.1.6/i686/green_threads/libc.so.6
#3  0x400b7504 in ?? () from /usr/lib/jdk-1.1.6/i686/green_threads/libc.so.6
#4  0x805fc1a in _efree (ptr=0x811fa78) at alloc.c:173
#5  0x805cd33 in pval_destructor (pvalue=0x811f608) at variables.c:89
#6  0x805abd3 in _php3_hash_destroy (ht=0x810d828) at php3_hash.c:637
#7  0x805d288 in assign_to_variable (result=0xbfffede4, var_ptr=0xbffff044, 
    expr=0xbffff064, func=0) at variables.c:80
#8  0x8051bca in phpparse () at language-parser.y:498
#9  0x8059792 in php3_parse (yyin=0x8102028) at main.c:1541
#10 0x8059f3e in main (argc=2, argv=0xbffffc98) at main.c:1850


I don't own the source code so I can't post it here, the above backtrace is probably not the one you're used to... it's from setting MALLOC_CHECK_=2 and isn't the actual crash, but instead it's libc calling abort() because 
there's been a "mistake" that it's detected... (see the end of man malloc) 

I'll put the binary and the core file at ftp://baremetal.com/php.bug/

From my quick look at things, it seems that PHP is destroying the results of a mysql query that got stored in a hash? A quick grep shows that the script programmer is using

sql.php:  $result=mysql($dbName, $query);
sql.php:  $b_advertiser=mysql_result($result, 0, "b_advertiser");

constructs, as well as the 
sql.php:    if ($count=@mysql_NumRows( $result ) ) {
sql.php:        $cols  =  mysql_num_fields(  $result  );
sql.php:        if($row  =  mysql_fetch_array( $result ) )

functions... (damn, but it would be easier to format a nice bug report if this text area box was bigger/wider...

-Tom

I've asked the programmer for a short script the reproduces the problem... he has suggested that it may be tied into the mysql functions...

Obviously, let me know if there's anything else I can provide?

Ahh, one other point, the trace above is with DEBUG=0 ...
with DEBUG=1 PHP detects some troubles, but unfortunately the C library can't ... I can build it any way you want... 

Ahh, yes, PHP does identify a problem with DEBUG=1...

---------------------------------------
Block 0x08125DF0 status at variables.c:77:
Beginning:      Overrun (magic=0x4011D910, expected=0x7312F8DC)
      End:      Unknown
---------------------------------------

what else can I provide? This originally showed up in a recently installed 3.0.8 and I was quite disappointed to see it in 3.0.9 too :-(

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-06-09 03:52 UTC] tbrown at baremetal dot com
As per a suggestion from:
"Bonis, Wim" <bonis@solution-service.de>

I changed the --enable-magic-quotes to no, and the exremely reproduceable 
core dump vanished... :-)

Thanks Wim!

-Tom


 [1999-06-18 11:57 UTC] sas at cvs dot php dot net
fixed in CVS
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 19 02:01:35 2024 UTC