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: Motti Shneor <email@hidden>
- Date: Sun, 04 Nov 2018 21:24:48 +0200
Hi Dave and thanks for the reply.
As you can see in the stack - there isn’t actually any “code” per-se that runs
at that time. Here is the actual method that fails:
// Show the measurement browser panel, in which user can review existing
measurements for the selected sample.
-(IBAction)showMeasurements:(id)sender {
// See if a window is already open for the measurements of the selected
samples.
NSArray *docWindowControllers = self.document.windowControllers;
for (PMWaterSample *sample in [self.samplesController selectedObjects]) {
// Look for a measurement window controller for this sample
NSUInteger idx = [docWindowControllers
indexOfObjectPassingTest:^BOOL(id obj, NSUInteger idx, BOOL *stop) {
*stop = ([obj isKindOfClass:[PMXMeasurementsWindowController
class]] &&
[obj representedObject] == sample);
return *stop;
}]; // look up the name in the transfomation table.
PMXMeasurementsWindowController *mwc = nil;
if (idx == NSNotFound) {
// Open new measurements window for the sample.
mwc = [[PMXMeasurementsWindowController alloc]
initWithRepresentedObject:sample];
[self.document addWindowController:mwc];
[mwc setShouldCloseDocument:NO];
——> The following line crashes with huge stack. I never even get to “show” the
window. We crash while loading the nib file.
[mwc window]; // make sure the nib is loaded
}
else {
// measurements window already open for this sample, unhide and
bring it to front.
mwc = [docWindowControllers objectAtIndex:idx];
}
[mwc showWindow:self];
}
}
As for modifying the persistent store - I guess I don’t because the
database-document does not become “dirty”. If I double click one of the
“sample” entities that can be open - and the window is shown as expected, then
I close the document - there are no autosaves or changes recorded. The
modification time of the persistent store does not change.
However - you’re right to point at NSManagedObjectContextDidChangeNotification
— how could I get it to pop?
3 of my NSTableColumn do have a formatter for the number presented - but why
should this affect the context, The columns are not “editable” in-place.
I will attempt to delete these columns and try again…
Motti Shneor
---
Ceterum censeo Microsoftinem delendam esse
> On 4 Nov 2018, at 20:15, Dave Fernandes <email@hidden> wrote:
>
> 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