Bug #1513: segfault... malloc related
| From: | tbrown at baremetal dot com | Date: | Wed, 09 Jun 1999 02:18:17 +0000 |
| Subject: | Bug #1513: segfault... malloc related | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-6741@lists.php.net to get a copy of this message | ||
From: tbrown@baremetal.com
Operating system: linux 2.0.x (redhat 5.2)
PHP version: 3.0.9
PHP Bug Type: Reproduceable crash
Bug description: segfault... malloc related
./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 :-(