qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: proton 0.10 blocker
Date Fri, 17 Jul 2015 21:04:19 GMT
On Fri, Jul 17, 2015 at 12:47 PM, Gordon Sim <gsim@redhat.com> wrote:

> On 07/17/2015 08:15 PM, Rafael Schloming wrote:
>
>> On Fri, Jul 17, 2015 at 11:56 AM, Gordon Sim <gsim@redhat.com> wrote:
>>
>>  On 07/17/2015 07:17 PM, Rafael Schloming wrote:
>>>
>>>  Given this I believe the incref/decref pair is indeed running into
>>>> problems
>>>> when being invoked from inside a finalizer. I'd be curious if an
>>>> alternative fix would work. I suspect you could replace the additional
>>>> conditions you added to the if predicate with this:
>>>>
>>>>     pn_refcount(endpoint) > 0
>>>>
>>>>
>>> If the refcount is *not* 0, what does the incref/decref sequence
>>> accomplish?
>>>
>>
>>
>> I believe the answer to this is the same as the answer I just posted on
>> the
>> other thread, i.e. the incref may trigger the incref hook (see
>> pn_xxx_incref in engine.c), and this in turn may update the endpoint state
>> and adjust the refcount accordingly. The decref may then end up finalizing
>> the object.
>>
>
> Right, understood now.
>
> Unfortunately replacing the additional conditions with just that check on
> the refcount doesn't prevent the crash though.
>

Doh, not the result I was hoping for. Does it yield the same stack trace as
before?

--Rafael

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message