[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Crash bugs in KOffice
From:       Werner Trobin <trobin () kde ! org>
Date:       2005-10-17 14:07:24
Message-ID: 200510171607.24285.trobin () kde ! org
[Download RAW message or body]

On Monday 17 October 2005 15:44, Inge Wallin wrote:
> On Monday 17 October 2005 15.32, Boudewijn Rempt wrote:
> > We've got 57 crash bugs in bugzilla. Most of them are filter bugs,
>
> What I would like to know is why the application should crash just because
> a filter does.  Isn't that the real bug?  And is there anything we can do
> to isolate filter bugs to the filters themselves?

Filters are located in shared libraries that are dynamically loaded/unloaded 
during run-time. If the user requests to open a non-native file the KOffice 
libraries pass the control to the appropriate filter. All that happens within 
one process, so if the filter crashes, the whole process is terminated by the 
OS.

In stone age (KOffice wise, think KDE 1.x) KOffice was using CORBA for that 
stuff, so the filter was in a different process and a crashing filter did not 
take the application down. At least in theory :-)

The cost of that additional process was:
- Increased memory usage
- Increased run-time
- It was impossible to load directly to internal structures, you always had to 
convert to a file
- Way more complex to program, to get all the CORBA stuff right and so on

Therefore KOffice switched to KParts and friends, so now it's all within one 
process (also the filters, although this is not really KParts related, it 
just made sense not to use CORBA soley for the filters).

I'd also like to point out that there are two kinds of filter crashes:

1) The filter misbehaves and causes e.g. a SIGSEGV or some FP error,... Then 
it's clearly the fault of the filter, case closed.

2) The filter creates a file or loads something directly to memory and the 
application crashes when it tries to render the new document. There it could 
still be the filter's fault, e.g. if it breaks some internal assertion or 
writes out an invalid file.
In some cases, though, the application crashes on a (theoretically) correct 
file because of rendering problems.  One good example for that are .doc files 
containing large tables. The filter correctly writes them out but KWord 
crashes when it tries to render the tables.

Hope that helps,
Werner
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]