I'm working on a WebGL app, and have recently been getting reports of it losing the context sometimes and just leaving users with a white screen.
I've added code to handle the context loss and resume operation when/if the context is restored (although chrome never seems to restore it...), but that still leaves me of the root issue: sometimes I'm losing my context.
I understand sometimes this is unavoidable, but I'd like to be able to tell users "you ran out of RAM", "update your graphics drivers", or something. Is there any way to get a 'cause' of the error?
The only thing I see is the 'statusMessage' on the event, which is just giving me "context lost" currently?
There is no reason given.
As for restoring the context you have to handle both the webglcontextlost event and call event.preventDefault() otherwise the context will never be restored.
You also need to handle the webglcontextrestored event to know when it's been restored and realize that all your WebGL objects created before are now invalid and need to be re-created.
The spec shows example code
Related
I have been working on a ARKit/ SceneKit app. I have been getting this particular Scenekit Error, which doesn't crash the app right away, however on repeated usage after a certain point, the app crashes.
[SceneKit] Error: inconsistency in scene graph found in C3DNode
finalize
I have used the usual ways to create nodes and remove them from parent, etc. And more importantly, I have created several other modules (within the same app) without ever encountering such an error. I have been trying to close this issue for the past two days, however I couldn't get any clue.
Following are what I have tried:
Checking allocations of SCNNodes (in Instruments) hoping rather that
some nodes would persist, but this is not the case.
Removing any method which changes the SCNMaterial of a node, hoping the possibly changes in material property might have some
issue.
Removing any node which are being regenerated in my app, hoping that possibly generating lot of nodes might create this issue.
Comparing this module against other modules within my app, which are based on the same logic to check whether I might have changed something within this module. But to no avail.
Removing all logics of AddAudioNode() and in fact all audio nodes themselves, since I saw in my allocations within Instrument.trace that they are persistent and are not being removed on node removal. But this also didn't help.
Granted this module is supposedly more complex with incrementally more number of nodes, however I am not able to understand what direction to strike in to investigate this Error.
I have not found anything existing on the net/ SO on this issue. The only option I am left with to raise a TSI with Apple, though it would cost me 1 TSI, which I have left, and they are expensive, these TSIs! Hence, I really hope if someone is able to throw some light on this and let me know how to approach this bug, it would be very helpful. Anything you require from the code, I can add in, but then the whole codebase is pretty humongous to post here. Hence, snippets as much as applicable.
I have encounted this error when my code was trying to remove nodes on a background thread, so I recommend checking that you are on the main thread with Thread.isMainThread when debugging to ensure you are on the main thread. Something like SCNAction.run(block) actually launches your code in a background thread, which is where I encountered this error. Basically the background thread removed from parent while at the same time the main thread was trying to do something with the node, which cause the scene graph to change before the node finished its process.
I have a parent and a child managed context. I call the parent managed context to save its data in two methods:
applicationWillTerminate
applicationDidEnterBackground
When I am using the simulator and just clicking the "stop" button at the top, neither is called and the context not saved. On the phone itself of course when normally using the app everything works like a charm. If I click the "Home" button in the simulator and go back to the app and then terminate, then of course it is saved because applicationDidEnterBackground was called.
So either I probably have to add somewhere else to save the background context if the simulator is right, or this is a bug of the simulator, or I exit the simulator wrongly. Can you help me? Do I need to change anything or should I just use the "trick" in the simulator to store the data?
It's OK to save your data in those methods but they should not be the only place you do so. Things can go wrong that are out of your control, and it would be good to not lose user data when they do. For example, maybe the phone's battery will suddenly die when your app has a lot of unsaved changes in memory. You're doing a good job of simulating this kind of situation, actually.
Also, the more unsaved changes you have, the more memory your app needs. If you save data, you can always look it up later, so Core Data can clear out its caches, re-fault objects, etc.
You should save changes whenever new changes exist that should not be lost. Exactly when that is depends on your app, but it's almost certainly more than just in those two methods. A common pattern is that any time the UI indicates the user has completed some task, the data related to that task should be saved.
While developing with Firebase, I manually added a data record in the console but forgot one entry, which caused the app to crash. I've corrected the problem in the console but, because I was using Firebase's data persistence, the original data error persists, causing the crash again. If I switch the persistence off, everything is fine but the cached store isn't being updated. Has anyone had this problem and found a way to solve it?
I too have faced this issue, and have lost sleep over the thought of users being trapped in an endless crash-on-start-up loop.
As suggested, the opportunity for the issue to arise is created in the time window between the start up of an app and the subsequent arrival of cache updates from the Firebase server. If data is read from the cache during this time window, and then, if the data happens to be missing an expected value, and then, if the app uses the data in a way that assumes the data will not be nil, the app crashes. If the app crashes before the cache updates, the cache will never have the chance to update, and the user will be trapped in an endless loop (absent wiping the app's data from the device's memory).
Thus far, I've dealt with the issue by more strenuously guarding against the possibility of nil values in code that is called during start up. If nil is checked and inconveniently found, then, depending upon the situation, either (1) if possible and if it will not lead to further data corruption, the app substitutes an appropriate value in place of nil, or otherwise (2) the app goes into a wait mode for a couple of seconds, and then initiates a fresh read from the problem node, and then reattempts the start-up routine.
Perhaps the moral of the story is never assume that a value is non-nil or otherwise within an expected range. Either validate the value upon receipt or check the value at the time of intended use or both, and then handle errors accordingly.
The cache should update automatically. Since this happens in a background thread without, while it invokes your code on the main thread, I'd expect it to update the disk cache even if you application code crashes.
But if that doesn't happen, the fastest way to get back in a good state is to clear the app data for you application or to completely uninstall/reinstall.
I'm a brand new programmer. I'm about to finish my first simple todo list app using core data. The app works perfectly and never crashes. It doesn't require internet connection to work and I don't think there are any possible errors in the app since I made sure everything works fine. By reading apple developer's website, I understand that you need to handle possible errors properly before submitting it for review, but my question is, would I need to handle errors if there can't be any?
Consider this.
Let the set of possible errors be E.
Apple's guidelines insist that your app be robust enough that should an error e in E occur, the application handle it without crashing. This could be displaying a modal dialog informing the user of the issue; ignoring or accounting for the error and then continuing silently; changing the UI to reflect the change in process state; or any number of non-crashing control paths.
You have stated for your application that the size of the set E is 0. Since there are no elements within the set, you have handled all of the errors, implying that your assertion that you have handled all errors is vacuously true.
We had to use CoFreeUnusedLibrariesEx for fixing a bug with heap not being cleared after using a MSXML library
Refer this link:
http://blogs.msdn.com/b/marcelolr/archive/2008/11/13/msxml-heaps-not-being-released.aspx
But this caused another issue with TTimers which takes while to show up and disappears when Delphi app is bounced and again shows after a while.
This app uses TTimers to schedule it's job like running a XML transform .
Here is the issue:
When TTimer.Enable is called it throws an error not enough Timer available.
I know this is a masked error and I would have to figure out how to get to the actual error.
This is a single threaded application with only one timer.
Here are the links I looked into
Most Common reason seems to be invalid windows handle
https://groups.google.com/forum/#!topic/borland.public.delphi.winapi/UrIskaFZggU
There are other threads that suggested that OS ran out of resources for TIMERS I'm not sure if that is relevant to me.
I'm Just trying to understand what is Interaction between CoFreeUnusedLibrariesEx and TTimers that it gradually some how robs it of resources and makes us bounce the app to get it working.
How do I go about solving this issue , I'm looking for some directions?
CoFreeUnusedLibrariesEx should not affect TTimers. But if loading and unloading a (buggy) dll leaks any user objects (this includes timers, window handles, ...) then I could imagine that you run out of user objects.
Use Windows Task Manager and configure it so it will show the "USER Objects" in the "Processes" tab. Then compare the number of user objects when you call CoFreeUnusedLibrariesEx and when you don't call CoFreeUnusedLibrariesEx.