1

I'm running into a strange crash that's difficult to reproduce. For instance, out of the past 35 runs of the app, this crash happened once. I'm not sure of the exact steps to repro unfortunately.

The crash report shows:

SIGSEGV
Remotely-[NetworkCall handleRequestFinished] 
in NetworkCall.m on Line 232

line 232 is:

_startBlock = nil;

and that property is defined as:

typedef void (^NetworkCallStartBlock)();
@property(copy, nonatomic) NetworkCallStartBlock startBlock;

The one time i was able to repro the bug w/ the debugger attached, printing out _startBlock to console showed its value was already nil when attempting to assign nil.

Any thoughts?

Gavin
  • 8,204
  • 3
  • 32
  • 42
adam.wulf
  • 2,149
  • 20
  • 27
  • This means that you set the block without copying it (most likely through the variable or in the setter without a manual copy), and when you set it to nil, you try to release the block which used to be on the stack. You're welcome. – Richard J. Ross III Feb 11 '14 at 22:33
  • the property is defined as copy though, so shouldn't that already be copying it? – adam.wulf Feb 11 '14 at 22:58
  • If you have a custom setter, no. You must copy inside the setter (why else would you use monatomic?). – Richard J. Ross III Feb 11 '14 at 23:01
  • There's no custom setter. looking further at the code, the only thing set to _startBlock is nil. – adam.wulf Feb 11 '14 at 23:48
  • 1
    Is it possible 'self' is no longer valid? Can you run with NSZombies enabled? Is there any other information in the callstack etc? – JosephH Feb 11 '14 at 23:56
  • Just because you have a property doesn't mean you are using it. You do not show the important part -- how `_startBlock` gets set. – newacct Feb 12 '14 at 00:56
  • Joseph, your comment did the trick, if you add it as an answer below I'll accept it – adam.wulf Feb 12 '14 at 21:44

2 Answers2

1

_startBlock = nil; change to self.startBlock = nil the latter one make your block release and safely set the property to nil.

simalone
  • 2,768
  • 1
  • 15
  • 20
0

JosephH's comment above was correct. setting the already nil'd value to nil was happening after self was dealloc'd, so it was dereferencing self that was the issue. the dealloc for this class wasn't properly setup to nil everything out, so fixing that solved the issue. Thanks all for the input and tracking it down

adam.wulf
  • 2,149
  • 20
  • 27