[TIMOB-651] Audio Player crash

GitHub Issue	n/a
Type	Bug
Priority	Medium
Status	Closed
Resolution	Fixed
Resolution Date	2011-04-17T01:53:48.000+0000
Affected Version/s	n/a
Fix Version/s	Release 1.2.0
Components	iOS
Labels	n/a
Reporter	Nolan Wright
Assignee	Blain Hamon
Created	2011-04-15T02:33:46.000+0000
Updated	2011-04-17T01:53:48.000+0000

Description

get this

2010-03-26 11:46:28.667 TwitterUI[51108:530b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'stopAudioSession called too many times'

seems to be a problem with the guard.

run attached app (click button on page1, then click row on table view, close modal, repeat -> crash)

Attachments

File	Date	Size
archive.zip	2011-04-15T02:33:47.000+0000	10898

Comments

Stephen Tramer 2011-04-15
Claimed from Blain. My previous description of the bug was erroneous.
Stephen Tramer 2011-04-15
This appears to be a much more serious issue. Stack traces indicate the following:

Creation: (count = 1)
0: -[TiMediaAudioSession startAudioSession]
1: -[TiMediaAudioPlayerProxy initWithProperties:]
2: -[TiProxy initWithPageContext:args:]
3: -[TiModule createProxy:forName:context:]

With the following when the tab (NOT the modal window!) are closed:

Destruction:

Once for context destruction: (count = 0)
1: -[TiMediaAudioSession stopAudioSession]
2: -[TiMediaAudioPlayerProxy _destroy]
3: -[TiProxy contextShutdown:]

And once for the proxy destruction: (count = -1)

1: -[TiMediaAudioSession stopAudioSession]
2: -[TiMediaAudioPlayerProxy _destroy]
3: -[TiProxy dealloc]

The solution is to perform a sanity check on (count), but please be aware of the larger issue: All destroy functions MUST RELEASE_TO_NIL() all variables and/or perform operations which are guaranteed to have NO side-effects in other classes (in this case, TiMediaAudioPlayerProxy calls a function with a side-effect in another class: TiMediaAudioSession.) If they must call functions with side-effects, there should be a 'BOOL destroyed' variable which tracks whether or not the object has already been destroyed. (ED'S NOTE: Calling [super destroy] in the appropriate place handles this already; ignore my advice.)

Strongly recommend that this variable (and a sanity check associated with it) be added to TiProxy.
Stephen Tramer 2011-04-15
Well I'll be - there's already this variable (and an associated sanity check!) in _destroy for TiProxy.

The problem was that [super _destroy] was not called. Fixed.
Jeff Haynie 2011-04-15
(from [31b5596dc6480e8f6e753a48949505706e7a2f2a]) Closes #651 - Didn't call [super _destroy]. http://github.com/appcelerator/titanium_mobile/commit/31b5596dc6480e8f6e753a48949505706e7a2f2a"> http://github.com/appcelerator/titanium_mobile/commit/31b5596dc6480...

JSON Source