While launching the app it gets crashed, Due to Ignoring RegisterValidateFunction() for flag pointer 0x10360c5d0: no flag found at that address. Please share how to solve this issue.
Related
Lately numerous network requests with Alamofire made from our iOS device fail with the following error:
Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device"
UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask
.<3>,
_kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask .<3>" ),
_kCFStreamErrorCodeKey=28}
Our app has a mechanism to send a network request if the user has moved +- 10 meters. This is checked every 5 seconds, so in theory every five seconds a call can be made. The network request fails occasionally with this message, returning no status code and the above error.
The message implies the error has to do with available disk/memory space on the device. However, after checking both there is no link to be found since there is plenty of space available. Also, the error occurs on multiple devices, all running iOS 14.4 or higher.
Is there information available regarding error code 28 and what could be the culprit on iOS devices? Even better; how can this error be prevented?
To answer the occurrence of the error itself:
NSPOSIXErrorDomain Code=28 "No space left on device"
With logs in the Xcode terminal:
2021-05-07 15:56:50.873428+0200 MYAPP[21757:7406020] [] nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW 05CD829A-810D-412F-B86E-7524369359E8 [28: No space left on device]
2021-05-07 15:56:50.877243+0200 MYAPP[21757:7400322] Task <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1> finished with error [28] Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1>, _kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalUploadTask <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1>"
), _kCFStreamErrorCodeKey=28}
It appears to get called when there are too many NSURLSessions created, reaching a limit of (in our tests) 600-700 sessions, which are not maintained or closed properly. The error started to get thrown since iOS 14, so it is interesting to see if there was a limit introduced.
Linked is a github issue raised stating the same issues on the ktor microservices framework by JetBrains, pointing in the same direction, mentioning the invalidation of sessions to prevent this issue:
https://github.com/ktorio/ktor/issues/1341
In our own project the origin of the problem turned out to be our implementation of the StarScream websocket library. This might not be relevant for the issues others are having, but explained anyways to create a complete picture of the problem. It is the cause and fix of our specific situation.
At first we assumed it had something to do with the URLSession created by Alamofire (networking library used) since POST requests started to get cancelled, and a kill of the app seemed the only solution to do requests again.
However, we also make use of websocket connections using the StarScream library, which attempts to connect to an socket, and if failed retry to connect every two seconds for a max time of two hours. This would mean for two hours, every two seconds, we connect to the socket -> receive a failure to connect -> disconnect the socket -> connect again. Using a singleton of the socket it was thought there was no possibility of creating multiple URLSessions, since the socket was only initiated once. However calling the connect to the socket again would create a new nw_connection object every single time, since the library did not handle the disconnect properly.
image of NWConcrete_nw_connection objects generated in socket connection
The way this was validated was using the instruments app to check for the creation of new nw_connection objects. Logged as a "memory leak" there, the creation of the nw_connection objects was getting logged and the solution was to make sure we disconnect the socket (invalidate the session) properly before connecting again.
I hope to answer a big part of the issue here, and I will mark my own question answered since this was the solution to the problem at hand. I think Apple should consider giving accurate reports on the number of objects created being limited, instead of giving an error "No space left on device".
Just wanted to chime in with more info, since we're experiencing the same issue.
Based on our analytics, this issue only started happening since iOS 14. We've verified it happening on 14.2, 14.4 and 14.5. Naturally the most straightforward cause for this error would be low memory or disk storage. We've excluded this option with additional logging, as you seem to have done as well.
A possibly related SO post has attributed the issue to a network inspecting framework that was enabled in their release build. It's worth checking if you use a similar tool.
Another report of this issue, this time on the Github of AFNetworking (predecessor to the Alamofire library you use), says they were able to fix it by limiting the creation of URLSession objects.
For us personally, neither of these did the trick. We created a support ticket with Apple, but this hasn't lead to a solution. They requested a small sample project that reproduces the issue, but the error only manifested after 7 days of continuous use in our app. If you have a faster way to reproduce this, it may be worth it to submit your own support ticket.
Hopefully this helps you find a solution, if you do please add this to your post to help others!
I’m new to bluetooth development and I’m working on a project that require connecting to a BLE. Currently I have multiple problem that I will list them:
The app (some times) keep disconnecting from Peripheral with three different reasons:
The first one is "The connection has timed out unexpectedly.” with error code = 6.
The second one is unclear to me, error object is null.
The last one is "Unknown error".
how can I solve such a problems? the disconnection interval between each one is ~10 sec., after the disconnection, I’m trying to reconnect again, which will reconnect then disconnect, how can I solve such an issue?
While debugging the app using xCode, the above errors does not appear, I can check these error on adhoc version or release version (from debug log from the devices that uses the app), but in xCode I can see a warning:
"[CoreBluetooth] WARNING: Characteristic <CBCharacteristic: 0x1706aab00, UUID = FFF3, properties = 0x8, value = (null), notifying = NO> does not specify the "Write Without Response" property - ignoring response-less write”
Is this warning relative to the disconnection problem? or does this warning meaning that the app will disconnect from Peripheral at some point?
If I don’t stop scanning for Peripheral, will this create an issue for me? currently I keep scanning for Peripheral despite I’m connecting to one, the only case I stop scanning is when the app is terminated.
I have the following scenario:
Peer A is waiting for invitations in a custom UI (let's call it WaitingVC). The MCNearbyServiceAdvertiser object is initialized at application start, and the advertising starts (startAdvertisingPeer) when the WaitingVC is presented.
Peer B has the MCNearbyServiceBrowser up and running, also with custom UI (that is, not using the Apple provided MCBrowserViewController).
Peer B finds Peer A (browser:foundPeer:withDiscoveryInfo: is called).
Meanwhile Peer A chooses to close the WaitingVC. Advertising is stopped (stopAdvertisingPeer).
There is a few seconds lag, before Peer B finds out, that Peer A is lost (that is, browser:lostPeer: is called).
If in these few seconds, Peer B chooses to invite Peer A (who still seems to be available for Peer B), Peer A crashes (yes, the invited one, who normally stopped advertising).
Peer B's invite normally times out, and no problem arises.
The crash happens in queue com.apple.NSNetServices.tcplistener-queue. A dispatch_call_block_and_release call fails at release (EXC_BREAKPOINT).
I truly wonder, if this a bug in the MC framework; or am I missing some cleanup procedure? Peer A only does the following:
App delegate: Creating an MCPeerID, store in a strong property,
App delegate: Creating an MCNearbyServiceAdvertiser, store in a strong property, setting delegate,
In WaitingVC: calling startAdvertisingPeer, then calling stopAdvertisingPeer when done.
The crash seemingly occurs no matter what I do. If the MCNearbyServiceAdvertiser object and the MCPeerID object is being kept in WaitingVC and thus destroyed after the WaitingVC is closed, the crash still happens.
Apart from this, everything works fine (invitation procedure, connecting, exchanging data); but this few seconds window for certain failure is not really acceptable. Keeping the advertiser running all the time solves this, but it's just treating the symtpom (and this "sync" feature would be used seldom in the applicaiton, so it's also an overkill).
Update:
The same crash happens when using MCAdvertiserAssistant, if I call its stop method on Peer A, and quickly connect on Peer B. Also, I tested the scenario on this tutorial: http://techmaster.vn/2013/09/multipeer-connectivity-quick-tutorial/ - and the result is the same: Crash. So I have a strong suspicion, this is a bug on Apple's side...
I've been experiencing the same crash and according to this thread in the Dev Forums so have other people. A bug report has been created for it:
Developer Forums: Multipeer Connectivity Crash
I found a simple workaround. I added a delay before starting the browser going.
To fill in the whole story I created a wrapper to replace GKSession with MCSession. The connection was being closed and reopened under specific circumstances, by both ends at the same time, hence it crashed. Adding a delay to the browser start offset it from the tear down of the other end avoiding the problem.
This looks like a problem with your delegate callback
advertiser:didReceiveInvitationFromPeer:withContext:invitationHandler:
most likely with the final argument, the invitationHandler block. Is this method being called? When B makes A crash, there must be something that is being called and this seems to be the only conceivable entry point.
I am getting below crash on console
-[CFURL retain]: message sent to deallocated instance 0x691edc0
I am sending one videourl to another view to play video in MPMovieplayer. any idea.. Thanks
Your question is high-level. At a similarly high level: Run with Zombies enabled in Instruments. When you reproduce the error, find the zombie object, and review its reference count history/actions to determine where the imbalance was introduced.
I am having trouble running the debugger on a STM32F205ZG using µVision4 and the ULINK2. I keep getting the error message "Could not stop Cortex-M device! Please check the JTAG cable." I am using the SW port. Any help with this would be greatly appreciated.
In my own experience I have usually seen this error when either the ULINK2 is disconnected and reconnected while in the middle of a debug session or if you have some external hardware, outside of the control of the debugger, that is acting on your processor.
If the ULINK2 was disconnected mid-debug, then usually cycling power to your device will fix the problem.
If you have something like a watchdog timer that is trying to reset the processor while you are in the middle of debugging, then you will have to disable the watchdog before you can start a debug session.
I've seen the same problem with my NXP uC.
The problem was that the code loaded in flash was faulty and was placing the CPU into a busy loop branching back to the same address, this prevented the debugger accessing the bus.
the uLink worked if I put the device into ISP mode as it never got to the user code.
it seems that uLink takes too long to halt the device after reset, the spec tells you this somewhere, so by the time uLink tries to halt the CPU it is too late as it cannot access the bus and locks up.
I had this problem on LPC4337. I tried all the solutions people are talking about but the only one that worked for me was using a lower processor clock so that JTAG/SWD interface can match/catch up with the processor before it is gone too far into executing user code. In my case I set JTAG/SWD clock in Keil uVision 5 to 10MHz and the changes the processor clock divisors to give 36MHz. With these settings, it never missed to capture on reset when I begin a debug session.
This happens for ULink2 but ULINK Pro and ULINK Pro-D support a JTAG/SWD <= 50MHz. See this link for more comparisons:
ulink comparisons
Just an other issue with this message:
We have the same error message, but the problem was the wrong state of the RESET line.