Hi Eric,
return_value is already allocated for you in a PHP_FUNCTION() that is
called by the engine (or via call_user_fuction(_ex)), as you have
guessed.
> PHP_FUNCTION(eo_table)
Looks correct.
> /* 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).
> > Hints: make sure that your zvals are correctly initialized (there are
> > some big differences between ALLOC_ZVAL and MAKE_STD_ZVAL).
>
> One resets the refcount and the is_ref flag, the other doesn't. All the
> variables I'm dealing with are "fresh", not references to pre-existing
> zvals.
Yes, and this is important when the zval is passed into the engine
again. If those flags and refcounts are incorrect, you will experience
problems like those you have described. However, from what you have
shown here, it looks like your code is correct.
> 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.
You need to specify TRUE if:
- the data was not allocated with the PHP memory allocator
- the data is constant.
- the data is on the stack.
- the data was allocated with malloc
- the data is "owned" by some other zval or object that expects to efree
it.
> Thanks in advance for any insights you can give. This is really
> frustrating. If you want to know how I am doing anything else, let me
> know.
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.
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.
--Wez.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
