Issue 38213 - [src680 m64] crash when open database beamer or Bibliography component
Summary: [src680 m64] crash when open database beamer or Bibliography component
Status: CLOSED FIXED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 680m64
Hardware: All All
: P1 (highest) Trivial (vote)
Target Milestone: OOo 2.0
Assignee: marc.neumann
QA Contact: issues@dba
URL:
Keywords:
: 38216 38221 38229 (view as issue list)
Depends on:
Blocks:
 
Reported: 2004-12-01 10:41 UTC by marc.neumann
Modified: 2006-05-31 14:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
stack of the crash (2.48 KB, text/txt)
2004-12-01 11:55 UTC, Frank Schönheit 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description marc.neumann 2004-12-01 10:41:11 UTC 
1. open a new document
2. press F4
==>> crash
Comment 1 Frank Schönheit 2004-12-01 11:54:52 UTC 
fs->mav: This looks like a problem with the new file storage implementation. I'm
going to attach a stack
Comment 2 Frank Schönheit 2004-12-01 11:55:22 UTC 
Created attachment 19961 [details]
stack of the crash
Comment 3 Frank Schönheit 2004-12-01 12:01:40 UTC 
The file system storage seems to catch an exception while retrieving storage
names, and re-throw it as WrappedTargetRuntimeException - which is nowhere caught.

Several things came to my mind when seeing this:
- framework should be more exception-resistent against exceptions in components
  it faciliates. However, that's definately not the primary problem here
- I am not sure about wrapping an non-RuntimeException as
  WrappedTargetRuntimeException. Basically, a RuntimeException means "something
  went extraordinarily wrong, no chance to recover from this". Thus,
RuntimeExceptions
  are seldomly caught.
  However, when the storage now wraps a non-RuntimeException as
  (WrappedTarget)RuntimeException, then it promotes a possibly non-fatal error
  to a fatal error - as it seems to happen in this case. I tend to think that
this is  a
  questionable concept, in general.
  In this particular case, is it possible that getElementNames is allowed to
fail, and
  perhaps should simply return nothing?
Comment 4 mikhail.voytenko 2004-12-01 13:13:30 UTC 
The problem is fixed.
Comment 5 mikhail.voytenko 2004-12-01 13:23:05 UTC 
*** Issue 38221 has been marked as a duplicate of this issue. ***
Comment 6 Frank Schönheit 2004-12-01 13:25:11 UTC 
found another manifestation:
Tools|Bibliography (in a text document) crashes with the very same stack. Seems
it's a general problem with non-SFX frames ...?
Comment 7 Frank Schönheit 2004-12-01 13:34:24 UTC 
*** Issue 38216 has been marked as a duplicate of this issue. ***
Comment 8 Frank Schönheit 2004-12-01 13:34:54 UTC 
the Tools|Bibliography problem is also fixed with this - great!
Comment 9 mikhail.voytenko 2004-12-01 13:36:40 UTC 
The problem was that the broken storage based on nonexistent folder was created.
Now the correct checking is done on readonly storage creation. The framework
code accesses shared UI configuration using readonly access. So if there is no
configuration for an application ( seems to be the case for database ) the
problem is reproducible.
Comment 10 andreas.schluens 2004-12-01 13:47:59 UTC 
*** Issue 38229 has been marked as a duplicate of this issue. ***
Comment 11 andreas.schluens 2004-12-01 13:50:15 UTC 
*** Issue 38229 has been marked as a duplicate of this issue. ***
Comment 12 mikhail.voytenko 2004-12-03 12:38:51 UTC 
Ropening to send for verification.
Comment 13 mikhail.voytenko 2004-12-03 12:42:25 UTC 
Please verify the issue.
Comment 14 mikhail.voytenko 2004-12-03 12:42:51 UTC 
Setting back to fixed.
Comment 15 marc.neumann 2004-12-07 10:53:20 UTC 
verified in master
Comment 16 marc.neumann 2004-12-07 10:53:38 UTC 
close