Numbers quit unexpectedly when adding a new row. This is repeatable.

Ian,

I really can't put this thing out for public inspection, it's a proprietary financial product of mine.

But, I will share what I've discovered along the way and how I finally resolved this issue.

After more careful analysis, I discovered my original problem was actually associated with only one of the tables in the file. I could not add a line or, as it turned-out, delete a line or the affected table (tab) either.

After performing back-ups, I added a new table and recreated the structure, formulae, links and data based on the corrupted one. Once this was complete and its integration with the rest of the package checked-out, the problem table itself was now "functionally" isolated.

At this point, I then discovered I couldn't delete the problem table. I removed all the data, etc., and still couldn't delete it. I subsequently found I could delete only a single (blank) line at a time, from the bottom up (about 40 lines). This worked for all lines except the last one (line 1). Since it was the last line associated with what was the original table, I found I could "select" the corner "circle icon" for the table and successfully delete it. Home free? Not so fast!

Now, the blank table (tab) would not delete. I then exported the file to Numbers 09. There, I was finally able to delete the problem child. After which, I accepted the offer to upgrade the whole thing back to "Numbers 5.3".

After performing the export, tab delete, and upgrade, I discovered two things about my newly-repaired file. First, most of the links I previously restored in the replacement table were now gone (disappeared). These I replaced and all is well. Second, the newly repaired file size is now only 1.8MB, down from the original 2.8MB!

The only thing I can now add to this saga is that this spreadsheet file started out as an Excel 2010 file, imported into Numbers about fourteen months ago. Perhaps it's been harboring some "excess baggage" associated with that conversion! (In a former work-life, we called this kind of thing a "fluke"! Just fix it and move on.)

Also, I don't think any the formulas I used caused any of the problems. Outside of a couple of "Now()" instances, they are limited to financial, mathematical and reference types working with local data. And, lots of links!

And finally, I don't think file size played any part. I tried changing the file type from "single" (default) to "package" with no effect. By the way, Apple suggests using "package" file type to improve performance for files over 500MB!

Not sure what happened, but everything is OK now.

Thank you for your suggestions and interest.

Mike

Ian,

Saga continues. Adding a line still generating crash report to Apple. Excerpt below:

Crashed Thread: 4 Dispatch queue: com.apple.Numbers.TSCE.writeExclusionQueue

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11

Termination Reason: Namespace SIGNAL, Code 0xb

Terminating Process: exc handler [6482]

LinuxQuestions.org suggests:

Signal 11 (segmentation fault) means that the program accessed an unassigned memory location. It is usually a bug in the code.

For example allocating a buffer larger than available memory, not checking to see if the pointer to the buffer is non-NULL and then writing to the (non-existent) buffer.

A search turns up this issue appearing frequently over the last 10 years with various apps and OSX releases. Most recently, with PhotoShop in Mojave.

Does any of this sound familiar to you? Anyway, I just wanted to pass this along.

Mike

(Not a Linux programmer)

Thank you for the quick response Ian.

There are about 12 tabs (tables) that have numerous links between them. There's one chart with 5 table-driven curves and 4 tables each with a few, short "reference" text-boxes.

The largest table is only about 200 rows and 38 columns, there are several others that are not as big, but this spreadsheet is absolutely "lousy" with volatile formulae. The largest table would have approximately 7,600 cells, each doing something! The file is actually very responsive with very little, if any, latency even on the largest tables.

I like working with "native" apps (especially the included, free ones). But if what you say is correct, and I do tend to agree with you, then I probably need a "Numbers Plus" app! (Even if I have to pay for it. Apple, are you listening?)

I've tried most of your suggestions. Maybe I just need to tweak it a bit more to see if I can get a few more "horses" out of it.

Thank you again for your insight.

O.M.2