On 17 July 2015 at 23:32, Gordon Sim <g...@redhat.com> wrote:
> On 07/17/2015 10:04 PM, Rafael Schloming wrote:
>>
>> On Fri, Jul 17, 2015 at 12:47 PM, Gordon Sim <g...@redhat.com> wrote:
>>
>>> On 07/17/2015 08:15 PM, Rafael Schloming wrote:
>>>
>>>> On Fri, Jul 17, 2015 at 11:56 AM, Gordon Sim <g...@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?
>
>
> Yes
>

Given that and all who looked thinking the earlier proposal was safe,
is it worth going with that change at least for now? Knocking things
off the blocker list and getting an RC (or even just a beta) out would
be really really good.

Robbie

Reply via email to