You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@bogardon-bind: will invoke that method, and should touch all the same code paths that your -filter: example did.
I actually do see something similar when profiling our app, but nothing that helps me figure out the exact leak, why it's occurring, or how to best fix it. I was hoping a unit test could narrow it down and give us something reproducible. :\
If I change line 103/104 in RACSequence.m to have __weak modifiers in front. Instruments claims RACArraySequence is no longer leaked, but a few malloc 32 bytes are still leaking. Sorry at this point I'm just trying to brute force my way to a fix.
What's really confusing me now is why some of the items that Instruments claims to have leaked shows an allocation history where it reaches a reference count of 0, like this:
I googled around and people say it's related to not calling [super dealloc], which should be irrelevant for us since we're using ARC?
It is dangerous with my experience that use of @property, (copy), Block type variable combination.
There is probably a some difference with @property(copy) void(^block)(); self.block = blockValue; and @property(strong) void(^block)(); self.block = [blockValue copy];.
May be compiler bug?
I always use @property(strong) id block and typecast for inoke block in my project code.
Activity
jspahrsummers commentedon May 21, 2013
Is that the exact code you used? Can you share the context for it?
bogardon commentedon May 21, 2013
@jspahrsummers that's the exact code. I created an empty project and placed those lines at the top of
appDidFinishLaunching...
.jspahrsummers commentedon May 21, 2013
Would you mind uploading a saved Instruments trace somewhere?
bogardon commentedon May 21, 2013
http://www.fileswap.com/dl/dkwA1qy2yX/
bogardon commentedon May 21, 2013
It looks like the leak is happening because of this extra retain highlighted here.
Add a test for the memory leak in #505
jspahrsummers commentedon May 22, 2013
I tried writing a unit test to reproduce this issue, but wasn't able to trigger a leak: https://github.com/ReactiveCocoa/ReactiveCocoa/compare/sequence-leak
bogardon commentedon May 22, 2013
How come you're not going through
[RACDynamicSequence sequenceWithLazyDependency...
in these tests?Were you able to reproduce my results in instruments at all? FWIW it appears to be the same on the device.
Also, turns out it leaks even if you don't convert back to an array, but I guess your tests show that you already know that.
jspahrsummers commentedon May 22, 2013
@bogardon
-bind:
will invoke that method, and should touch all the same code paths that your-filter:
example did.I actually do see something similar when profiling our app, but nothing that helps me figure out the exact leak, why it's occurring, or how to best fix it. I was hoping a unit test could narrow it down and give us something reproducible. :\
bogardon commentedon May 22, 2013
If I change line 103/104 in
RACSequence.m
to have__weak
modifiers in front. Instruments claimsRACArraySequence
is no longer leaked, but a fewmalloc 32 bytes
are still leaking. Sorry at this point I'm just trying to brute force my way to a fix.What's really confusing me now is why some of the items that Instruments claims to have leaked shows an allocation history where it reaches a reference count of 0, like this:
I googled around and people say it's related to not calling
[super dealloc]
, which should be irrelevant for us since we're using ARC?kkazuo commentedon May 22, 2013
@bogardon How happen with this patch?
It is dangerous with my experience that use of
@property
,(copy)
,Block type variable
combination.There is probably a some difference with
@property(copy) void(^block)(); self.block = blockValue;
and@property(strong) void(^block)(); self.block = [blockValue copy];
.May be compiler bug?
I always use
@property(strong) id block
and typecast for inoke block in my project code.Coneko commentedon May 22, 2013
@kkazuo's change does fix the problem.
Could you open a PR with the fix please?
Avoid using copying property as a block value
2 remaining items