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

Question

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

Answer 1

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