|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #37061 Zend HashTable getting corrupted
Submitted: 2006-04-12 22:03 UTC Modified: 2006-04-13 11:26 UTC
Avg. Score:3.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: ceo at l-i-e dot com Assigned: tony2001
Status: Closed Package: cURL related
PHP Version: 5.1.2 OS: FreeBSD 5.3-RELEASE
Private report: No CVE-ID:
 [2006-04-12 22:03 UTC] ceo at l-i-e dot com
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, '');
$jpeg = curl_exec($curl);
//ASSUME that the server bounces us around with 302s and gives:
<html><head><meta http-equiv="Refresh" src="0;"></head><body></body></html>
curl_setopt($curl, CURLOPT_BINARYTRANSFER, 0);
curl_setopt($curl, CURLOPT_URL, '');
$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:

I am happy to provide my login/password to * 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)

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/", line=752)
    at /www/
#1  0x081a899f in zend_hash_copy (target=0x83e0ca4, source=0x83e14a4, pCopyConstructor=0x819d0cc <zval_add_ref>, tmp=0xbfbfc950, size=4)
    at /www/
#2  0x0819d1ed in _zval_copy_ctor_func (zvalue=0x839ce64,
    __zend_filename=0x823d6b0 "/www/", __zend_lineno=45)
    at /www/
#3  0x0819da97 in _zval_copy_ctor (zvalue=0x839ce64, __zend_filename=0x823d628 "/www/",
    __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/
#5  0x0819cfb9 in _zval_dtor_func (zvalue=0x84c68a4, __zend_filename=0x823c3e0 "/www/",
    __zend_lineno=35) at /www/
#6  0x081919cb in _zval_dtor (zvalue=0x84c68a4, __zend_filename=0x823c344 "/www/",
    __zend_lineno=395) at zend_variables.h:35
#7  0x08191b84 in _zval_ptr_dtor (zval_ptr=0x83e0730, __zend_filename=0x823d4bc "/www/",
    __zend_lineno=175) at /www/
#8  0x0819d2f7 in _zval_ptr_dtor_wrapper (zval_ptr=0x83e0730) at /www/
#9  0x081a8338 in zend_hash_clean (ht=0x83e14a4) at /www/
#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/
#14 0x0815bae9 in php_execute_script (primary_file=0xbfbfeb98) at /www/
#15 0x08202e1b in main (argc=2, argv=0xbfbfec28) at /www/


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-04-12 22:09 UTC]
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
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]
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

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.

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]
404 not found...
 [2006-04-13 00:12 UTC] ceo at l-i-e dot com
Jeez, I'm fumbling today.
 [2006-04-13 09:44 UTC]
Assigned to myself - I have the patch.
 [2006-04-13 11:26 UTC]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Wed Apr 16 10:02:09 2014 UTC