Re: Segfault when assigning a reference variable
| From: | JGM | Date: | Mon, 10 Mar 2014 00:58:40 +0000 |
| Subject: | Re: Segfault when assigning a reference variable | ||
| References: | 1 2 3 4 5 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-11622@lists.php.net to get a copy of this message | ||
> I haven't fully checked, but the suspicious part for me is
> ZVAL_STRING(arguments[0], (char*) buffer, 0);
> I assume that on
> $buffer = fread($this->image, $bufsize);
> $buffer tries to free its contents in order to be overwritten, but the
> buffer passed to wxInputStream_php::OnSysRead may not be freed by
> PHP. I assume simply passing a NULL zval to the function would be
> enough.
>
You rock! Thats exactly what was happening. After testing with your
recommendations the engine doesn't segfaults. Now I have to fix some code
generator virtual methods related issues in order to finally support this
feature.
> Some other unrelated notes on things I saw:
>
>
> You are calling zend_call_function(). this is no ZEND_API so depending
> on compiler flags etc. it is not exported and not callable from the
> extensions .so/.dll file.
>
> The usage of static bool is_php_user_space_implemented is suspicious.
> Is there never a chance that the method at first does not exist and a
> user provides it lateron?
>
> In memcpy ((void*) buffer, (void*) Z_STRVAL_P(arguments[0]),
> Z_STRLEN_P(arguments[0])); you assume that the arguments[0] zval will
> still be a string, if it is passed y ref this is not guaranteed. The
> user might do $buffer = NULL; (or an object with a __toString()). Also
> you don't verify that the buffer is large enough (the user might
> ignore $bufsize).
>
> In return (size_t) Z_LVAL_P(return_value); you aren't verifying the
> type either. If the user by mistake returns a string with the
> contents this will misbehave. You also don't check whether the
> returned length matches the information from the return value. Thus
> the consumer of wxInputStream_php::OnSysRead can't rely on that size.
>
Thanks for all your feedback, I will try to implement all that type
checking in the code generator.
> Your extension will have its own peculiarities anyway, just because PHP
> itself is responsible for memory management as opposed to C/C++.
> Generally, a PHP extension can't have exactly the same API as a C/C++
> library. (Especially, if it performs some kind of memory management.)
>
> I suppose you'll provide some docs for the extension. I guess a
> user will refer to _your_ docs, not the wxWidgets's C++ API. Then I
> can't find any purpose for making exact copy of C++ API here in PHP.
Actually wxWidgets is so big that it would be impossible for this miserable
guy (me) to provide all the documentation. I wrote some automatic reference
generator so people can have an idea of the classes that are binded, and in
fact the idea is that people use wxWidgets official documentation as much
as possible as I described here: http://wxphp.org/reference/index.html