APub Crash on Save - v1.10.0 (file specific)

[TheOtherRoland]

Of course it had to happen. Last night I finished editing the last chapter of my book and shortly thereafter, the file started to crash upon trying to save anything I tried to write afterward.

I have incremental saves, so I'm not "screwed" — but this is inconvenient.

My path to disaster likely began when I added a couple of master pages. I then noticed that my epilogue had disappeared completely. Not because I deleted it (at least not intentionally). Anyway, saving a single word correction is now impossible.

I'm on a Mac production machine using Sierra and other previous APub files work fine. So I have a corruption. What I need is a suggestion wherein I might troubleshoot what's causing it. I'm going to cut and paste into an older file and continue. I can't even do a "save as" (have to duplicate using Mac finder duplicate function.)

Any thoughts (and prayers)? Suggestions? Thanks.

I have crash reports, they seem to always suggest "bad access" but the exception codes are different for all three. I don't know what any of that means, but should there not be a consistent cause rather than a roaming one? Here's an example of crash #3: (truncated)

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000500000007
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0x500000007:
    MALLOC_LARGE_REUSABLE  00000001ca8b3000-00000001caf8b000 [ 7008K] rw-/rwx SM=PRV  
-->
    MALLOC_NANO            0000600000000000-0000600007e00000 [126.0M] rw-/rwx SM=PRV  

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib            0x00007fffc65ef34a mach_msg_trap + 10
1   libsystem_kernel.dylib            0x00007fffc65ee797 mach_msg + 55
2   com.apple.CoreFoundation          0x00007fffb08822e4 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation          0x00007fffb0881761 __CFRunLoopRun + 1361
4   com.apple.CoreFoundation          0x00007fffb0880fb4 CFRunLoopRunSpecific + 420
5   com.apple.HIToolbox               0x00007fffafddfebc RunCurrentEventLoopInMode + 240
6   com.apple.HIToolbox               0x00007fffafddfcf1 ReceiveNextEventCommon + 432
7   com.apple.HIToolbox               0x00007fffafddfb26 _BlockUntilNextEventMatchingListInModeWithFilter + 71
ETC...

 

 

[TheOtherRoland]

No, please. Don't get up. I've got this.

Anyway, I solved the problem and found a possible bug. I had to delete the entire chapter (20) — text and master pages — and then add the chapter one paragraph at a time into new content pages that I added. Why? Good of you to ask. Here's why.

I have index markers throughout that chapter and when I added a paragraph that I could see the index markers on, the file would not save after that — in most cases. So it seems that some but not all markers got corrupted. I can't imagine what I'd do if the whole index went kaput like that...

Anyway, I solved all of this by pasting that paragraph into another program, which stripped away all that marker-based coding, then I pasted it back into the book file and applied my styles again. Voila. It worked. Then I had to reassign the index markers/flags.

It was tedious as f... to do it this way, but at least I found out what was crashing 1.10 for this specific file. On other files 1.10 seemed fine, but somehow the index markers got corrupted or may have been mistakenly detached from their origin (at the end of the book) and this created the error (I assume) about "bad access."

Anyway, I got my book file working again.

However, 1.10 seems kinda sluggish to me, unlike when I was using 1.92. That's not what the advertising says. I'm getting beachballs here on my Mac Intel.

So yeah, I think 1.10 needs some tweaking to get it up to snuff.

[Dan C]

Hi @TheOtherRoland,

Our sincerest apologies for the delayed response here, the 1.10 update combined with working from home due to the pandemic has temporarily increased our response time - we're working hard to stay on top of this, so we appreciate your continued patience and understanding here!

We're very glad to hear you've been able to resolve this issue, although I can certainly understand how tedious this may have been, so again please do accept our apologies for the inconveniences here.

I'm currently checking with our team internally if this is a known issue with the 1.10 update, or if we'll require some further information from yourself for our development logs. I'll be sure to respond here ASAP with any further questions we may have.

On 8/10/2021 at 3:37 AM, TheOtherRoland said:

However, 1.10 seems kinda sluggish to me, unlike when I was using 1.92. That's not what the advertising says. I'm getting beachballs here on my Mac Intel.

I'm sorry to hear this, can you please expand on the workflow at the time of these beachballs? Does the app appear to 'freeze' when performing certain actions, or is this happening seemingly randomly? Do you have Metal Hardware Acceleration active?

[TheOtherRoland]

I had the sluggishness issue (I believe) when working on the book cover. I had embedded the graphics. I then linked them instead. That may have helped.

I haven't worked on the cover in a couple of days. I'll have to check on it again to see if the sluggishness is still there. I can't do metal on this computer. Too old - the card.