On 2020/05/20 21:54, Jun Omae wrote:
> On Mon, May 18, 2020 at 8:25 AM Yasuhito FUTATSUKI <futatuki_at_poem.co.jp> wrote:
>>
>> On 2020/05/18 2:51, Johan Corveleyn wrote:
>>> On Sun, May 17, 2020 at 3:43 PM Jun Omae <jun66j5_at_gmail.com> wrote:
>>
>>>> Assertion for negative ref count is raised from test_conflict
>>>> (client.SubversionClientTestCase).
>>>> 1.10.x through trunk have the issue.
>>
>>> Thank you for the thorough research!
>>> I'm not sure what can be done further about this. Perhaps others can
>>> chime in here.
>>
>> Jun and I found it is caused by long existing bug on SWIG Python bindings,
>> since before swig-py3 branch was merged (thus this bug exists on 1.13.x
>> and 1.10.3 branches). On SWIG Python bindings, APIs which have multiple
>> apr_pool_t * argments cannot be wrapped correctly.
>>
>> If we call such a wrapper function with specifying multiple pool argments
>> explicitly, only last one is used for *all* apr_pool_t * arguments when
>> it calls C API.
>
> Created global-py-pool-ref-count.diff patch to solve the multiple apr_pool *
> pointers issue in Python bindings.
>
> Verified no assertions while running check-swig-py with the following
> environments:
>
> - (Python 3.5.2, 3.6.10, 3.7.7, 3.8.3, 3.9.0a6) x (SWIG 4.0.1)
> - (Python 2.7.12) x (SWIG 1.3.40, 2.0.12, 3.0.12)
Thank you very much!
With this patch, I confirmed that each apr_pool * argment in C API supplied
from corresponding pool object if it is supplied by the Python wrapper function
(by reading _wrap_svn_client_propget5() in svn_client.c generated by
SWIG 3.0.12, for Python 2).
However, I couldn't confirm that the "_parent_pool" attribute in wrapper
object returned by wrapper function point to "result_pool" object in such case,
yet. I doubt it still points to "scratch_pool" object because variable
"_global_py_pool" points to "scratch_pool" object when both of "result_pool"
and "scratch_pool" are provided on such APIs.
> Investigating generated C code for Perl and Ruby bindings from SWIG, it seems
> that all bindings have the same issue which only apr_pool_t * pointer passed
> as last argument is used.
svn_swig_pl_get_pool(), svn_swig_py_get_pool(), svn_swig_rb_get_pool(),
which is used in "default" typemaps for apr_pool_t *, only examine whether the
last argment passed by wrapper function is pool wrapper object or not, and "in"
typemaps for apr_pool_t * don't see $input in Perl and Ruby bindings.
Thus I think they have same issue, too.
Cheers,
--
Yasuhito FUTATSUKI <futatuki_at_poem.co.jp>/<futatuki_at_yf.bsdclub.org>
Received on 2020-05-22 01:03:10 CEST