Hide Forgot
abrt version: 1.1.17 architecture: i686 Attached file: backtrace, 51619 bytes cmdline: /usr/lib/openoffice.org3/program/soffice.bin -quickstart -nologo -nodefault comment: I don't know if this is always reproducible. So far I ran into it twice in roughly the above scenario: tweak a template, open a file that was base on the previous version, accept to update, but don't save the changes, close file without saving. component: openoffice.org Attached file: coredump, 122744832 bytes crash_function: SfxShell::SetDisableFlags executable: /usr/lib/openoffice.org3/program/soffice.bin kernel: 2.6.35.11-83.fc14.i686.PAE package: openoffice.org-brand-1:3.3.0-20.2.fc14 rating: 4 reason: Process /usr/lib/openoffice.org3/program/soffice.bin was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1301736944 uid: 500 How to reproduce ----- 1. I have created an invoice template and used this to create some invoices. 2. Next I have made a change to the template. 3. I then opened one of the old invoices. I'm asked if I want to update the file based on the new template. I choose to do so, but I don't save yet. 4. After playing with some other files, I decided to close the old invoice and choose not to save the changes. => This results in a crash
Created attachment 489567 [details] File: backtrace
Package: openoffice.org-brand-1:3.3.0-20.2.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- See bug 693065
Please ignore comment 2. It is the result of my attempt to attach a second backtrace via abrt. But abrt apparently considered the second backtrace a duplicate of the original one, so it just added comment 2 and not the backtrace.
I tried to reproduce this with some simple examples with no success. Its clearly a crash on closing of the documents, but its not obvious from the backtrace where exactly the error lies. It might help if we could get your template, and/or some indication of what class of item got tweaked in the original.
#0 pImp->nDisableFlags = nFlags: so we can assume that "this" is busted completely #1 void SfxDispatcher::SetDisableFlags( sal_uInt32 nFlags ) { pImp->nDisableFlags = nFlags; for ( int i = int(pImp->aStack.Count()) - 1; i >= 0; --i ) pImp->aStack.Top( (sal_uInt16) i )->SetDisableFlags( nFlags ); } much less clear, i apparently is 0, which suggests that the stack contains a wrong value from elsewhere so from the stack trace alone I can't determine the problem, and I can't reproduce the problem with a simple test-case :-( If you can provide a test-case which triggers this feel free to reopen this and attach the data.