Bug 693065

Summary: [abrt] openoffice.org-brand-1:3.3.0-20.2.fc14: SfxShell::SetDisableFlags: Process /usr/lib/openoffice.org3/program/soffice.bin was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: info <info>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: caolanm
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: abrt_hash:90d4baf2cc9e55905ea71c9294fa2f2417f08900
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-17 22:14:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace none

Description info@kobaltwit.be 2011-04-02 09:58:55 UTC
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

Comment 1 info@kobaltwit.be 2011-04-02 09:58:57 UTC
Created attachment 489567 [details]
File: backtrace

Comment 2 info@kobaltwit.be 2011-04-02 09:59:50 UTC
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

Comment 3 info@kobaltwit.be 2011-04-02 10:02:11 UTC
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.

Comment 4 Caolan McNamara 2011-04-04 15:30:06 UTC
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.

Comment 5 Caolan McNamara 2011-04-17 22:14:26 UTC
#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.