php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #37061 Zend HashTable getting corrupted
Submitted: 2006-04-12 22:03 UTC Modified: 2006-04-13 11:26 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: ceo at l-i-e dot com Assigned: tony2001 (profile)
Status: Closed Package: cURL related
PHP Version: 5.1.2 OS: FreeBSD 5.3-RELEASE
Private report: No CVE-ID: None
View Developer Edit
 [2006-04-12 22:03 UTC] ceo at l-i-e dot com 
Description:
------------
It's a LONG script, but it always ends up in:
Zend/zend_hash.c:66 (give or take lines changed in CVS)

zend_output_debug_string(1, "%s(%d) : ht=%p is being cleaned", file, line, ht);

and then it just quits, with no other error output.

I *suspect* that the root cause is in something like this:

curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1);
curl_setopt($curl, CURLOPT_URL, 'http://example.com/example.jpg');
$jpeg = curl_exec($curl);
//ASSUME that the server bounces us around with 302s and gives:
<html><head><meta http-equiv="Refresh" src="0;http://example.com/"></head><body></body></html>
curl_setopt($curl, CURLOPT_BINARYTRANSFER, 0);
curl_setopt($curl, CURLOPT_URL, 'http://example.com');
$html = curl_exec($curl);

At this point, I get warnings about $html not being zero-terminated if I try to use it, and, sure enough, it's got garbage characters at the end.

I SUSPECT that the curl handle is getting forced into non-binary mode because of the 302s and the fact that plain/text comes out at the end of that -- And I SUSPECT that this somehow gets the curl handle's "binary" status out of sync somehow with itself, and gets curl all confused.

All of this, however, is just my suspicion...  It COULD be the OCR GD stuff I'm doing...

But something is definitely corrupting thing somewhere.

Hopefully somebody who understand backtrace better than I can track it down...


Reproduce code:
---------------
http://acousticdemo.com/info.com/overture/overture.phps
http://acousticdemo.com/info.com/overture/overture.inc.phps

I am happy to provide my login/password to *@php.net if you can't reproduce and want to run this from CLI under gdb and see it in action.

I've already done that, and can reproduce it in gdb.

It just takes awhile to get to that state, and my "short" scripts are not yet causing the bug. :-(

Also happens in:
php_5.1.2 (release)
php5.1-200604071630
php5.1-200604102030

Take your pick.


Expected result:
----------------
Ideally, it would just "work" and continue on, keeping track of strings and binary strings without me worrying about it.

I'd settle for an E_ERROR for conditions where a server returns plain-text instead of binary expected.

Or even an E_ERROR when the strings are known to be corrupted.

But a "silent" failure with only C errors under --with-debug is pretty harsh.


Actual result:
--------------
Silent script end prematurely under normal CLI.

--with-debug and gdb get me this:

#0  _zend_is_inconsistent (ht=0x83e14a4, file=0x823e6b4 "/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c", line=752)
    at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:67
#1  0x081a899f in zend_hash_copy (target=0x83e0ca4, source=0x83e14a4, pCopyConstructor=0x819d0cc <zval_add_ref>, tmp=0xbfbfc950, size=4)
    at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:752
#2  0x0819d1ed in _zval_copy_ctor_func (zvalue=0x839ce64,
    __zend_filename=0x823d6b0 "/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h", __zend_lineno=45)
    at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:134
#3  0x0819da97 in _zval_copy_ctor (zvalue=0x839ce64, __zend_filename=0x823d628 "/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c",
    __zend_lineno=1009) at zend_variables.h:45
#4  0x0819ec52 in zend_error (type=2, format=0x823d488 "String is not zero-terminated (%s) (source: %s:%d)")
    at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c:1009
#5  0x0819cfb9 in _zval_dtor_func (zvalue=0x84c68a4, __zend_filename=0x823c3e0 "/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.h",
    __zend_lineno=35) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:35
#6  0x081919cb in _zval_dtor (zvalue=0x84c68a4, __zend_filename=0x823c344 "/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_execute_API.c",
    __zend_lineno=395) at zend_variables.h:35
#7  0x08191b84 in _zval_ptr_dtor (zval_ptr=0x83e0730, __zend_filename=0x823d4bc "/www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c",
    __zend_lineno=175) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_execute_API.c:395
#8  0x0819d2f7 in _zval_ptr_dtor_wrapper (zval_ptr=0x83e0730) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_variables.c:175
#9  0x081a8338 in zend_hash_clean (ht=0x83e14a4) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend_hash.c:547
#10 0x081bcae1 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd3e0) at zend_vm_execute.h:255
#11 0x081bd2f1 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd3e0) at zend_vm_execute.h:322
#12 0x081bc486 in execute (op_array=0x8387124) at zend_vm_execute.h:92
#13 0x0819ef70 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/Zend/zend.c:1109
#14 0x0815bae9 in php_execute_script (primary_file=0xbfbfeb98) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/main/main.c:1728
#15 0x08202e1b in main (argc=2, argv=0xbfbfec28) at /www/acousticdemo.com/php_cvs/php5.1-200604102030/sapi/cli/php_cli.c:1092

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-04-12 22:09 UTC] tony2001@php.net 
>5.3-RELEASE
Is it AIX 5.3 or ..?

Try to build PHP with --enable-debug and --disable-zend-memory-manager and then run it through `valgrind --tool=memcheck` (see http://valgrind.org).
And if you put the valgrind log somewhere in the net, that would give us a lot of useful information.

Though, a short but complete reproduce script would be even better.
 [2006-04-12 22:24 UTC] ceo at l-i-e dot com 
Corrected typo of OS. Sorry.
 [2006-04-12 23:06 UTC] ceo at l-i-e dot com 
Just to keep you readers posted:

Compiling --without-zend-memory-manager is easy, and it still terminates prematurely.

valgrind, however, will take some time...
From source yields:
checking for a supported CPU/OS combination... no (i386-freebsd5.3)
configure: error: Valgrind is platform specific. Sorry. Please consider doing a port.

It's in the ports tree, but I'm not root, so I've asked for it to get installed.

Or maybe I could convince ports tree to install it in my homedir somehow? I'll search for a way to do that.
 [2006-04-12 23:17 UTC] tony2001@php.net 
No need to install it in the system or use some ports.
Just grab the latest valgrind sources and compile them in your own HOME directory. IIRC latest relase compiled on FreeBSD just fine.
 [2006-04-12 23:38 UTC] ceo at l-i-e dot com 
Okay.

HERE is a short (35 lines) script which will yield:
Warning: String is not zero-terminated

I don't think the strings involved should have any problem being zero-terminated -- They are just HTML plain-text.

This MAY not solve this bug, but it's an easy avenue to explore, and MAY solve the root cause of this bug, if my suspicions are correct.

http://acousticdemo.com/binarytransfer.phps

NOTE:
You'll have to run it from CLI (or CGI) and --enable-debug to get the messages.

Note that the strings ONLY get "not zero-terminated" if you do the CURLOPT_BINARYTRANFER part of the script.

Comment out that middle section, and warnings go away.

Surely this should not behave like this, right?
 [2006-04-12 23:47 UTC] ceo at l-i-e dot com 
Errr. To be 100% clear:
The $html strings should not be non-zero-terminated.
$jpeg makes perfect sense as non-zero-terminated, to me.
 [2006-04-13 00:05 UTC] bjori@php.net 
404 not found...
 [2006-04-13 00:12 UTC] ceo at l-i-e dot com 
Jeez, I'm fumbling today.
http://acousticdemo.com/info.com/overture/binarytransfer.phps
 [2006-04-13 09:44 UTC] tony2001@php.net 
Assigned to myself - I have the patch.
 [2006-04-13 11:26 UTC] tony2001@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC