Recently we detected a crash report in firebase with underlying possible reason being, accessing CoreData fault values in a different thread.
CoreData crashed with Fatal Exception: NSInternalInconsistencyException at _PFFaultHandlerLookupRow.
My doubt is, will firebase collect a non-crashing report associated with CoreData faulting. Such a doubt came into light because, we are not able to produce this manually. We have detected a concurrency error in code but app crash is simply not reproducible. This specific behaviour of firebase logging of above error happens in iOS 16 devices only.
I have tried debug tools of coredata and found concurrency error and detected faulting is happening in entity and code was trying to access an entity's attribute whose values are at fault state.
Question is :- Will firebase collect a non-crashing report associated with CoreData faulting?
Related
Hi we have a product of a C# WPF application riding upon a C++ engine.
Occasionally (more often than we would like) we have to debug the whole stack.
Recently I started having a crash occur in the application on the creation of a connection.
connection = Database.DefaultConnectionFactory.CreateConnection(connectionString);
yes I have tried creating a connection by this method. But it produces the same error.
var factory = DbProviderFactories.GetFactory(providerName);
connection = factory.CreateConnection();
connection.ConnectionString = connectionString;
We have a SQL CE database for storing...well data.
We access it using EF Code First.
We found in the past we could improve performance by creating ONE connection (it is one file) and reusing the connection.
The app is crashing on me WHEN it creates the connection NOT our code.
I have tried catching Exception or ExecutionEnginException (I could not find FatalExecutionEngineException)
I have also tried reinstalling the various packages related to our EF stack.
All to no avail.
Please help if you have run into this problem or a MS engineer that scours the stackoverflow boards.
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in > >'(our application)'.
Additional Information: The runtime has encountered a fatal error. The address of the error was at 0xd8ed0f68, on thread 0x2330. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
If there is a handler for this exception, the program may be safely continued.
i used Bugsense framework in iPhone application to get the crashe logs, and it works fine.
but when i get the crash report from iTunes account, the crash report indicate that there is a crash in bugSense framework.
What this is mean? is it indicate that crashes in applications reported by bugSense ? or it is actual crash in the framework itself?
Please Help.
Thx
It could be, that this is a crash in their SDK. Sadly they perform non-async safe functions in their framework once the crash happened. See http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html for more details on what that means (in this case calling Objective-C code once a crash occurred is unsafe). You might want to contact them to make the fix this possible problem.
But the messages lower in the stack trace also indicate, that this is a crash that happened because of an uncaught exception occurred, which would normally cause another Last Exception Backtrace to appear on top of Thread 0. I am not sure if they have that functionality included. If they do, this causes that block only appear in their own crash report but not in the crash reports iOS creates. Then this is nothing to worry about, except that code above being bad as already mentioned.
If you have enabled immediate dispatch in BugSense, this is probably the reason of this crash, as it isn't guaranteed to be safe.
For more info you can check this: https://github.com/bugsense/plcrashreporter-bugsense/wiki/Using-the-BugSense-2.x-iOS-library , section Enabling immediate dispatch
this may happen when there is no internet connection, try enable immediate dispatch in bug sense
I am using a sqlite query to get nutrient values for a specific food item from USDA database.
The query works fine, when tried in simulator, but results in crash on device sometimes.
I am including the USDA database in the app itself. Also the table on which the query is getting executed holds more than 5 lac records. I am getting 'Level 1 Memory Warning' at the launch of application. I cannot go for webservices, as the requirement is to give offline support.
Any suggestions how to handle this situation??
Edit :
In the log I get Signal 0 message
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
You are exhausting your app's memory. I am not a DB expert but you will have to use some special techniques to access your huge data base. Perhaps execute multiple queries serially in different sections of the DB. Or divide the DB into segments. Following are some references related to the crash you are seeing-
Program received signal: “0”. Data Formatters temporarily unavailable
Data Formatters temporarily unavailable
Data Formatters temporarily unavailable, will re-try after a 'continue'
There are more if you search for the error message.
I guess the size of the database is causing the crash...
If you are using this database as read only then you can use the compressed and encrypted form ... you can get more details from here http://www.hwaci.com/sw/sqlite/cerod.html
this might help you get rid of the memory warnings..
here is another link which can help you reduce the size of the database....
How to reduce the size of an sqlite3 database for iphone?
Memory Related Crashes are quite common for ios apps I've noticed that more stable apps tend to manually manage memory alot over just letting the device manage it. I think if you split it up into sections instead of reading off one file and like akshay said index the tables it will be more stable. You could try reading files from compressed zips which would be more efficient over just plain old reading.
i am getting a serious issue
Program received signal: “EXC_BAD_ACCESS”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
kill
quit
The Debugger has exited with status 0.(gdb)
Note:
Problem occurs when i am fetching approx more than 5000+ data on tableview (using Core data)
If data is not huge then application doesnt crash.
EXC_BAD_ACCESS means: Exception Bad Access.
This is not a Core Data error. It is an exception from trying to access an object that has been released.
Turn on NSZombie, set a breakpoint on objc_exception_throw. Then run your app again in the debugger and track down the over-release.
Don't know, but it appears to be happening because of the amount of data you are loading. This sounds like a lot of data to be loading on an iPhone. Is there anyway you can reduce the volume? Perhaps you could create a table that contains summaries of your data. Or perhaps page load 20 or 30 records at a time rather than the full 5000.
This is a rather general question, as I don't have any solid evidence atm.
I have an iPhone app with about 20,000 users. It allows users to message each other, and saves those messages in core data. The only other thing it saves in core data is the users profile, a copy locally and a copy on the server.
I have a small percentage of users complaining that they receive messages but nothing shows, when they send a message (which immediately goes into core data then shows on screen) it disappears immediately. Nothing but a full restore seems to fix it, and from what I can gather, even a restore which involves them restoring a backup they just made doesn't fix it.
My first thought was that core data must have become corrupted in some way ... but the messages they attempt to send actually do send, and this would be impossible if their local profile had become corrupted too.
I've never been able to recreate it, or found anyone face to face who has had a similar problem.
Does anyone have any suggestions on what could occur in core data that could lead to a situation like this so I can start to try and track down the problem? I'd estimate it's happening with about 1% of users.
Once again, sorry for the generality of the question, but it's all I have to work with just now!
Thanks
** Edit
Just to clarify, deleting the app and reinstalling it, does not fix the problem when this happens.
** Edit
I just had some more information from a user who is suffering from the problem ... the information my app saved in core data still exists after the app has been deleted and re-installed, all of it. I have deleted and re-installed my app hundreds of times over the last year, on countless different devices, and every time I delete and re-install, all previous data stored in core data is completely erased .. yet for these users, this is not happening. Does this sound like an iPhone issue that basically requires a restore?
** Edit 03/12/2010
AT LAST! I have some real solid information to work on. I added flurry to my latest release so I could track any core data error messages, and was able to correlate the errors received with a user id that I knew for a fact was experiencing the problem ...
The error is: "Msg: Error Domain=NSCocoaErrorDomain Code=133020 'The operation couldn’t be completed. (Cocoa error 133020.)' UserInfo=0x39c7c0 {conflictList=( 'NSMergeConflict (0x39c700) for NSManagedObject (0x38ad00) with objectID '0x375c30
Unfortunately, the error is trimmed. Flurry must have limit on the size of the message it can pass.
I don't have access to my mac and code just now, I'll start investigating as soon as I do and post back with some source code and any findings I have.
I'm having a problem like that right now. So far I have figured out that the same object is modified in two NSManagedObjectContext-s. The object X has (at least) two persistent attribites, a and b, one thread changes a, another thread changes b, and CoreData cannot merge.
The key phrase in the error message is NSMergeConflict:
Error Domain=NSCocoaErrorDomain Code=133020 "The operation couldn’t be completed. (Cocoa error 133020.)" UserInfo=0x1544c7d0 {conflictList=(
"NSMergeConflict (0xc489f40) for NSManagedObject (0xd833ca0) with objectID '0xd82b7c...
Not sure this really helps, but at least it tells you what might go wrong...
Does anyone have any suggestions on what could occur in core data that could lead to a situation like this so I can start to try and track down the problem?
About a zillion different things.
Your real problem is that you are trying to debug in a speculative fashion. To properly fix this bug, you first need to know how to reproduce the bug. There's no other way to know if you've fixed it after you've tried something.
I would not start by blaming the underlying frameworks like Core Data. Odds are your program is the one losing the data. Start with that assumption.
Does it affect these users from the moment they set up there account? Could it be something to do with their username/id/personal information?
If deleting the app completely and reinstalling doesn't solve the problem, then I'm at a loss for how it could be core data - as you yourself say, I often do this and it removes all core data each time. So if it is core data corruption, it would have to be in your construction of the core data instead of the database itself. I don't think it likely that only people who install your app would have problems with core-data being retained.
If you have contact with a user experiencing this problem, I would get them to try to create a new username that is "safe and normal".
Good Luck.