Created attachment 55420 [details]
Crash output my system generated

Found how to stop the crashing.

5) Going back in, restore, close, run Base, open existing, open Relation Design,
remove relationship tables, save, save DB, Close relation design window, OOo
does not crash.

This suggests to me that merely table being present in the relation design
window, causes the crash. I have now checked this by going back in and just
adding one table to the relation design window, saved Relation design and the
DB, moved the window so I could see what happens. On closing the window it does
crash as does trying to exit Base. When the crash happens the title of the table
window in the relation design window changes to "bad".

....

The following is the steps I tried to discover more information. I have numbered
the following items based on their order. I Copied the most important one at the
top to help ensure it is not overlooked.

1)After I go back into the document I can restore it and save it.
Closing and opening again after restore works.
At this point opening the Relation Design window shows the relation set up
previously as existing.
Closing the relation design window crashes OOo. No other action taken than to
click on the x in the upper right hand corner.

2)Going back in, restore, close, run Base, open existing, open Relation Design,
remove relationship, save, Close relation design window, OOo crashes.

3)Going back in, restore, close, run Base, open existing, open Relation Design,
remove relationship, save, save DB, Close relation design window, OOo crashes.

4)Going back in, restore, close, run Base, open existing, open Relation Design,
relationship now removed, Close relation design window, OOo crashes.

5)Going back in, restore, close, run Base, open existing, open Relation Design,
remove relationship tables, save, save DB, Close relation design window, OOo
does not crash.

note that you're in the issue tracking system of the main OpenOffice.org project
(www.openoffice.org) here.
We do not provide 64 bit builds at the moment, the version you named sounds as
if you got it from go-ooo.org, which effectively is a fork of OpenOffice.org.

Since its hard to to guess whether the bug you describe is specific to this
fork, or would also be present in a regular 64 bit build, if we had one, it
might take a while until your issue is handled. (In fact, there are people which
would suggest to immediately close the issue - I am reluctant to do this, since
in fact the problem might be in the main OOo code base, and not specific to the
fork).

In any way, I suggest you raise the issue at the place where you got your build
from.

I will try that.

The build I am using is from the main Fedora Core repository. I will check there
first.

Should some solution happen I will post what I can here if the topic is not closed.

Thanks.

Work around is to disable accessibility features under
system-preferences-personal-assistive technologies and restart the session.

Caolan McNamara at RedHat is looking into the problem:
https://bugzilla.redhat.com/show_bug.cgi?id=457193

FWIW it's a Fedora build and Fedora doesn't use go-ooo.org, just vanilla OOO
with just the patches at issue 90439 added. From the trace this is with
accessibility enabled and after enabling accessibility I can reproduce this on i386.

There are a few problems, at least one is that TableWindow has a accessibility
object associated with it that references that TableWindow, when the TableWindow
dtor is finished the OTableWindowAccess still references that dtored window and
eventually calls GetText on it.

I don't have any real solutions to the problems, but I attach a pair of
workarounds to make them "go away" which should help illustrate the problem anyway. 

Created attachment 55451 [details]
patches to workaround crash

a11y specific rather than F-9 specific

Caolan, thanks for the investigations.

That's Ocke's issue then.

I modified the patch a little bit. Now I overload the method ProcessWindowEvent
and set table to NULL when it is dying.

void OTableWindowAccess::ProcessWindowEvent( const VclWindowEvent& rVclWindowEvent )
	{
        if ( rVclWindowEvent.GetId() == VCLEVENT_OBJECT_DYING )
            m_pTable = NULL;

        VCLXAccessibleComponent::ProcessWindowEvent( rVclWindowEvent );
	}

Please review the patch I've done. Thanks.

cd dbaccess\source\ui\querydesign
cvs diff -r1.14 -r1.14.34.1 TableWindowAccess.cxx

fs->oj:
- ProcessWindowEvent should lock m_aMutex before setting m_pTable to NULL, since
  this assignment is no atomic operation.
- Not related to this bug here, but while you are there: ::containsRelation
  does not check m_pTable for being != NULL before accessing it, this has the
  potential for another crash.

looks good now

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues