In my Windows Store App the following exception is thrown when I attempt to access
CurrentAppSimulator.LicenseInformation
"A quota was exceeded. (Exception from HRESULT: 0x803D0008)"
I have tried creating a new solution and copying all the code files across to it but still get the same error, I have found no help on MSDN or Googling in general.
Judging from the answer here and another one here, I would say you are exceeding a memory limit somewhere. The linked questions/answers indicate that "A quota was exceeded" indicates you used up your entire heap or that your message buffer isn't large enough.
Additionally, some users have indicated that they get that error when their developer license has expired and have had to re-install Windows 8 to resolve the issue.
With a little help from Googling I have discovered that uninstalling the app from the windows start screen seems to help.
When you debug your application seems to get installed and appears on the start screen, in the past I had just ignored this fact. After uninstalling the application and debugging again I was able to get past that error and was able to see the real underlying errors that were occurring. I'm not sure of the relationship between these underlying errors and the one we are discussing here, I suspect they are not directly related.
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!
and subsequently obviously to read/take the topic. The problematic topic is published under BuiltinQosLibExp::Generic.KeepLastReliable.TransientLocal policy and the message is fired only once at the startup of the publisher application. Few things to consider:
Im not using this policy and taking the default policy configuration in code
dds::sub::qos::DataReaderQos tempQos = inSubScriber->default_datareader_qos();
m_EntitySpecReader = new dds::sub::DataReader<XXX_ICD::Entity_Specification_DT>(*inSubScriber, topicLocal, tempQos, m_EntitySpecListener);
from subscriber
The problem is not Firewall or some connection issue, as I know to receive other cyclic topics without any problem.
It is frustrating that I see this topic if Im trying to monitor either with rtiddsspy or RTI administration console.
Last bullet and most frustrating, when I actually felt stuck, is that I have a listener configured with all available callbacks and I thought to receive if not the data at least some callback clue regarding the possible mismatch, lost, something .... but it keeps silence no matter what Im trying to do :)
Will be more than happy to understand if somebody has an answer or potential direction to check :)
You are using the default QoS for your DataReader. This means that its Durability policy is VOLATILE. Even though the DataWriter is configured as TRANSIENT_LOCAL, it will not deliver "old" samples to your DataReader since it is not requesting those due to its volatile durability. In this context, "old" samples are samples that were written before the DataWriter discovered the DataReader.
Things should start working as expected when you configure your DataReader with a Durability policy as TRANSIENT_LOCAL as well.
If you instrumented a Listener on the DataReader, it should show you that a match has taken place though, or that it has failed. If you implemented both the on_subscription_matched and on_requested_incompatible_qos callbacks, then at least one of those two should fire if you have both applications started and if they are able to discover each other.
Since you discovered that the problem was a type mismatch, I wanted to show how the AdminConsole tool could have helped you finding that. Reproducing your issue, this is what it showed:
I'm working on a console app developed by a guy who doesn't work here any longer. While debugging, the ContextSwitchDeadlock exception was thrown (I found this question on the exception). If I ignore it, the app will eventually work through the loop it occurs in. The app runs as a scheduled task every day, but this particular process is not called every single time.
I'm wondering if it is OK to allow this exception to go to production. The author of this app put it in production with this exception, and its been running ever since. Should I just make my (unrelated to this exception) updates and leave the app as is? Or should I try to address the issue? Addressing it seems daunting to me :/
Ben. I would say 'NO'. Unless your exception is a ThreadAbortException (i.e. the user closed a window and so the process is dead) or some such thing, an exception like this could open your code up to cascading failures. Based on what we do where I work:
I think, as a band aid, you should encapsulate the offending code with a Try-Catch, and wire it up to send you an email every time it Catches so you have documentation on what's going on AND so that you prevent cascading failures from propagating throughout your code (quarantine the problem).
Towards a fix (when you have time), debug it and step through to figure out why your main thread is taking so long, and if you can, create a worker thread to handle that (DISCLAIMER: this would be my opening attack angle at this problem, based on the answer from the link you provided. I have NOT tested this, nor do I have experience enough to definitively say this will work).
EDIT: After running into this error for a particularly long running process myself, I came across this slew of answers on msdn:
http://social.msdn.microsoft.com/Forums/en/vsto/thread/bf71a6a8-2a6a-4c0a-ab7b-effb09451a89
While I resolved my error (I was reading a System.IO.FileStream into a String Builder instead of using a String and the StreamReader ReadToEnd method), I think it might be helpful to you.
Is there any way to change this error message? It appears when Resin is not running so I would think it is an IIS6 error message but the source code of the page shows this text commented out:
Unfortunately, Microsoft has added a clever new
"feature" to Internet Explorer. If the text in
an error's message is "too small", specifically
less than 512 bytes, Internet Explorer returns
its own error message. Yes, you can turn that
off, but surprise it's pretty tricky to find
buried as a switch called "smart error
messages" That means, of course, that many of
Resin's error messages are censored by default.
And, of course, you'll be shocked to learn that
IIS always returns error messages that are long
enough to make Internet Explorer happy. The
workaround is pretty simple: pad the error
message with a big comment to push it over the
five hundred and twelve byte minimum. Of course,
that's exactly what you're reading right now.
I've found nothing in the documentation for either IIS6 or for Resin for this error message.
If I recall correctly, Resin and some other Web Servers add an HTML comment to the error page to pad the message such that the true error is presented.
e.g. http://weblogtoolscollection.com/archives/2004/06/22/lame-internet-explorer-script-error-message/
Sample comment as seen on the web:
<!–-
Unfortunately, Microsoft has added a clever new
“feature” to Internet Explorer. If the text in
an error’s message is “too small”, specifically
less than 512 bytes, Internet Explorer returns
its own error message. Yes, you can turn that
off, but *surprise* it’s pretty tricky to find
buried as a switch called “smart error
messages” That means, of course, that many of
Resin’s error messages are censored by default.
And, of course, you’ll be shocked to learn that
IIS always returns error messages that are long
enough to make Internet Explorer happy. The
workaround is pretty simple: pad the error
message with a big comment to push it over the
five hundred and twelve byte minimum. Of course,
that’s exactly what you’re reading right now.
-->
I should note that this message should be a comment on the page (e.g. not visible) if it is visible, something has gone wrong. e.g. maybe the file is being served up as text, not text/html?
In my application I am uploading photos to Face Book. So, While taking picture from iPhone device 3G continuously two or three times my application getting crash and getting message as below
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
(gdb)
I am not getting how to solve this can any one help me to solve this issue.
Thanks in advance.
There really should be a backtrace and that error sounds a lot like your install is hosed; you might try re-installing the dev tools and iOS SDK.
In any case, the description of your problem sounds like you might potentially be using all available memory and your app might be being jettisoned by the system.
If you rate limit the photos such that you can't take another photo until the first photo is uploaded, does the problem go away?
Do you have a memory warning hook in your app? Is it getting fired?