|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[1999-06-09 03:52 UTC] tbrown at baremetal dot com
[1999-06-18 11:57 UTC] sas at cvs dot php dot net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Dec 17 08:00:01 2025 UTC |
./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 :-(