I'm using an NTP framework in my App and it makes use of ASyncUDPsocket, however this framework makes the App break after coming back from the background after a while.
NetworkClock source: https://code.google.com/p/ios-ntp/issues/attachmentText?id=8&aid=6136447331175276042&name=NetworkClock.m&token=ky6UNYWjqChe2rQkEv1a_VSDpqk%3A1372342874389
AsyncUdpSocket source: http://pastebin.com/tuKqpnqZ
Breakpoints are:
[self doSend:[self socketForPacket:theCurrentSend]];
And:
result = sendto(theNativeSocket, buf, (size_t)bufSize, 0, dst, (socklen_t)dstSize);
I tried suggestions here:
https://code.google.com/p/ios-ntp/issues/detail?id=8
But so far the app stills crashes with a iPhone backboardd[28] <Warning>: Application 'UIKitApplication:nl.app[0x8f48]' exited abnormally with signal 13: Broken pipe: 13 error.
How can I prevent this?
Related
I am doing some iPhone automation and want to observe call states of ongoing calls. I implemented a listener to read the idevicesyslog and fetch log output of com.apple.accessibility.heard, which is printing each state change similar to the following lines (stat=Sending and stat=Active):
ay 13 02:14:02 heard(HearingUtilities)[11392] <Notice>: -[HUComfortSoundsController callStatusDidChange:]:415 Phone call holding 0 [pending = 1, active = 0, avc = 0, endpoint = 1] - NSConcreteNotification 0x102f173f0 {name = TUCallCenterCallStatusChangedNotification: object = <TUProxyCall 0x102f47080 p=com.apple.coretelephony aPI=(null) svc=Telephony hdl=<TUHandle 0x103407870 type=PhoneNumber, value=+4912345, normalizedValue=+4912345, isoCountryCode=de> isoCC=de stat=Sending tStat=0 dR=0 fR=0 supportsR=1 uPI=57FCA1D2-D09F-4E23-A08A-3AD4B18B570D grp=(null) lSIUUID=00000000-0000-0000-0000-000000000001 lSIAccountUUID=AA1FC9E6-068E-4D86-B3B9-C1074658AFB2 hosted=1 endpt=1 callerNFN=(null) srcID=(null) aC=(null) aM=(null) iUB=1 vm=0 connStat=00 nMICS=0 sR=0 iSA=0 iSV=0 iSS=0 wHM=0 hSI=0 vST=0 iapST=0 oapST=0 vCA=<TUVideoCallAttributes 0x102f17330 remoteCameraOrientation=0 localVideoContextSlotIdentifier=0 remoteVideoContextSlotIdentifier=0> model=<TUCallModel 0x102f3e380 hold=1 grp=1 ungrp=1 DTMF=1 uMPS=1 aC=1 sTV=0> em=0 iFE=0 sos=0 sSR=1 sSUI=0 mX=0<\M-b\M^#\M-&>
May 13 02:14:14 heard(HearingUtilities)[11392] <Notice>: -[HUComfortSoundsController callStatusDidChange:]:415 Phone call holding 0 [pending = 0, active = 1, avc = 1, endpoint = 1] - NSConcreteNotification 0x10321ab80 {name = TUCallCenterCallStatusChangedNotification: object = <TUProxyCall 0x102f47080 p=com.apple.coretelephony aPI=(null) svc=Telephony hdl=<TUHandle 0x103330670 type=PhoneNumber, value=+4912345, normalizedValue=+4912345, isoCountryCode=de> isoCC=de stat=Active tStat=0 dR=0 fR=0 supportsR=1 uPI=57FCA1D2-D09F-4E23-A08A-3AD4B18B570D grp=(null) lSIUUID=00000000-0000-0000-0000-000000000001 lSIAccountUUID=AA1FC9E6-068E-4D86-B3B9-C1074658AFB2 hosted=1 endpt=1 callerNFN=(null) srcID=(null) aC=AVAudioSessionCategoryPhoneCall aM=(null) iUB=1 vm=0 connStat=11 nMICS=0 sR=0 iSA=0 iSV=0 iSS=0 wHM=0 hSI=1 vST=0 iapST=0 oapST=0 vCA=<TUVideoCallAttributes 0x102f17330 remoteCameraOrientation=0 localVideoContextSlotIdentifier=0 remoteVideoContextSlotIdentifier=0> model=<TUCallModel 0x1032596b0 hold=1 grp=1 ungrp=1 DTMF=1 uMPS=1 aC=1 sTV=1> em=0 iFE=0<\M-b\M^#\M-&>
Unfortunately, starting from newer iOS versions (maybe 15.4 or 15.x already, don't know exactly), the heard service is killing itself after 3 minutes:
May 13 02:28:03 heard(Accounts)[11501] <Notice>: "The connection to ACDAccountStore was invalidated."
May 13 02:28:03 heard(Accounts)[11501] <Notice>: "The connection to ACDAccountStore was invalidated."
May 13 02:30:21 heard(HearingUtilities)[11501] <Notice>: -[AXHeardController shutdownIfPossible]:355 heard still shouldn't be running. Shutting down.
It is restarting after i am opening the settings-> accessibility settings via phone menu. Does anybody have an idea what I can do about this? I thought about following things:
Include heard service / accessibility in an own app, so that it will stay online when app is active
Get call states in another way? I tried an observer inside an app, but when it is running in background, it will not react anymore.
Some iOS setting to enable it permanently
Will this be fixed in an upcoming version?
The com.apple.accessibility.heard seems to be an internal service, does anybody know how to deal with it now?
Otherwise i would also be happy for a hint how to solve this without observing logs. As I said, CallObserver in my swift app is problematic, as it is not working in background.
I am writing e2e tests on Detox to test a Firebase app in React Native. It looks like the call to firebase.auth().signInWithPhoneNumber(number) dispatches some items on the dispatch queue but these items don't ever seem to be dequeued and therefore the tests cannot proceed. My hunch is that there is a network request being made by the sign in call that never resolves.
Here is the log:
detox[41991] INFO: [APP_STATUS] The app is busy with the following tasks:
• There are 2 work items pending on the dispatch queue: "Main Queue (<OS_dispatch_queue_main: com.apple.main-thread>)".
• Run loop "Main Run Loop" is awake.
I have read through this troubleshooting guide and it looks like the operation is on the Main thread (native) and the issue is a waiting too much issue.
Is there a way to inspect the items on the dispatch queue to further understand what they are? I have tried running the /usr/bin/xcrun simctl spawn <device> log stream --level debug --style compact --predicate 'process == "myapp"' but I don't understand the output. If it is useful I can upload the logs.
I'm hoping I can post some logs of some sort and someone can help me to find the reason for the items on the dispatch queue or point me in the right direction.
I have no experience with native development so device system logs and Objective C/Swift code mean nothing to me.
Thanks
Detox version: 19.4.2
React Native version: 0.67.4
Node version: v12.22.6
Device model: iPhone 11 Simulator
OS: iOS
Test-runner (select one): jest-circus
To answer the question: No,there is no easy way to inspect the dispatch queue. You must go through the internals of the app, add logging, and comment-out portions of the code until you figure out what is causing the issue.
EDIT: As of 2022-08-07, updating your #react-native-firebase/* packages to >=v15.3.0 should fix the issue.
About your specific synchronization problem...
This problem is caused by a bug in the #react-native-firebase/messaging implementation of application: didReceiveRemoteNotification: fetchCompletionHandler:[!].
Their implementation gets into a race with FIRAuth/didReceiveRemoteNotification which causes react-native-firebase/messaging to not callback the completion handler if FIRAuth's function ran first.
A PR is in progress for this to be fixed upstream, but in the meantime you can use the following patch if you have set-up patch-package:
diff --git a/node_modules/#react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m b/node_modules/#react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
index ec26b70..743fe41 100644
--- a/node_modules/#react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
+++ b/node_modules/#react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
## -123,6 +123,18 ## - (void)application:(UIApplication *)application
completionHandler(UIBackgroundFetchResultNoData);
return;
}
+
+ // If the notification is a probe notification, always call the completion
+ // handler with UIBackgroundFetchResultNoData.
+ //
+ // This fixes a race condition between `FIRAuth/didReceiveRemoteNotification` and this
+ // module causing detox to hang when `FIRAuth/didReceiveRemoteNotification` is called first.
+ // see https://stackoverflow.com/questions/72044950/detox-tests-hang-with-pending-items-on-dispatch-queue/72989494
+ NSDictionary *data = userInfo[#"com.google.firebase.auth"];
+ if (data && data[#"warning"]) {
+ completionHandler(UIBackgroundFetchResultNoData);
+ return;
+ }
#endif
[[NSNotificationCenter defaultCenter]
[!]in #react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
When I test my app on my iPad I can consistently and reliably get it to crash. When it does, I get an EXC_BAD_ACCESS error in main, and the root cause is far from obvious. I have tried the following steps to try to shed more light on it:
I have enabled zombies. This doesn't seem to have had any affect at all in the output, which makes me think this is not a zombie issue (but clearly I could be wrong).
I have add an exception breakpoint, but when the app crashes, the exception breakpoint doesn't kick in, and all I get is the standard green arrow next to line 16 of main.
I have run the Analyzer and corrected the few minor error that were revealed there. Still, no effect.
I have confirmed that the same problem is occurring for two of my testers who receive the build via test flight.
I have performed a 'Clean' as well as a 'Clean Build Folder'
Here is whats especially weird. When I test on the iPad the app crashes consistently. When I test in a simulator it will not crash no matter what I do. So if it IS a zombie I am at a loss as to how to discover which object need retained better. Further, if I test on my iPhone, the app also does not crash.
Where the crash occurs: In the app, I have a number of sprite nodes that display information, when I touch one of them (actually, what I am touching is a child sprite made to look like a cancel button), what is supposed to happen is that I remove the cancel button's parent from its parent with:
[[self parent] removeFromParent];
Pic of call stack:
There is nothing in the console in the main xcode window, but this is in the console of the device (from the organizer window:
Apr 10 08:50:39 Roberts-iPad com.apple.debugserver-310.2[596] <Warning>: 69 +0.000164 sec [0254/060b]: far -> 788
Apr 10 08:50:39 Roberts-iPad com.apple.debugserver-310.2[596] <Warning>: 70 +0.000079 sec [0254/060b]: esr -> 796
Apr 10 08:50:39 Roberts-iPad com.apple.debugserver-310.2[596] <Warning>: 71 +0.000081 sec [0254/060b]: exception -> 800
Apr 10 08:50:42 Roberts-iPad backboardd[31] <Error>: HID: The 'Passive' connection 'Bubble Fit' access to protected services is denied.
Apr 10 08:50:43 Roberts-iPad backboardd[31] <Warning>: CoreAnimation: updates deferred for too long
Apr 10 08:50:57 Roberts-iPad lockdownd[25] <Notice>: 01cdc000 _select_socket: receive secure message timeout!
Apr 10 08:50:57 Roberts-iPad lockdownd[25] <Notice>: 01cdc000 _receive_message: walk away - non-SSL 1
Up until yesterday I thought I was very, very close to shipping :P I would appreciate any advice on how to shed more light on what the root cause of this exception is. Thanks!
UPDATE: As LearnCocos2D points out below, I may very well have the same SpriteKit bug he links to. The suggestion is to override removeFromParent. I tried this, but it produces an error:
- (void)removeFromParent
{
[self removeFromParent];
self = nil;
[super removeFromParent];
}
The error it produces is that self cannot be assigned to outside of init. How should I rewrite that?
As it turns out, this really was a bug in SpriteKit, further discussed here:
Sprite Kit iOS 7.1 crash on removeFromParent
My fix was to override removeFromParent, in the SKShapeNode subclass that contained the children that needed to be nil'ed before the parent was removed, as thus:
- (void)removeFromParent
{
[self.addButton removeFromParent];
[self.cancelButton removeFromParent];
self.addButton = nil;
self.cancelButton = nil;
[super removeFromParent];
}
The children shape nodes are properties of the parent.
I am using the Redpark Serial SDK 1.4 r270 to help with i/o features for the iphone. One of the issues, that I am currently having is reading the data given using
- (void) readBytesAvailable:(UInt32)numBytes {
Here are my errors.
Feb 8 15:27:50 iapd[897] <Warning>: ERROR - /SourceCache/iapd/iapd-1065.23/iapd/IAPSession.mm:-[IAPSessionBasic _sessionBufferToAppHasSpaceAvailable] - 823 session=0x1 for connectionID=0x1e12ea00 failed to write bytes, errno = 32
Feb 8 15:27:50 iOS[7428] <Warning>: ERROR - /SourceCache/ExternalAccessory/ExternalAccessory-213/EASession.m:-[EASession dealloc] - 137 unable to close session for _accessory=0x20047eb0 and sessionID=65536
Feb 8 15:27:50 iOS[7428] <Warning>: ERROR - /SourceCache/ExternalAccessory/ExternalAccessory-213/EAOutputStream.m:-[EAOutputStream write:maxLength:] - 212 failed to write 229 bytes (wrote -1) with error 9
Feb 8 15:27:50 iOS[7428] <Warning>: ERROR - /SourceCache/ExternalAccessory/ExternalAccessory-213/EAInputStream.m:-[EAInputStream _readInputFromAccThread] - 357 error waiting for read data, errno = 9
This works perfectly works fine with a single view application.
Suppose there is a UINavigationController with view A and view B where A => B when a button is clicked. View B is using the RscMgr thread where all the magic happens to read from the serial port.
At the first instance of the UINavigationController at view B, it works perfectly fine if we stay on this view. We are able to disconnect, connect the port and we will continue streaming the data.
However, if I go back to view A then back to view B. Everything goes to hell. I cannot read the data anymore from this function, and I found (MULTIPLE) errors in the console. Does anyone have a good reason as to why this happened and how we can fix it? I know we have popped the UIViewController off the stack and everything resets and the RscMgr thread is created again but nothing is being viewed. I am unsure on how to clear the buffer using the SDK since it is not provided.
This is simpler than the solution above. Define your function in a different .m file, and have this launch from AppDelegate, not the ViewController.
I had this issue with former apps I wrote. The other option is to declare RscMgr in App Delegate, but then have it initialized in the given ViewController.
The scope you've declared
- (void) readBytesAvailable:(UInt32)numBytes {
in is likely the problem. I would declare this somewhere that does not go away when you open and close B. Such as on the UINavigationController, or on your AppDelegate.
Better yet, create a new singleton class that manages the interface to RedPark, and query it from the rest of your app as needed.
I have a app in which i play a splash video and have added some custom fonts.
The app works fine on ipad 3.2 but on 4.2 etc it crashes. The log says that i release something that i dint alloc. I have checked my code a hundred times and i dont do any such thing.
Either ways it works on the simulator and on the device(both 3.2)
any ideas?
EDIT:
<Error>: df(7903,0x3e3d7898) malloc: *** error for object 0x1a11b0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Wed Jan 19 20:35:38 unknown UIKitApplication:com..imagazine[0x9c7c][7903] <Notice>: def(7903,0x3e3d7898) malloc: *** error for object 0x1a11b0: pointer being freed was not allocated
Wed Jan 19 20:35:38 unknown UIKitApplication:com.imagazine[0x9c7c][7903] <Notice>: *** set a breakpoint in malloc_error_break to debug
Wed Jan 19 20:35:39 unknown ReportCrash[7905] <Notice>: Formulating crash report for process df[7903]
Wed Jan 19 20:35:39 unknown com.apple.launchd[1] <Warning>: (UIKitApplication:com.imagazine[0x9c7c]) Job appears to have crashed: Abort trap
Wed Jan 19 20:35:39 unknown SpringBoard[27] <Warning>: Application 'df' exited abnormally with signal 6: Abort trap
Wed Jan 19 20:35:39 unknown ReportCrash[7905] <Error>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/df_2011-01-19-203538_Sumas-iPad.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
SOLUTION:
First of all use the NSZombies and you will catch such errors.
The Problem: I had a timer setup for every 0.2sec and it was clearing a UIView and allocating it, not every 0.2secs but maybe once every 5secs.
I did a standard check:
if(vewCustom!= nil) {
[vewCustom removeFromSuperView];
[vewCustom release];
vewCustom = nil;
}
But the strange thing was i verified the code hundreds of times and I was not over releasing and either ways it worked on iOS4.2 for iPhone.
I removed the Timer but still it was crashing and then I removed the release and now it works fine.
Strange but it would be good if someone can explain what i was doing wrong.
You could try running the app in debug with zombies enabled. This way you'll get a stack trace on the overreleased object here's a link on how to set it up.
http://iosdevelopertips.com/debugging/tracking-down-exc_bad_access-errors-with-nszombieenabled.html
Assume that the log is true. The easiest way to find it is to enable Zombies and then exercise your application throughly. See here (tip #1):
http://loufranco.com/blog/files/debugging-memory-iphone.html
Another thing to do is a Build and Analyze and look at each thing it flags. In my experience there are very few false positives.
Just noticed this while looking for something else. The reason for the crash is that removeFromSuperview causes the superview to release the view. Thus, the release that follows is redundant (over-release). Won't be an issue with ARC, but could cause some confusion in other situations