text of crash on win32, but also on linux

Die Anwendung in 0x5decf333 verweist auf Speicher in0x00eb00f0
Der Vorgang read konnte nicht auf dem Speicher durchgeführt werden... 

this happens when destroying the following static object

    static Reference< XComponentContext > xContext;

from basic/source/classes/sbunoobj.cxx:170 in getComponentContext_Impl

The memory of the refered Object is not mapped anymore. (it was there after
initialisation and the pointer did not change since)

.

Seems to happen only on windows.

To reproduce copy from automation the files testtool.exe and the simplecm and
communi libs in the program dir of an office and from basic the stt*.res file in
the ressource directory of the office.

Start the testtool and enter the following script:

sub  main
  bla
end sub

Run it!
It will fail but that's irrelevant for reproducing.
The Testtool will break on closing

kr wants the issue so I won't argue ;-)

The problem is, that Windows de-initializes msci_uno during termination despite
the fact, that BASIC still holds some global objects in static references, later
on Windows tries to de-initialize the BASIC library, while the virtual vtables
(these objects are Uno C++ proxies) are already un-mapped (see VTableFactory in
bridges/source/cpp_uno/shared).

So, actually, what I see is a wrong order of de-initialization, I don't know
yet, if this is a Windows feature or a dependency bug somewhere.

So, others are experiencing the same:

http://blogs.gotdotnet.com/larryosterman/archive/2004/06/10/152794.aspx

It seems, that holding references to Uno objects in global variables while dying
needs to be forbidden, because the Windows OS loader is too smart ... stupid.

Going to fix this, by avoiding the global variable.

.

.

This is duplicate to 78284.

*** This issue has been marked as a duplicate of 78284 ***

cleanup - fixed long time ago - closing