03.12.2015 12:11, Alex Peshkoff wrote:
>> Remove the call of addRef(), find all YHelper's descendants and fix
>> every single
>> >creation of them is the right fix for that?
>> >
> Yes, something like this.
In YTransaction::enterDtc(), copy->addRef() is already called. Must it be
now two
On 12/03/2015 02:01 PM, Dimitry Sibiryakov wrote:
> 03.12.2015 11:22, Alex Peshkoff wrote:
>> Yes, and looks like assert() did it best to help find it.
> Remove the call of addRef(), find all YHelper's descendants and fix every
> single
> creation of them is the right fix for that?
>
Yes, some
03.12.2015 11:22, Alex Peshkoff wrote:
> Yes, and looks like assert() did it best to help find it.
Remove the call of addRef(), find all YHelper's descendants and fix every
single
creation of them is the right fix for that?
--
WBR, SD.
---
On 12/02/2015 08:19 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> YHelper calls this->addRef() in constructor. But if the rest of the
> constructor throw
> anything, destructor is called automatically and die on assertion
> fb_assert(refCounter.value() == 0).
> Is it a design flaw?
>
I think addRef should not be called using this->addRef. Only external
owners can add refs.
One more place where this->addRef exists it is /src/remote/remote.h#L1008.
In all other places, addRef is called on private objects that the object owns.
On 2 December 2015 at 19:19, Dimitry Sibiryakov wro
Hello, All.
YHelper calls this->addRef() in constructor. But if the rest of the
constructor throw
anything, destructor is called automatically and die on assertion
fb_assert(refCounter.value() == 0).
Is it a design flaw?
--
WBR, SD.
---
