Wez Furlong said:

>>   /* call the constructor */
>>   if ( call_user_function(NULL, &object, ctor_fn, ctor_retval, 0,
>> NULL)
>
> Looks correct too.  However, I would use call_user_function_ex, which
> relieves you of the burden of creating a retval (among other things).

The API for call_user_function... changed (new parameter was added) so the
instructions in the docs are totally borked.  Someone else figured out how
to make it work and added a helpful note to the page for using
call_user_function() (not _ex()) so I just followed their hints without
using my brain and reading the source.  It seems to work.

Thanks for the tip though, I'll look into it once I overcome this bigger
nastiness.

>> Note also that the variables which are getting corrupted are simple
>> strings, not even zvals.  Here is how I'm setting the value of
>> serverId, which is one of those getting corrupted:
>>
>>     add_property_string(return_value, "serverId", serverId, TRUE);
>> efree(serverId);
>
> In this case, it is better to do this:
>
>     add_property_string(return_value, "serverId", serverId, FALSE);
> and not use the serverId again.

Thanks for your very clear explanation (which I've snipped out).  That's more
or less as I understood it, but now I feel more confident.   I doubt you
expected that to be related to my bug, but I changed all such instances
anyway, and of course the problem persists.

> > Did you --enable-debug in your development build?  If not, I strongly
> recommend that you do, as it will help detect overruns in emalloc'd
> memory.  This is a great way to track down the lines of code that are at
> fault.

Yes I've been developing with debug enabled, it's a real lifesaver
if--like me--you're not perfect.  It also helped me to understand how Zend
manages memory, since it would tell me if I neededed to efree() something
or if it was taken care of by Zend.

But this raises an interesting point...  I accidentally re-ran configure
_without_ --enable-debug, did a make clean and make, and suddenly my main
bug went away!  return_value is no longer getting corrupted in the same
way, and I am not getting a segfault when trying to access my object's
member variable!  But let's not get too excited here...

I say "no longer getting corrupted in the same way" because it is getting
corrupted... but in a very strange way which I encountered several months
ago, and used an ugly hack to get around, rather than properly solving the
issue.

If you ask me, this is stranger yet.  If you recall from my original post,
I am trying to return a "serverId" object member which contains a value
such as "N^VESoDMN(107)".  Again, right before my PHP_FUNCTION returns
control to the script, this value is perfect.  When I DON'T use
--enable-debug, and the serverId is NOT getting completely clobbered, the
value that is returned by $table->serverId is not "N^VESoDMN(107)".  It is
"N^VESoDMN'107)"

This is not a random thing.  It is very consistent--I have several
PHP_FUNCTIONs that return serverIds, either with RETVAL_STRING or as a
member of a more complex object, and server IDs are always in a similar
format, a string ending with a parenthesized integer.  Yet EVERY time, the
"(" is replaced by a single quote.

Does this make ANY sense to anyone out there?  Is there some hidden hack
within Zend that is being triggered by this string pattern (perhaps the ^
followed by "(" in a string?) and which causes Zend to replace a
open-paren with a single-quote?

To be perfectly clear, no other character is ever changed, and the ( is
always changed in the same way.  Aside from that, the serverId is valid
and if I
replace the ' with a (, the server recognizes the ID as valid when I send
it back.

> The other thing to try is valgrind - it is possible that some of your
> non-zend-api code is misbehaving, and valgrind will help you find that
> problem code.

Another excellent suggestion, and I tried it this morning, even with the
-v option.  Result: nothing.  No warnings except to tell me I was about to
have a segfault.  I haven't read the whole valgrind manual, but unless you
can think of some command-line option that could be helpful, I don't think
that's going to get me anywhere.

I don't know if the " ( becomes ' " glitch offers any clue as to what
could be happening, but if not, I guess I am doomed to step interminably
through php/Zend in gdb, and become far more intimately familiar with the
inner workings of Zend than I would really like.

And to be clear, once I re-enabled debug in configure, my data is being
completely corrupted just as before.  Does this offer any clues?  I have
come across some #IFDEFs etc. in the source, where the debugging code is
activated, but before I go and look at every such instance for clues,
maybe someone else has an idea?

Thanks again for your assistance.

Bamboozled,
Eric




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to