On Thu, 13 Feb 2003 09:02:44 -0800, Eric Lambart wrote:
> Second of all, I have narrowed the problem down a bit. It has nothing
> to do with parentheses or single-quotes (surprise!). Seriously... I
> just observed it mangling another string, but what seemed stranger yet,
> it changed "\037N^VESOBJ(4)" to "\037N^VESOBJ(3)" (this is output from
> gdb, so that's ASCII octal 37, which isn't a printable character and
> didn't show up in my previous console output).
>
> So what does this have in common with changing "\037N^VESoDMN(107)" to
> "\037N^VESoDMN'107)"? Simple: it is the 11th character of the string
> that is getting changed. Moreover, it is getting decremented by one.
> Just as 3 precedes 4 in the ASCII table, ' precedes ). These strings
> that are getting mangled are not the same variables... not the same
> zvals or memory locations or anything.
OK, another update, although I fear I am just adding noise to the list.
Not sure if anyone is reading this thread!
Further investigation on my part has revealed a workaround which "fixes"
this ONE problem: if I use erealloc() to make my string just ONE byte
longer, the string does not get corrupted.
I first suspected this had nothing to do with actually extending the
string, but that the pointer was getting assigned to a completely new
address; but I have disproved that by printing the pointer address before
and after the erealloc(), which can remain unchanged and the problem
nevertheless goes away.
If this solved the problem, this would be an acceptable workaround for me
at this point. But the problem of the other object field getting
corrupted remains:
php_var_dump() from C:
object(eo_table)(10) {
["serverId"]=>
string(15) "N^VESoDMN(192)"
["rows"]=>
int(0)
["cols"]=>
int(0)
["namedCols"]=>
bool(false)
["errorText"]=>
string(0) ""
["errorItem"]=>
string(0) ""
["errorId"]=>
int(0)
["flags"]=>
int(0)
["colNames"]=>
NULL
["table"]=>
NULL
}
var_dump() from PHP script immediately afterwards:
object(eo_table)(10) {
["serverId"]=>
string(15) "N^VESoDMN(192)"
["rows"]=>
&UNKNOWN:0
["cols"]=>
int(0)
["namedCols"]=>
bool(false)
["errorText"]=>
string(0) ""
["errorItem"]=>
string(0) ""
["errorId"]=>
int(0)
["flags"]=>
int(0)
["colNames"]=>
NULL
["table"]=>
NULL
}
As you can see, the "rows" field is becoming undefined. Again, here I
have found another clue.
If I repeat the add_property_long() for "rows", like this:
add_property_long(return_value, "rows", rows);
add_property_long(return_value, "rows", rows);
"rows" is OK, but the "&UNKNOWN:0" moves to the next field ("cols")
If I repeat both, exactly like this,
add_property_long(return_value, "rows", rows);
add_property_long(return_value, "rows", rows);
add_property_long(return_value, "cols", cols);
add_property_long(return_value, "cols", cols);
...no data is getting corrupted... AT THE MOMENT.
I don't trust this. I shouldn't have to trust this. It's not the
ugliest hack, but it's very much a hack. I really think something in
either zend_hash.c is mishandling the object's hash table...
or in the case of the string getting corrupted, perhaps it's something in
zend_alloc.c or somewhere within the memory manager/garbage collector.
At this point, can anyone give me any reason to doubt that the problem
lies within the Zend engine? Please refer to my earlier posts on this
thread for more (though less-informed and -investigated) details.
This is all very strange to me, ESPECIALLY the 11th-character thing.
Again, I am compiling this extension into PHP 4.3.0.
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.1)
Intel P4 CPU
Thanks for your time--and for Wez and others on the dev team, thanks for
your work on Zend/PHP!
Eric
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
