Skip navigation
mmmsydney
Currently Being Moderated

How to fix InDesign CS6 cloud crashes while exporting to pdf?

Apr 23, 2013 1:14 AM

Tags: #export #indesign #crashes #cs6 #cloud #multipage_pdf

Hi My InDesign CS6 cloud crashes when exporting to pdf.

 

It's a Mac Book Pro, OS X 10.7.4. It shows a blank warning, and then there is a long report, here is part of it. Even all my old files can't be exported to pdf. Can any one help?

 

Process:         Adobe InDesign CS6 [325]

Path:            /Applications/Adobe InDesign CS6/Adobe InDesign CS6.app/Contents/MacOS/Adobe InDesign CS6

Identifier:      com.adobe.InDesign

Version:         8.0.0.370 (8000)

Code Type:       X86 (Native)

Parent Process:  launchd [119]

 

 

Date/Time:       2013-04-23 18:08:27.430 +1000

OS Version:      Mac OS X 10.7.4 (11E2620)

Report Version:  9

 

 

Interval Since Last Report:          572434 sec

Crashes Since Last Report:           18

Per-App Interval Since Last Report:  621470 sec

Per-App Crashes Since Last Report:   13

Anonymous UUID:                      33716403-25A9-4DBD-B3F9-99FAE5855C5D

 

 

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

 

 

Exception Type:  EXC_BAD_ACCESS (SIGBUS)

Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000

 
Replies
  • Currently Being Moderated
    Apr 23, 2013 8:21 AM   in reply to mmmsydney

    Moved from the Creative Cloud to the InDesign forum. They will be able to help you here.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 23, 2013 8:29 AM   in reply to mmmsydney

    That's not enough of the crash report to be helpful.

    Please upload the entire thing to http://pastebin.com/ and post a link here.

    (Don't post the whole thing here, it's too long for a forum post).

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 23, 2013 8:29 AM   in reply to mmmsydney

    First things first. Update InDesign to 8.0.1.

     

    Bob

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 23, 2013 5:55 PM   in reply to mmmsydney
    I've pasted the crash report here:

     

    http://pastebin.com/BfxsrutL

    Well, that is unfortunately not useful:

    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0   ???                                 0xace85630 _XHNDL_trapback_instruction + 0
    1   ???                                 0xffffffff 0 + 4294967295
    

     

    Usually there's a lot more there. Anything in Console.app?

     

    As for 8.0.1, did you try Help > Updates?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 24, 2013 12:56 AM   in reply to mmmsydney

    John means there's usually more information in the report regarding the crashed thread and yours is only two lines of not-very-helpful information (not your fault unless you edited the report).

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 24, 2013 1:07 AM   in reply to Peter Spier

    Indeed. To be more specific, typically program execution begins in a main() function, which calls some other function (say, to handle menu selections), which calls some other function (whatever menu function the user chose), which calls some other function, etc., etc., perhaps 30 or 40 functions deep.

     

    Because of the way C++ calling conventions work, the history of which function called which other function is preserved in a data structure known as the stack. (The stack also does other things). Under normal circumstances, this "stack trace" is reconstructed to form the crash report.

     

    There is one stack trace for each thread (parallel execution components of the program), but the thread that crashed is usually the only one of interest.

     

    In this case, thread 0 crashed. Its stack trace is meaningless. It contains two stack frames (e.g. functions). At the top, the most recent function is called _XHNDL_trapback_instruction, which is a pseudo address that basically tells us nothing, other than there was some sort of fault.

     

    But typically we will see what function called that top function; and the function that called that; etc., etc.

     

    In your case we do not. Allegedly the crashing code was called from the address 4294967295, or in hexadecimal 0xffffffff. And that is the largest number that a 32-bit word can hold. It is, sadly, garbage.

     

    So your stack trace tell us zilch

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 24, 2013 5:59 AM   in reply to mmmsydney

    OK, so we know the problem is in the file. That's good.

     

    Can you export iti in two pieces (front half/back half)? If you can, then it's most likely a system resources problem and you should just combine the two pieces in Acrobat Pro. If either half fails, then dived that in half again and repeat, and continue to repeat until you isolate a page that crashes, then you can isolate an image that is causing the problem.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 24, 2013 1:30 PM   in reply to mmmsydney

    Once you have a page isolated (if you can), you can start moving objects off to the pasteboard. Move half at a time, as you did woth exporting half the pages at a time. Once you know which image it is, you can open it and try to figure out waht's causing the problem. Had one the other day that was similar -- turned out to be the hidden template layer and deleting it solved the problem.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 24, 2013 1:44 PM   in reply to mmmsydney

    Sorry, we were both typing at the same time and I didn't see your post about the old files. You should still try the divide and conquer approach and see if you can isolate a problem. You'll be surprised at how fast it goes.

     

    ID can only see a little less than 4 gb of RAM, so anything beyond that on your system is not used by ID, which means that for large exports there may be a lot of swapping in and out of a "page file" in virtual memory on the hard drive. Low disk free space can be a problem in cases like this.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Apr 24, 2013 4:31 PM   in reply to Peter Spier

    ID can only see a little less than 4 gb of RAM, so anything beyond that on your system is not used by ID, which means that for large exports there may be a lot of swapping in and out of a "page file" in virtual memory on the hard drive. Low disk free space can be a problem in cases like this.

    For what it's worth, the 4GB limit (for all 32-bit programs) applies to virtual memory as well. So if you for some reason wanted ID to address more than 4GB of virutal memory, you could not.

    Paging would only come into play if you had, say, 1GB of RAM and ID wanted to use 2GB. Then it would page.

     

    (Paging could also occur if other apps are using system memory such that ID has less than 4 GB available to it.)

     

    My inclination would be to disagree about it being a system resources problem—that does not seem likely to me.

    But we really don't know what is wrong at all, so it could be anything. I wouldn't rule anything out.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)