Our App got rejected during AppStore review. It worked fine on the physical test device running iOS 13.1.2 however. So, I upgraded to iOS 13.3.1 and now it crashes with the exact same error report that Apple has sent.
Am I correct in the assumption that the error needs to be fixed in JavaFXPorts?
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
VM Region Info: 0 is not in any region. Bytes before following region: 4374036480
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 0000000104b68000-0000000106898000 [ 29.2M] r-x/r-x SM=COW ...yMobileApp
Termination Reason: LIBSYSTEM, [0x4]
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001aa016930 __abort_with_payload + 8
1 libsystem_kernel.dylib 0x00000001aa01af24 abort_with_payload_wrapper_internal + 100 (terminate_with_reason.c:72)
2 libsystem_kernel.dylib 0x00000001aa01aec0 abort_with_reason + 28 (terminate_with_reason.c:86)
3 libsystem_pthread.dylib 0x00000001a9f3fed0 pthread_self.cold.1 + 32
4 libsystem_pthread.dylib 0x00000001a9f3f0a8 pthread_self + 48 (internal.h:722)
5 Foundation 0x00000001aa4d2964 +[NSThread currentThread] + 96 (NSThread.m:373)
6 MyMobileApp 0x0000000104d58170 JNI_OnLoad_glass + 63624
7 MyMobileApp 0x00000001055b0cfc 0x104b68000 + 10783996
8 MyMobileApp 0x00000001055a5030 [J]com.sun.glass.ui.Window.<init>(Lcom/sun/glass/ui/Window;Lcom/sun/glass/ui/Screen;I)V + 10735664 (Window.java:273)
9 MyMobileApp 0x00000001055b0c58 [J]com.sun.glass.ui.ios.IosWindow.<init>(Lcom/sun/glass/ui/Window;Lcom/sun/glass/ui/Screen;I)V + 10783832 (IosWindow.java:40)
10 MyMobileApp 0x00000001055aa790 [J]com.sun.glass.ui.ios.IosApplication.createWindow(Lcom/sun/glass/ui/Window;Lcom/sun/glass/ui/Screen;I)Lcom/sun/glass/ui/Window; + 10758032 (IosApplication.java:78)
11 MyMobileApp 0x0000000105915f50 [J]com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow()V + 14344016 (WindowStage.java:198)
12 MyMobileApp 0x0000000105915c7c [J]com.sun.javafx.tk.quantum.WindowStage.init(Lcom/sun/javafx/tk/quantum/GlassSystemMenu;)Lcom/sun/javafx/tk/quantum/WindowStage; + 14343292 (WindowStage.java:144)
13 MyMobileApp 0x000000010590525c [J]com.sun.javafx.tk.quantum.QuantumToolkit.createTKStage(Ljavafx/stage/Window;ZLjavafx/stage/StageStyle;ZLjavafx/stage/Modality;Lcom/sun/javafx/tk/TKStage;ZLjava/security/AccessControlContext;)Lcom/sun/javafx/tk/TKStage; + 14275164 (QuantumToolkit.java:570)
14 MyMobileApp 0x00000001061b485c [J]javafx.stage.Stage.impl_visibleChanging(Z)V + 23382108 (Stage.java:1164)
15 MyMobileApp 0x00000001061b9bec [J]javafx.stage.Window$9.invalidated()V + 23403500 (Window$9.java:825)
16 MyMobileApp 0x0000000105ed4e54 [J]javafx.beans.property.BooleanPropertyBase.markInvalid()V + 20368980 (BooleanPropertyBase.java:110)
17 MyMobileApp 0x0000000105ed4f58 [J]javafx.beans.property.BooleanPropertyBase.set(Z)V + 20369240 (BooleanPropertyBase.java:146)
18 MyMobileApp 0x00000001061b8564 [J]javafx.stage.Window.setShowing(Z)V + 23397732 (Window.java:923)
19 MyMobileApp 0x00000001061b85d4 [J]javafx.stage.Window.show()V + 23397844 (Window.java:938)
20 MyMobileApp 0x00000001061b34fc [J]javafx.stage.Stage.show()V + 23377148 (Stage.java:260)
21 MyMobileApp 0x00000001054c4160 [J]com.gluonhq.charm.glisten.application.MobileApplication.a(Z)V + 9814368 (MobileApplication.java:277)
22 MyMobileApp 0x00000001054c3e38 [J]com.gluonhq.charm.glisten.application.MobileApplication.start(Ljavafx/stage/Stage;)V + 9813560 (MobileApplication.java:235)
23 MyMobileApp 0x00000001055f8a54 [J]com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(Ljava/util/concurrent/atomic/AtomicBoolean;Ljavafx/application/Application;)V + 11078228 (LauncherImpl.java:868)
There's more in the report but I think this should be enough. If more information is needed I will glady provide it.
Until a new JavaFXPorts repo is officially published with the fix, you can download the custom ios-sdk from this repository . Extract it and change your build.gradle as follows to use it:
jfxmobile {
javafxportsVersion = '8.60.13'
ios {
iosSdk='<PATH_TO_EXTRACTED_ios-sdk>';
....
}
}
Related
We are facing a bit of a conundrum in our DriverKit extension development. We would like to build and debug on Monterey. This means that we need to use Xcode 13. We also need to support Big Sur. Unfortunately we haven't been able to build a DEXT with Xcode 13 that works on Big Sur.
We are setting the DRIVERKIT_DEPLOYMENT_TARGET to 19 (the lowest possible value). The DEXT loads fine on Big Sur but whenever a user client connects the DEXT process crashes with an assertion failure like this:
Crashed Thread: 0 Dispatch queue: Root
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
dyld2 mode
abort() called
Thread 0 Crashed:: Dispatch queue: Root
0 libsystem_kernel.dylib 0x0000000104bfb3a4 __pthread_kill + 8
1 libsystem_pthread.dylib 0x0000000104de6844 pthread_kill + 272
2 libsystem_c.dylib 0x0000000104b98f24 abort + 124
3 com.apple.DriverKit 0x00000001048b12b4 __assert_rtn + 92
4 com.apple.DriverKit 0x00000001048b151c OSMetaClassBase::QueueForObject(unsigned long long) (.cold.2) + 44
5 com.apple.DriverKit 0x0000000104893068 OSMetaClassBase::QueueForObject(unsigned long long) + 176
6 com.apple.DriverKit 0x0000000104893780 OSMetaClassBase::Invoke(IORPC) + 412
7 com.apple.DriverKit 0x000000010489425c Server(void*, mach_msg_header_t*, mach_msg_header_t*) + 512
8 com.apple.DriverKit 0x00000001048959c8 uiomachchannel(void*, dispatch_mach_reason_t, dispatch_mach_msg_s*, int) + 156
9 libdispatch.dylib 0x0000000104a43b90 _dispatch_mach_msg_invoke + 476
10 libdispatch.dylib 0x0000000104a313ec _dispatch_lane_serial_drain + 308
11 libdispatch.dylib 0x0000000104a448f4 _dispatch_mach_invoke + 464
12 libdispatch.dylib 0x0000000104a313ec _dispatch_lane_serial_drain + 308
13 libdispatch.dylib 0x0000000104a32154 _dispatch_lane_invoke + 456
14 libdispatch.dylib 0x0000000104a33408 _dispatch_workloop_invoke + 1680
15 libdispatch.dylib 0x0000000104a3c9f0 _dispatch_workloop_worker_thread + 764
16 libsystem_pthread.dylib 0x0000000104de75e0 _pthread_wqthread + 276
17 libsystem_pthread.dylib 0x0000000104dee7fc start_wqthread + 8
I've seen a similar problem on the Apple developer forums and the advice seems to be "upgrade to Monterey", which doesn't help much.
I have not been able to locate any meaningful assertion message. I tried digging in the XNU sources to find the failing assert, but did not have any luck.
Has anyone been able to build a DEXT with Xcode 13 that works on Big Sur? Any pointers on what to try are very welcome.
We faced the same issue, Apple suggested to do a seperate release for both Monterey and BigSur, or do two builds and modify the installer to install based on the corresponding OS.
I am trying to set up a new MacBook Pro M1 Max. I have been using the same phone with my previous MBP 2018 Intel.
I installed Xcode 13 for M1. When I plug this iPhone 13 Pro Max into this new MBP and open the device manager I get the error that it can't prepare the device for development.
Another piece of info: I am still able to build and deploy my app to the phone from Xcode on this MBP.
I have received this error from time to time on my old laptop and when that happens I just restart the phone and it will work. I tried that with this laptop and that didn't change anything. I don't know if it is exactly the same error as before though.
Here are the details from the error:
Details
Failed to prepare device for development.
Domain: com.apple.dtdevicekit
Code: 806
Recovery Suggestion: If you are certain that Xcode supports development on this device, try disconnecting and reconnecting the device.
User Info: {
AssociatedMobileDeviceFunction = AMDeviceMountImage;
DVTDeviceErrorIsProxied = 1;
DVTRadarComponentKey = 487927;
NSLocalizedFailure = "This operation can fail if the version of the OS on the device is newer than the version of Xcode that is running.";
}
--
The device rejected the pairing attempt.
Domain: com.apple.dt.MobileDeviceErrorDomain
Code: -402653035
User Info: {
DVTRadarComponentKey = 261622;
MobileDeviceErrorCode = "(0xE8000095)";
"com.apple.dtdevicekit.stacktrace" = (
0 DTDeviceKitBase 0x000000017b3c2ff8 DTDKCreateNSErrorFromAMDErrorCode + 272
1 DTDeviceKitBase 0x000000017b3fc3bc -[DTDKMobileDeviceToken _mountDeveloperDiskImage:withError:] + 912
2 DTDeviceKitBase 0x000000017b3fcdb0 __58-[DTDKMobileDeviceToken mountDeveloperDiskImageWithError:]_block_invoke + 564
3 libdispatch.dylib 0x00000001a4b7ebac _dispatch_client_callout + 20
4 libdispatch.dylib 0x00000001a4b8de00 _dispatch_lane_barrier_sync_invoke_and_complete + 56
5 DTDeviceKitBase 0x000000017b3fcb20 -[DTDKMobileDeviceToken mountDeveloperDiskImageWithError:] + 168
6 IDEiOSSupportCore 0x000000017b2a5850 __43-[DVTiOSDevice prepareProxiedDevicesAsync:]_block_invoke + 584
7 DVTFoundation 0x0000000101da6238 __DVT_CALLING_CLIENT_BLOCK__ + 16
8 DVTFoundation 0x0000000101da7824 __DVTDispatchAsync_block_invoke + 564
9 libdispatch.dylib 0x00000001a4b7ce60 _dispatch_call_block_and_release + 32
10 libdispatch.dylib 0x00000001a4b7ebac _dispatch_client_callout + 20
11 libdispatch.dylib 0x00000001a4b86330 _dispatch_lane_serial_drain + 672
12 libdispatch.dylib 0x00000001a4b86ea4 _dispatch_lane_invoke + 392
13 libdispatch.dylib 0x00000001a4b91708 _dispatch_workloop_worker_thread + 656
14 libsystem_pthread.dylib 0x00000001a4d395b0 _pthread_wqthread + 288
15 libsystem_pthread.dylib 0x00000001a4d382c4 start_wqthread + 8
);
}
--
System Information
macOS Version 12.0.1 (Build 21A559)
Xcode 13.1 (19466) (Build 13A1030d)
Timestamp: 2021-11-13T16:59:37-07:00```
My app is rejected and want to know which line of source is problem.
anyway, I extracted .app file and .app.dSYM file and put it in same new directory.
Crash log says.
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001838d42e8 0x1838b2000 + 140008
1 libsystem_pthread.dylib 0x00000001839e92f8 0x1839e6000 + 13048
2 libsystem_c.dylib 0x0000000183842fbc 0x1837e0000 + 405436
3 libc++abi.dylib 0x0000000182fdf068 0x182fdd000 + 8296
4 libc++abi.dylib 0x0000000182fdf210 0x182fdd000 + 8720
5 libobjc.A.dylib 0x0000000183008810 0x183000000 + 34832
6 libc++abi.dylib 0x0000000182ff754c 0x182fdd000 + 107852
7 libc++abi.dylib 0x0000000182ff7158 0x182fdd000 + 106840
8 libobjc.A.dylib 0x00000001830086e8 0x183000000 + 34536
9 CoreFoundation 0x0000000183c84cc4 0x183c7c000 + 36036
10 GraphicsServices 0x0000000185b30f84 0x185b26000 + 44932
11 UIKit 0x000000018d3dd5c4 0x18d36a000 + 472516
12 ARlocator <- this is app name 0x0000000102415434 0x102410000 + 21556
on terminal I commanded
atos -arch arm64 -o ARlocator.app/ARlocator -l 0x102410000 0x0000000102415434
but it says
atos cannot load symbols for the file ARlocator.app/ARlocator for architecture arm64.
The dSYM is a bundle. The target dwarf data is in ../contents/resources/dwarf.
I am writing an app that uses Audio Queue Services to play music. When it gets to the end of one song, it should move on to the next. It works fine in the debug scheme, but it crashes in the release scheme
Process: xxx [1136]
Path: /Users/USER/Desktop/btunes.app/Contents/MacOS/xxx
Identifier: xxx
Version: 1.0 (1)
Code Type: X86-64 (Native)
Parent Process: launchd [152]
Responsible: xxx [1136]
User ID: 501
Date/Time: 2014-03-18 09:33:15.557 -0700
OS Version: Mac OS X 10.9.2 (13C64)
Report Version: 11
Anonymous UUID: 57FFD284-4D30-889E-73D0-CE978BAFC774
Crashed Thread: 6 com.apple.coreaudio.AQClient
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000280000018
VM Regions Near 0x280000018:
CG shared images 00000001c7eb2000-00000001c7eba000 [ 32K] r--/r-- SM=SHM
-->
JS JIT generated code 00005b8cc8000000-00005b8cc8001000 [ 4K] ---/rwx SM=NUL
Application Specific Information:
objc_msgSend() selector name: delegate
Thread 6 Crashed:: com.apple.coreaudio.AQClient
0 libobjc.A.dylib 0x00007fff85742097 objc_msgSend + 23
1 com.cluttered.btunes 0x000000010aced249 -[BTSAudioStreamer handleAudioQueueProperty] + 136 (BTSAudioStreamer.m:180)
2 com.apple.audio.toolbox.AudioToolbox 0x00007fff87af6f6d ClientAudioQueue::PropertyChanged(unsigned int) + 415
3 com.apple.audio.toolbox.AudioToolbox 0x00007fff87afc97c AQClientCallbackMessageReader::DispatchCallbacks(void const*, unsigned long) + 440
4 com.apple.audio.toolbox.AudioToolbox 0x00007fff87af742e ClientAudioQueue::FetchAndDeliverPendingCallbacks(unsigned int) + 334
5 com.apple.audio.toolbox.AudioToolbox 0x00007fff87af7554 AQCallbackReceiver_CallbackNotificationsAvailable + 129
6 com.apple.audio.toolbox.AudioToolbox 0x00007fff87b1777c _XCallbackNotificationsAvailable + 48
7 com.apple.audio.toolbox.AudioToolbox 0x00007fff87b111bf mshMIGPerform + 153
8 com.apple.CoreFoundation 0x00007fff81adc9a9 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
9 com.apple.CoreFoundation 0x00007fff81adc91e __CFRunLoopDoSource1 + 478
10 com.apple.CoreFoundation 0x00007fff81acda16 __CFRunLoopRun + 1830
11 com.apple.CoreFoundation 0x00007fff81acd0b5 CFRunLoopRunSpecific + 309
12 com.apple.audio.toolbox.AudioToolbox 0x00007fff87afe479 GenericRunLoopThread::Entry(void*) + 187
13 com.apple.audio.toolbox.AudioToolbox 0x00007fff87ab7c0d CAPThread::Entry(CAPThread*) + 109
14 libsystem_pthread.dylib 0x00007fff87db1899 _pthread_body + 138
15 libsystem_pthread.dylib 0x00007fff87db172a _pthread_start + 137
16 libsystem_pthread.dylib 0x00007fff87db5fc9 thread_start + 13
Line 180 is
if (self.delegate) {
The delegate is (weak), and I set self.delegate to nil in dealloc. It looks like the Audio Queue Property Listener keeps running even after I remove it (which I'm also doing in dealloc).
I don't understand why it only happens in Release mode though. For now I'm just archiving the app in Debug but this obviously not ideal. Any ideas?
Paraphrasing/Quoting this post so that the knowledge is retained.
Looks like there is an issue with different optimization levels. Running with optimization at fast causes a crash in some environments.
"One of the differences that jumped out at me was the Optmization Level setting. The Debug version was set to None [-O0], while the Release version was set to Fastest, Smallest [-Os].
I changed the Debug setting to Fastest, Smallest [-Os] and BOOM, it crashed on the iPhone 3G every time I ran it. Switching it back to None [-O0] brought back the correct behavior."
Also see Related SO Question.
I have submitted new version of my app for review for the Mac App Store. The update was rejected because it crashed.
The crash happens when the app disconnects from iCloud. This leads to a strange problem:
The app supports storing files in iCloud and thus includes the iCloud entitlement. An app which uses iCloud and which is signed with a Mac App Store Distribution Profile cannot be launched, because only apps loaded from the App Store are allowed to use iCloud.
Thus I am not able to test the version I submitted on my machine. I can compile an run the app without signing it with a Mac App Store Distribution Profile, but then I cannot use/test iCloud.
I got the CrashLog from the review but I have no idea what the problem might be. Does any one has an idea how to handle this?
Process: MyApp [69811]
Path: /Applications/MyApp.app/Contents/MacOS/MyApp
Identifier: com.example.MyApp
Version: 1.2 (1.2)
App Item ID: 0
App External ID: 0
Code Type: X86-64 (Native)
Parent Process: launchd [184]
Responsible: MyApp [69811]
User ID: 201
Date/Time: 2014-01-29 13:20:22.910 -0800
OS Version: Mac OS X 10.9.1 (13B42)
Report Version: 11
Anonymous UUID: FE66701D-3E78-131A-A6CA-844122FA6616
Sleep/Wake UUID: DF88CF2B-42D1-40BD-BAC7-4C433EC11A34
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff9266ea52 __semwait_signal_nocancel + 10
1 libsystem_c.dylib 0x00007fff8ca39a7c nanosleep$NOCANCEL + 189
2 libsystem_c.dylib 0x00007fff8ca635fe usleep$NOCANCEL + 54
3 libsystem_c.dylib 0x00007fff8ca8fbc4 abort + 135
4 coop.plausible.CrashReporter 0x000000010343030e uncaught_exception_handler + 27
5 com.apple.CoreFoundation 0x00007fff8bc0f8c2 __handleUncaughtException + 706
6 libobjc.A.dylib 0x00007fff8a805304 _objc_terminate() + 94
7 libc++abi.dylib 0x00007fff8e6623e1 std::__terminate(void (*)()) + 8
8 libc++abi.dylib 0x00007fff8e662456 std::terminate() + 54
9 libobjc.A.dylib 0x00007fff8a8050b0 objc_terminate + 9
10 libdispatch.dylib 0x00007fff91e912c1 _dispatch_client_callout + 28
11 libdispatch.dylib 0x00007fff91e98f03 _dispatch_main_queue_callback_4CF + 333
12 com.apple.CoreFoundation 0x00007fff8bb76839 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
13 com.apple.CoreFoundation 0x00007fff8bb31b14 __CFRunLoopRun + 1636
14 com.apple.CoreFoundation 0x00007fff8bb31275 CFRunLoopRunSpecific + 309
15 com.apple.HIToolbox 0x00007fff93622f0d RunCurrentEventLoopInMode + 226
16 com.apple.HIToolbox 0x00007fff93622cb7 ReceiveNextEventCommon + 479
17 com.apple.HIToolbox 0x00007fff93622abc _BlockUntilNextEventMatchingListInModeWithFilter + 65
18 com.apple.AppKit 0x00007fff875e928e _DPSNextEvent + 1434
19 com.apple.AppKit 0x00007fff875e88db -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
20 com.apple.AppKit 0x00007fff875dc9cc -[NSApplication run] + 553
21 com.apple.AppKit 0x00007fff875c7803 NSApplicationMain + 940
22 com.example.MyApp 0x0000000102f92242 0x102f89000 + 37442
23 com.example.MyApp 0x0000000102f8adb4 0x102f89000 + 7604
You can test iCloud enabled apps on your machine during development.
iCloud does require entitlements, signing and provisioning but it also works with development provisioning profiles.
You can use your developer signing ID for debug builds.
Xcode 5 also gained an iCloud debug pane that shows some details about your container and current transfers: