Jump to content
You must now use your email address to sign in [click for more info] ×

Crash when trying to save file with Index and TOC


Recommended Posts

I have a very long file with images, multiple page masters, embedded images, etc (best way to test! :) ) which crashes randomly (haven't yet been able to determine the exact cause). 

1) I had this happen once, went back to file from 2 days earlier, opened fine, made changes, saved 23 versions of the file without issue (file v23). Next day, opened file v23 (same Publisher version) and tried to do save-as to create v24 - it crashed. Then try to go back to 22, 21, 20... all crash... but didn't crash when I did save-as originally (obviously, because I got to v 23).

2) Can save many other files, no problem.

Save as creates a zero byte file when crashing.

original file still exists with data. Can open, can work on it, also can export (if I am fast enough :) ) but save / save as / autosave all cause crash. 

Tried updating Publisher to latest RC1 (384) but didn't fix the issue.

Can attach crash data as needed (please let me know what you need). Here is beginning of Mac OSX crash log:

Also happy to send you afpub file that is crashing so you can have a look!

Quote

Process:               Affinity Publisher Beta [2288]
Path:                  /Applications/Affinity Publisher Beta.app/Contents/MacOS/Affinity Publisher Beta
Identifier:            Affinity Publisher Beta
Version:               1.7.0 (1.7.0.384)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Affinity Publisher Beta [2288]
User ID:               501

Date/Time:             2019-06-11 21:10:50.830 -0600
OS Version:            Mac OS X 10.14.4 (18E226)
Report Version:        12
Bridge OS Version:     3.0 (14Y677)
Anonymous UUID:        C5CEC00E-5482-7E46-00C7-9F17E862A471


Time Awake Since Boot: 1300 seconds

System Integrity Protection: enabled

Crashed Thread:        1  Dispatch queue: com.apple.root.default-qos

Exception Type:        EXC_BAD_ACCESS (SIGBUS)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x0000600001849401
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Bus error: 10
Termination Reason:    Namespace SIGNAL, Code 0xa
Terminating Process:   exc handler [2288]

 

Link to comment
Share on other sites

  • Staff

Hi @ea0723,

Can you please attach the file? Do you remember what build number were you using when you initially started the file? 

Can you replicate the crash from scratch? I'm asking because Build 337 was the last one which converted 1.6 adjustments to 1.7 adjustments automatically. Build 371 introduced the legacy feature, where the adjustment layers from 1.6 and pre-371 are imported as "legacy", keeping their look. If one wants to modify them, they will automatically be converted to new 1.7 adjustments.

Thanks,

Gabe.

Link to comment
Share on other sites

Hi Gabe, Thanks for your quick reply!

Yes, attached the file (v23) I don't remember which build, but it was before 1.7 (a build of 1.6 I think).

I can't recreate it from scratch ... though I've also been adjusting files that I created around the same time without issue (a lot less complex, though).

 

TRM_for_Print_v23.afpub

Link to comment
Share on other sites

You guys are dev ninjas :ph34r: :) can you tell me what the issue had to do with? I do development and usually I can pinpoint what causes something, but this one had me stumped! 

Thanks a million!

PS Glad you liked the book!!! Look for a nod to you guys and  "Affinity Serif Publisher" in the final copyright page :) 

Link to comment
Share on other sites

I have a problem very similar to ea0723.  I don't know what build I was using before today, but when I updated today, the problem was still there.

I have a very complicated file with lots of embedded pictures.  The current issue is with saving.  It saves sometimes, but doesn't other times.  When it doesn't, most of the time the save bar stays blank while it eats up hard drive space (it's gotten me down from 17GB to 25mb when I didn't catch it fast enough).  (Once or twice, it's managed to finally save after making no progress for a few minutes, but I don't know what was different about those times.  Either way, it's not ideal..)

Would you call that crashing? It doesn't automatically quit (whereas it does when I tweak a table in ways it doesn't like—but I just gave up on tables a few days ago).

I'm new to this whole tech beta thing, so I don't know if I've given you sufficient information. I'm hoping you can help.

Anyway, "game char book simplified" is the one that crashes repeatedly, while "came char book front" is a much earlier version that does not crash at all. I know that may not be helpful, but it's the best I have.

game_char_book_simplified.afpub

game char book front.afpub

Link to comment
Share on other sites

  • 1 month later...

So I just learned something today... When Affinity Publisher 1.7.1 is crashing because of a big file, you can open the file in Affinity Photo and tweak things. After replacing big images (some 16mb, some possibly 26mb) with smaller images (2-5mb), I could re-open the file in Affinity Publisher and it wouldn't crash in the first 10 seconds.  It's a miracle!

Link to comment
Share on other sites

  • 2 weeks later...

@GabrielM  I'm not sure how much this will help, but here's the file (GCB—2 alien with larger pix, in your dropbox now) that was crashing before. This time, I opened it from an external HardDrive that had much more space available than I had before (probably 10GB on my computer). It handled itself fine. Once I moved it back to my computer (now just less than 30GB), it was able to open and load, and save (though it took such a long time I began to wonder if it wouldn't).

I ended up realizing that modifying in Affinity Photo isn't a perfect fix. After I got down the size of the big photos, it handled well in Affinity Publisher. I decided to modify the photos directly through Affinity Photo, feathering edges and such. That got me an error message and corrupted the file. I took screenshots of those and uploaded them below. 

I submitted those to your dropbox, both the corrupted file (GCB—2 alien smaller--succeeded, then crashed and deleted) and the end result I was satisfied with (GCB—2 alien DONE) after rebuilding the whole thing from the one with larger pictures.

I hope this helps. It really is a great program, even if it feels like it takes a lot longer than it should to get things done.

Screen Shot 2019-07-19 at 6.01.18 PM.jpg

Screen Shot 2019-07-19 at 6.01.39 PM.jpg

Screen Shot 2019-07-19 at 6.01.59 PM.jpg

Link to comment
Share on other sites

  • Staff

Most of your files are linked and not embedded, and they are not uploaded to our dropbox. 

We have always advised to work on your files locally and not on any external/virtual/network drivers. If they get disconnected while you're working on your project, you have a chance of breaking that file. Most of the times it should be able to recover itself and let you save/as, but sometimes - like your case, it cannot do it. 

Regarding your free space, ideally, you should be having more free space on your OS drive, so that you have enough space for temp/appdata/etc, especially when you work with large files.

Link to comment
Share on other sites

@GabrielM  Thank you. I had no idea.  I'll do my best to improve my HD space in the future... And I should embed rather than link? It would certainly take some of the nerve-wracking elements out of working on these projects. How big are AfPub files meant to get? How big is too big for a file?

Link to comment
Share on other sites

  • Staff

Embedding/linking is a matter of preference, but as the project file gets bigger and bigger, it is advised you link instead of embed. 

14 hours ago, christineeb said:

How big is too big for a file?

There is no general rule for this, as it all depends on your pc specs and what it can handle. 

Link to comment
Share on other sites

One „small“ hint:

Looking at the path information provided by your screenshot, there are heavy(!) naming issues – especially, when working on servers:

No special or system reserved characters (öüäß./ and, and and) in file names and/or server directories!

Your path/filename contain blanks, apostrophes, slashes, full stops, em dashes, …, … Avoid these characters in file names, servers and network drives.

Link to comment
Share on other sites

4 hours ago, mac_heibu said:

One „small“ hint:

Looking at the path information provided by your screenshot, there are heavy(!) naming issues – especially, when working on servers:

No special or system reserved characters (öüäß./ and, and and) in file names and/or server directories!

Your path/filename contain blanks, apostrophes, slashes, full stops, em dashes, …, … Avoid these characters in file names, servers and network drives.

All of those things are perfectly allowed in Mac filesystems. Whether they work properly in a network situation is perhaps a different matter, and normally they should be handled either by the OS itself or the app that manages it (I'm thinking of Dropbox as an example), which would either disallow things that should not be allowed, or else come up with some other way to handle it. In this case, error message that christineeb posted was not from the network drive, so filename should not be a problem.

Since HFS+ about twenty years ago, Mac file names and directory names can have up to 255 UTF-16 characters, and the colon is the only reserved character. And for that reason the Mac will not let you save a file name with a colon.

It is still possible that Publisher is choking on a particular filename, and it is worth investigating. If such is the case, then I'm sure Serif will want to fix it so that all allowed filenames will work as expected.

Link to comment
Share on other sites

You have no influence, how these „exotic“ file names are handles by servers and/or network drives.

Moreover, when sending these files by email or something like that, you may run into heavy issues.

Did you ever run into issues with files like „myfile.ai.pdf“ "or myfile.psd.jpg“ No? I did frequently :)

So: Why risking this stumbling blocks? Use standard names (a–z,A–Z, minus and underscore) and you will be on the secure side of (mass storage) life.

EDIT: As Old Bruce mentioned in the next post, I forgot the numerals 1 – 0. Sorry for that!

Link to comment
Share on other sites

1 hour ago, mac_heibu said:

Why risking this stumbling blocks? Use standard names (a–z,A–Z, minus and underscore)

and 0-9 

I learned this yonks back. The argument that we can use other characters doesn't mean we have to. It would be like using emojis in source code for naming variables.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

 

52 minutes ago, Old Bruce said:

and 0-9 

I learned this yonks back. The argument that we can use other characters doesn't mean we have to.

This is all becoming amusing to me. I agree that "we can doesn't mean we have to." Totally! But also, "we don't have to doesn't mean that we can't or shouldn't." The OS itself automatically resorts to numerals to assign unique names to copies.

An important thing to keep in mind is that you learned it "yonks back." I'm so glad that we are not restricted to, for example, the limitations of DOS. But even DOS with its 8 character limit allowed numerals and certain other punctuation. I cannot imagine not being allowed to use numerals, as it is very common, especially in programming. In fact, Serif themselves have disregarded your recommendations by naming many of the files in their apps with characters that include numerals, a hyphen, and the @ symbol.

There may be occasions when a user of a more capable filesystem must make concessions to share with a user of an older, less flexible one, and so your advice would make sense in that context. But all of this is a tangent and has no bearing on the current thread at all. christineeb has not brought about this error because of the filename choices.

 

Link to comment
Share on other sites

11 hours ago, mac_heibu said:

One „small“ hint:

Looking at the path information provided by your screenshot, there are heavy(!) naming issues – especially, when working on servers:

 No special or system reserved characters (öüäß./ and, and and) in file names and/or server directories!

Your path/filename contain blanks, apostrophes, slashes, full stops, em dashes, …, … Avoid these characters in file names, servers and network drives.

@mac_heibu I had no idea... but as @garrettm30 pointed out, they're allowed in Macs. 

6 hours ago, garrettm30 said:

It is still possible that Publisher is choking on a particular filename, and it is worth investigating. If such is the case, then I'm sure Serif will want to fix it so that all allowed filenames will work as expected.

@garrettm30  I think it was more the fact that some of the linked files,  PNG images, were approaching 30MB. When I resized those original image files via Affinity Photo, and got them down to 5MB, it worked. But I couldn't replace them in Affinity Publisher without it crashing after 10 seconds, due to the multiple huge files I had linked. So I think I opened it in Affinity Photo and replaced them there. Doing so made it far more manageable for Affinity Publisher to handle the file.

Also, as @GabrielM pointed out, I should have more HD space available than the 10GB I was working with at the time. Before, it was eating up all that space as it processed the save, all the way to having no space left and I'd have to force quit and restart. Since I got my free space up to 30GB, that hasn't been an issue.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.