Re: cvs: php-src(PHP_5_3) /ext/phar phar.c phar_internal.h phar_object.c tar.c util.c zip.c
| From: | Greg Beaver | Date: | Wed, 29 Apr 2009 18:18:28 +0000 |
| Subject: | Re: cvs: php-src(PHP_5_3) /ext/phar phar.c phar_internal.h phar_object.c tar.c util.c zip.c | ||
| References: | 1 2 3 4 | Groups: | php.cvs |
| Request: | Send a blank email to php-cvs+get-57384@lists.php.net to get a copy of this message | ||
Antony Dovgal wrote:
> On 29.04.2009 17:50, Greg Beaver wrote:
>
>> Oh good - you can reproduce it! The segfault is not related to the
>> commit, as you can see from the line in question (line 315 of
>> phar_file_action is a zval_ptr_dtor of EG(return_value_ptr_ptr), which
>> has nothing to do with streams).
>>
>
> Well, I don't remember seeing it before.
>
Hi,
This could be because the fatal_error_webphar.phpt test was committed
only 1 day before the commit you did see?
>> I found this segfault on my system using apache 2.2 with the test script
>> and added the fatal_error_webphar test to attempt to reproduce it, but
>> the test in question passes using cgi on my system.
>>
>
> It segfaults with CGI here (but no with CLI?).
>
It is a web-based test, which means it only runs with the CGI sapi.
>> Would you be able
>> to forward bt + valgrind errors to Dmitry? This is a ZE2 problem that
>> phar's cleanup triggers, and so I need to know how to rewrite the
>> cleanup so it doesn't trigger the segfault (or ZE2 needs to be fixed,
>> whichever is the real problem).
>>
>
> Ok, I'll ping him.
>
thanks very much. I can get a backtrace using gdb, but no valgrind for
the apache crash, although I haven't tried running the server via
valgrind. Does anyone know if this is even possible to do with a
forking server?
Thanks,
Greg