Re: Need a direction. App crash in CoreData while loading a window's nib
Re: Need a direction. App crash in CoreData while loading a window's nib
- Subject: Re: Need a direction. App crash in CoreData while loading a window's nib
- From: Dave Fernandes <email@hidden>
- Date: Sun, 04 Nov 2018 13:15:23 -0500
Does your code modify anything in the persistent store during loading
(NSManagedObjectContextDidChangeNotification)? Maybe it is rounding some values
for display? This might cause infinite recursion with bindings.
> On Nov 4, 2018, at 2:42 AM, Motti Shneor <email@hidden> wrote:
>
> Thanks Richard.
>
> The data is OK. Not corrupt. I can import and export it to .csv, and I do run
> several sanity test (heavy calculations based on that data pass OK and
> provide expected results). Most important - the production build of the
> software (built half year ago), opens the same database and doesn't crash on
> the same data. It IS hanging about a second when opening those items but
> “survives” it.
>
> I cannot save it as XML easily - it is a rather big database about 500MB with
> tens of millions of entities, in 20 interrelated tables (LOTS of complicated
> relations). Most of the logic of this software is in its schema.
>
> More things I’ve done:
> 1. I tested, double-clicking different items - it seems quite consistent.
> Anything over ~2500 items to show in that window will crash while smaller
> relation sets “survive”
>
> 2. I put a symbolic breakpoint on -[NSSQLiteConnection connect] and
> double-clicked an item that opens without crashing (about 1000 related items
> to show). The behaviour is weird. I hit the breakpoint time and again, with a
> stack that looks exactly like the one I described - except that in the first
> stop there is only ONE iteration of that binding thing, next break I’ll see 2
> nested iterations of the binding calls, then 3, 4, 5 — and the stack gets
> longer and longer each hit. I did not survive to free it a 1000 times, but I
> think the rule is - it will iterate 1000 times, each time going deeper,
> until it either “survives” to open the window, or crashes for (what I think
> of as) stack overflow.
>
> 3. I tried to build with Xcode 9.4.1 (MacOS SDK 10.13) then with Xcode 10
> (MacOS SDK 10.14) - same thing. I only have my MacOS 10.13 to try running on.
> I cannot run the original Xcode (8.x) with which the production version was
> built. It won’t run on my OS.
>
> I just do not know how to go about resolving this.
>
> Another idea I had — I’m using AutoLayout in the .xib file. Maybe — for
> pre-caculating the “needed” space for some table column, it needs to know in
> advance the widths of all texts it should ever display there, hence it is
> forced to scan the whole data via some bindings before it can finally show
> the table?
>
> If so - this cannot (of course) survive longer tables. Still the question why
> older builds do survive.
>
> Motti Shneor
>
>
>> On 4 Nov 2018, at 4:18, Richard Charles <email@hidden> wrote:
>>
>>
>>> On Nov 3, 2018, at 2:47 PM, Motti Shneor <email@hidden> wrote:
>>>
>>> Can anyone suggest a way to start bisecting the issue or an idea where to
>>> look for?
>>
>> You may have bad or corrupted data in your core data persistent store. Save
>> the file out as an xml and see if you find anything suspicious.
>>
>> You could also open the sqlite file with the Base.app by Menial and see what
>> happens and take a look at the data.
>>
>> --Richard Charles
>>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden