[TIMOB-1877] iOS - errors and intermittent crash with email test case
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Low |
Status | Closed |
Resolution | Hold |
Resolution Date | 2011-04-15T03:04:33.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 1.6.0 M07 |
Components | iOS |
Labels | apple, bug, crash, defect, ios, release-1.6.0 |
Reporter | Thomas Huelbert |
Assignee | Blain Hamon |
Created | 2011-04-15T03:04:32.000+0000 |
Updated | 2017-03-03T07:01:14.000+0000 |
Description
4th gen iPod touch (4.1) with mobile sdk build 1.4.2.dc7b90
1.BaseUI>views>Email dialog
2.select an image (I used a previous screen shot) and enter a valid
email, send it
3.check output while its happening
output:Wed Sep 22 10:07:37 eWorld sandboxd[1536] : KitchenSink(1533) deny file-write-data /private/var/mobile/Media/PhotoData
Wed Sep 22 10:08:04 eWorld KitchenSink[1533] : DA|Could not open the lock file at /tmp/DAAccountsLoading.lock. We'll load the accounts anyway, but bad things may happen
Wed Sep 22 10:08:04 eWorld sandboxd[1539] : KitchenSink(1533) deny file-read-data /private/var/tmp/DAAccountsLoading.lock
I crashed once at this point. Not sure if this a downstream crash from a mem leak or not.
Wed Sep 22 10:08:04 eWorld KitchenSink[1533] : DA|Could not open the lock file at /tmp/DAAccountsLoading.lock. We'll load the accounts anyway, but bad things may happen
this line above is new, marking as regression, other output goes back to 1.4.0 at least
While debugging, I came across this bit:
2011-01-24 14:25:28.854 Titanium[38516:307] Using two-stage rotation animation. To use the smoother single-stage animation, this application must remove two-stage method implementations.
2011-01-24 14:25:54.508 Titanium[38516:307] Using two-stage rotation animation is not supported when rotating more than one view controller or view controllers not the window delegate
The stack trace was thus:
0 0x3108676c in NSLog ()
1 0x3163d2c0 in -UIWindow _setRotatableClient:toOrientation:duration:force:
2 0x3163c19a in -UIWindowController transition:fromViewController:toViewController:target:didEndSelector:
3 0x3163bad2 in -UIViewController presentModalViewController:withTransition:
4 0x3163b246 in -UIViewController presentModalViewController:animated:
5 0x001191f8 in -[TiApp attachModal:toController:animated:] (self=0x517110, cmd=0x24246f, modalController=0x5af100, presentingController=0x53b150, animated=1 '\001') at /CodeValhalla/Appcelerate/mobile/iphone/iphone/../Classes/TiApp.mm:560
6 0x0011775c in -[TiApp showModalController:animated:] (self=0x517110, cmd=0x23544c, modalController=0x5af100, animated=1 '\001') at /CodeValhalla/Appcelerate/mobile/iphone/iphone/../Classes/TiApp.mm:595
7 0x000c1770 in -[MediaModule displayModalPicker:settings:] (self=0x5ae900, cmd=0x23df10, picker=0x5af100, args=0x5aece0) at /CodeValhalla/Appcelerate/mobile/iphone/iphone/../Classes/MediaModule.m:159
8 0x000c25a6 in -[MediaModule showPicker:isCamera:] (self=0x5ae900, cmd=0x23dee9, args=0x5aece0, isCamera=0 '\000') at /CodeValhalla/Appcelerate/mobile/iphone/iphone/../Classes/MediaModule.m:327
9 0x000c7042 in -[MediaModule openPhotoGallery:] (self=0x5ae900, cmd=0x23d45f, args=0x5aece0) at /CodeValhalla/Appcelerate/mobile/iphone/iphone/../Classes/MediaModule.m:787
10 0x349c42ea in -NSObject(NSObject) performSelector:withObject:
11 0x3109a824 in NSThreadPerformPerform ()
12 0x349dbf24 in CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ()
13 0x349adba6 in CFRunLoopDoSources0 ()
14 0x349ad44a in __CFRunLoopRun ()
15 0x349ad276 in CFRunLoopRunSpecific ()
16 0x349ad17e in CFRunLoopRunInMode ()
17 0x311dc5f2 in GSEventRunModal ()
18 0x311dc69e in GSEventRun ()
19 0x315b0122 in -UIApplication _run
20 0x315ae12e in UIApplicationMain ()
21 0x000043ce in main (argc=1, argv=0x2ffff5ec) at /CodeValhalla/Appcelerate/mobile/iphone/iphone/main.m:28
Note that this is because of the camera roll in Apple's own code, not ours, so this part is nothing we can do about.
Hunh. Turns out that the origional bug is also Apple's fault.
Trapping on NSLog causes this to catch in the middle of entering an email address into the email dialog (Apple's code). The trace is in thread 21:
0 0x3108676c in NSLog ()
1 0x32ba43a8 in DALogV ()
2 0x32ba4282 in DALog ()
3 0x32ba3f7e in -DAAccountManager reloadAccounts
4 0x32ba3ce2 in -DAAccountManager init
5 0x32ba3bd4 in +DAAccountManager sharedInstance
6 0x3282ca0c in -MFFindSearchableStoresOperation main
7 0x310889ee in -__NSOperationInternal start
8 0x31088752 in -NSOperation start
9 0x3109d57a in __startOperations_block_invoke_2 ()
10 0x30ec3984 in dispatch_call_block_and_release ()
11 0x30ec4764 in dispatch_worker_thread2 ()
12 0x30e68680 in pthread_wqthread ()
13 0x30e61198 in start_wqthread ()
Titanium makes no mention of MMFindSearchable or DAAccountManager, leading me to believe this is entirely instigated outside our control. Oh Apple, what surprises don't you have for us?
Closing ticket due to time passed and irrelevance.