Hide Forgot
Description of problem: Opening oowriter gives a crash report. Version-Release number of selected component (if applicable): openoffice.org-core-1.9.113-1.2.0.fc5 How reproducible: Don't know. Steps to Reproduce: 1. Open attached file. 2. 3. Actual results: 0x160b0a: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1db0a 0x161358: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e358 0xae9420: + 0x420 (__kernel_sigreturn + 0x0) 0x496c08de: /lib/ld-linux.so.2 + 0x98de 0x496c4908: /lib/ld-linux.so.2 + 0xd908 0x496c9fb0: /lib/ld-linux.so.2 + 0x12fb0 0x4a97a916: /usr/lib/libcups.so.2 + 0x15916 (cupsDoFileRequest + 0x336) 0x4a96a4e2: /usr/lib/libcups.so.2 + 0x54e2 0x4a96ad28: /usr/lib/libcups.so.2 + 0x5d28 (cupsGetDests2 + 0x54) 0x4a96b018: /usr/lib/libcups.so.2 + 0x6018 (cupsGetDests + 0x48) 0x2036188: /usr/lib/openoffice.org2.0/program/libpsp680li.so + 0x51188 0x2034043: /usr/lib/openoffice.org2.0/program/libpsp680li.so + 0x4f043 (psp::CUPSManager::runDests() + 0x21) 0x2034099: /usr/lib/openoffice.org2.0/program/libpsp680li.so + 0x4f099 (psp::CUPSManager::runDestThread(void*) + 0x17) 0x15a2ad: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x172ad 0x4992eb80: /lib/libpthread.so.0 + 0x5b80 0x4979fd4e: /lib/libc.so.6 + 0xcad4e (__clone + 0x5e) Expected results: Not this, for sure ;-) Additional info:
Created attachment 116317 [details] Word file that crashes oowriter here
It doesn't crash for me when loaded, but that stack trace contains reference to cups, so it may happen with a specific printer driver, or cups configuration. What printer configuration do you have ?
I don't understand that stack trace format -- when were the top two lines involved in the stack, and what signal caused the crash? Coalan: is there any way to get a proper core file from OOo, or at least to get it to crash under gdb with debuginfo packages installed?
yeah, install the massive debuginfo packages and gdb /usr/lib/openoffice.org/program/soffice.bin (gdb) run -writer The top two few lines are just the stack trace of the stack dumper itself where it calls backtrace of /usr/include/execinfo.h
Horst: 1. Please install the cups-debuginfo package with the same version and release as the cups package you have installed (which is that btw?). 2. Then run 'gdb --args /usr/lib/openoffice.org/program/soffice.bin -writer' and enter 'run' at the (gdb) prompt. Then, when it crashes, enter 'bt' to get the stack trace. 3. Also useful is the output of 'lpstat -s', and some information about how you have configured CUPS.
1. cups-1.1.23-16 2. gdb --args /usr/lib/openoffice.org2.0/program/soffice.bin -writer Estado\ del\ arte.doc # (I assume the offending file has to be there too...) This now works fine. I don't know what could do this... at home (where this happened), I don't have access to the networked printer here. And I hadn't the Epson printer either. Funny thing is that I had opened another .doc (no trouble there), and opened this one immediately after closing oowriter with the other one. I did never get any trouble with OOo before (but then, rawhide has updated everything there a few times; and I'm no fan of WYSIWYG word processing, so...) 3. lpstat -s system default destination: printer device for epson: usb:/dev/usb/lp0 device for printer: ipp://lp-red.inf.utfsm.cl/printers/queue1 What exactly about the CUPS mess?
Can you try 'ulimit -c unlimited' and running: /usr/lib/openoffice.org2.0/program/soffice.bin -writer then opening the file? Do you get a core dump then? Without a proper stack trace this will not be very easy at all to debug.
I tried several times, and could not reproduce the crash. Sorry.