forked from amazingfate/loongoffice
25df8adbc0
commit 4b56d82c7d20ba5897d87aaf7fc94da5356b8eec converted the cli_uno library from "Managed C++" to "C++/CLI", but forgot one detail: The destructors on "ref" classes were mapped to Finalize() methods in the old syntax, but the new one maps them to Dispose() methods, which are only invoked on stack-allocated objects. Presumably this omission results in leaking of native C++ UNO objects. Reading the C++/CLI documentation i get the impression that: 1) the destructor should explicitly call the finalizer 2) the CLR will not call the finalizer itself iff the destructor is invoked http://msdn.microsoft.com/en-us/library/ms235315.aspx http://msdn.microsoft.com/en-us/library/ke3a209d%28v=vs.110%29.aspx Change-Id: I509d9b69a399c3d7d6597060ab9b7c78c5916e11 Reviewed-on: https://gerrit.libreoffice.org/11132 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
Because of the LoaderLock bug in .NET Framework 1.0 and 1.1 the cli_uno.dll is linked with the /NOENTRY switch, which prevent that the C-runtime is initialized when loading the dll. Also I removed all static c++ objects which need construction by the CRT, exception handling seems to need an initialised CRT. Therefore I added CRT initialization code in uno_initEnvironment (cli_bridge.cxx) However there is no deinitialization done because bridge libraries remain in memory until the process dies. There is actually no good place where this had to be called. If we would do that we would have to implement that the bridge can be disposed. Sell also: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vcconmixeddllloadingproblem.asp http://support.microsoft.com/?id=814472 http://www.ddj.com/dept/windows/184416689 http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx http://msdn2.microsoft.com/en-US/library/ms172219.aspx