Created attachment 55499 [details]
Apple Report

Bug is a Crash so I set heigher priority
add Keywords: aqua
add generic user: macport
add myself: rbircher

Notice: This is a Tiger issue.

@ steinsuppe
can you confirm this?

you can commet it here

.

yes I confirm -- I can reproduce this crash with an ibook 1.2 GHz PPC G4, 1.25 GB RAM, Mac OS X 10.5.4 
(OOo-Version 300m28 Build 9337

Hi
I cannot confirm with OOO300_m1 japanese version on MacOSX Tiger PowerPC.

reassign to maho

reassign

@ maho
do you create a new user?
It only happens at first start of a new user 

It is also found in OOO300DEV_m2 German version

I did some more digging and found a way to reproduce the crash as often as I wish.
procedure:
1. login as user a
2. start OO with that user
3. open up a document
4. switch to user b without logging user a off
5. start OO
6. open a document
7. close the document (no need to save, i used discard) with the closer button
8. close the application with the menu ("Quit")
-> application will crash instead of closing ... 
-> in one occasion the overall system has blocked ... (i assume a reboot with an open Terminal would 
have been possibile)

this also happens with Leopard 10.5 on Intel.

So all Mac versions are affected.

reassign

Created attachment 55838 [details]
stack with cppuhelper dbg

@sb: is it normal that after during cleanup during exit() and cxa_finalize() fancy allocations need to be 
performed? Please see the attached stack. If it is normal then please suggest a place where to catch the 
resulting bad_alloc.

@kr:  One more incarnation of issue 85084.  (For the probable cause of the
std::bad_alloc see <http://udk.openoffice.org/issues/show_bug.cgi?id=63473#desc3>.)

I am currently looking into this ... seems that the memory allocator does not
return any memory :-(

That is what I see reproducing the problem:

  :~ kayramme$  /Applications/OpenOffice.org.app/Contents/MacOS/soffice.bin
  terminate called after throwing an instance of 'std::bad_alloc'
    what():  St9bad_alloc
  sh: crash_report: command not found


Problems seems to be related to "quick" user switches and running OOo concurrently. A first instance keeps a second from terminating correctly, in 
case the second one had opened the last  document before A terminates.

To reproduce two users need to be logged in, e.g. user A and B.

Examples
What hangs / crashes:
- A: start OOo
- B: start OOo
- B: open a document
- B: close document
- B: quit OOo

- A: start OOo
- B: start OOo
- B: open a document
- B: close document
- A: quit OOo
- B: quit OOo

What works:
- A: start OOo
- B: start OOo
- A: quit OOo
- B: open a document
- B: close document
- B: quit OOo

- A: start OOo
- B: start OOo
- B: quit OOo
- A: quit OOo

.

This seems to be related to Matthias memory allocator, disabling it and using the system allocator solves this.

sal/rtl/source/alloc_global.c:rtl_memory_fini gets called to early -> std::bad_alloc

Memory needs to be the last thing in a process to get de-initialized.

Looking for ways to achieve this ... ;-)

Sorting the object files while linking SAL unfortunately does not help (neither alloc_global.o first nor last). Seems 
that the library unload/de-initialize order differs from expectations ...

Okay, it seems that in general d'tors registered with __attribute__((destructor)) get called _before_ d'tors 
of static C++ objects. Adding a C++ probe object to SAL calling rtl_memory_fini instead of using 
__attribute__((destructors)) cures the problem.

Mmmmhhh, if we used standard compliant C++ supporting that __cxa_atexit stuff, this shouldn't happen 
...

Fixed in hotmac :-)

.

@kr : thank you very much !

checked and verified in cws hotmac -> OK !

reported as fixed -> closed