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?
Getting Dispatch Group Crash with Too many nested calls to dispatch_group_enter(). I double checked the code and there is balance of enter and leave calls. This is happening in Prod for customers. I am not able to reproduce the issue. Can someone help me reproduce the issue or help me with some suggestion on fixing this issue. Got below text in the firebase crash
BUG IN CLIENT OF LIBDISPATCH: Too many nested calls to dispatch_group_enter()
dispatch group with data retrival from DB and flushing it to network and after successful call delete the data from DB
In my chat app while running it shows the following error with parse,
Trying to retrieve from cache
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This query has an outstanding network connection. You have to wait until it's done.'
Whats wrong with this,please help me out?Thanks in advance
(For clarity, the OP is referring to the parse.com BaaS SDK).
You're probably trying to do something to a PFQuery while it's in the middle of the previous operation. Parse objects can only perform one network operation at a time. Look through your code to see whether you're making two query calls on the same query object without waiting for the first to complete.
You're probably using an old version of the Parse iOS SDK. Updating to the latest version should resolve this issue.
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.