Re: [dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

Stephan Bergmann wrote:

Stephan Bergmann wrote:

Stephan Bergmann wrote:
[...]
The interesting thing, however, is that if I re-build this test 
scenario from scratch, with a main.exe and first.dll and second.dll 
(corresponding to soffice.bin, soffice.dll, sal3.dll, resp.) built 
"by hand" (without many of the switches used in the OOo build 
env.)---then it works!  I then do not even need the MS runtime libs 
in the C:\TEST\sub directory, the process starts happily with the 
runtime libs just in the C:\TEST directory next to the executable, 
and the re-thrown exception is caught.


So, maybe there is still hope, if we can identify the critical 
difference in the build environments for the two scenarios, and adapt 
the OOo build env. correspondingly...


The magic difference appears to be the way the Windows SDK mt tool is 
called to include XXX.dll.manifest in XXX.dll itself.  The OOo build 
environment uses a resource_id of 2 (i.e., 
ISOLATIONAWARE_MANIFEST_RESOURCE_ID, cf. WinUser.h in the Windows 
SDK), while I used the default (CREATEPROCESS_MANIFEST_RESOURCE_ID, 
defined as 1).  There appears to be no particular reason to use 2 in 
solenv/inc/tg_shl.mk:1.98 and following revisions (and 
solenv/inc/_tg_shl.mk generated from it), so I am now doing a 
DEV300m11 wntmsci12.pro OOo built with those places changed to the 
default, hoping that the resulting application will work fine.  
(However, the sad truth is that such a build takes on the magnitude of 
days rather than hours for me, so it will be some time before we know 
for sure...)


...and the freshly built OOo indeed appears to work fine!

However, one detail still puzzles me:  During the OOo build, the gperf 
tool is called.  In the Sun Hamburg build environment, it is available 
as a pre-built executable (r:\btw\DEV300\gperf.exe) that appears to be 
built with the .Net 2005 compiler (it links against msvcr80.dll) but 
also, for whatever reason, links against OOo's own sal3.dll.  However, a 
copy of the sal3.dll is not placed next to gperf.exe in r:\btw\DEV300, 
so, due to the PATH settings in the build environment, the sal3.dll 
produced during the OOo build itself is used (the one in the solver, at 
wntmsci12.pro\bin\sal3.dll).  Bad as that may be, it appears to have 
always worked fine (not too much of a surprise, given that sal has a 
stable interface).  But with my changes (sal3.dll containing 
sal3.dll.manifest with resource_id 1 instead of 2), the calls to gperf 
during the OOo build now fail:



Microsoft Visual C++ Runtime Library

Runtime Error!

Program: D:\shared\solar\r\btw\DEV300\gperf.exe

R6034
An application has made an attempt to load the C runtime library 
incorrectly.

Please contatct the application's support team for more information.


followed by


gperf.exe - Application Error

The application failed to initialize properly (0xc142). Click on OK 
to terminate the application.



So I thought maybe the redistributable runtime files (msvcr90.dll etc.) 
were missing from the location where sal3.dll is located, so I copied 
them there (solver's wntmsci12.pro\bin), but the failure remained.


Does that mean that my change would mean that the URE libraries now only 
work in an executable compiled with the exact same Microsoft compiler 
version as the URE libraries themselves?  Maybe someone else can help 
shed some light on this...


As nobody was able to shed enough light on this issue to clear the fog, 
it appears to be too brittle an approach to switch from 
ISOLATIONAWARE_MANIFEST_RESOURCE_ID to 
CREATEPROCESS_MANIFEST_RESOURCE_ID and wait for all sorts of unexpected 
anomalies to pop up over time.


The next worst thing is to remove the MS runtime files from the three 
OOo layers and instead install them into the system during OOo 
installation, so we will now go down that route (and see where we get).


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

Stephan Bergmann wrote:

Stephan Bergmann wrote:
[...]
The interesting thing, however, is that if I re-build this test 
scenario from scratch, with a main.exe and first.dll and second.dll 
(corresponding to soffice.bin, soffice.dll, sal3.dll, resp.) built "by 
hand" (without many of the switches used in the OOo build env.)---then 
it works!  I then do not even need the MS runtime libs in the 
C:\TEST\sub directory, the process starts happily with the runtime 
libs just in the C:\TEST directory next to the executable, and the 
re-thrown exception is caught.


So, maybe there is still hope, if we can identify the critical 
difference in the build environments for the two scenarios, and adapt 
the OOo build env. correspondingly...


The magic difference appears to be the way the Windows SDK mt tool is 
called to include XXX.dll.manifest in XXX.dll itself.  The OOo build 
environment uses a resource_id of 2 (i.e., 
ISOLATIONAWARE_MANIFEST_RESOURCE_ID, cf. WinUser.h in the Windows SDK), 
while I used the default (CREATEPROCESS_MANIFEST_RESOURCE_ID, defined as 
1).  There appears to be no particular reason to use 2 in 
solenv/inc/tg_shl.mk:1.98 and following revisions (and 
solenv/inc/_tg_shl.mk generated from it), so I am now doing a DEV300m11 
wntmsci12.pro OOo built with those places changed to the default, hoping 
that the resulting application will work fine.  (However, the sad truth 
is that such a build takes on the magnitude of days rather than hours 
for me, so it will be some time before we know for sure...)


...and the freshly built OOo indeed appears to work fine!

However, one detail still puzzles me:  During the OOo build, the gperf 
tool is called.  In the Sun Hamburg build environment, it is available 
as a pre-built executable (r:\btw\DEV300\gperf.exe) that appears to be 
built with the .Net 2005 compiler (it links against msvcr80.dll) but 
also, for whatever reason, links against OOo's own sal3.dll.  However, a 
copy of the sal3.dll is not placed next to gperf.exe in r:\btw\DEV300, 
so, due to the PATH settings in the build environment, the sal3.dll 
produced during the OOo build itself is used (the one in the solver, at 
wntmsci12.pro\bin\sal3.dll).  Bad as that may be, it appears to have 
always worked fine (not too much of a surprise, given that sal has a 
stable interface).  But with my changes (sal3.dll containing 
sal3.dll.manifest with resource_id 1 instead of 2), the calls to gperf 
during the OOo build now fail:



Microsoft Visual C++ Runtime Library

Runtime Error!

Program: D:\shared\solar\r\btw\DEV300\gperf.exe

R6034
An application has made an attempt to load the C runtime library 
incorrectly.

Please contatct the application's support team for more information.


followed by


gperf.exe - Application Error

The application failed to initialize properly (0xc142). Click on OK 
to terminate the application.



So I thought maybe the redistributable runtime files (msvcr90.dll etc.) 
were missing from the location where sal3.dll is located, so I copied 
them there (solver's wntmsci12.pro\bin), but the failure remained.


Does that mean that my change would mean that the URE libraries now only 
work in an executable compiled with the exact same Microsoft compiler 
version as the URE libraries themselves?  Maybe someone else can help 
shed some light on this...


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

Stephan Bergmann wrote:
[...]
The interesting thing, however, is that if I re-build this test scenario 
from scratch, with a main.exe and first.dll and second.dll 
(corresponding to soffice.bin, soffice.dll, sal3.dll, resp.) built "by 
hand" (without many of the switches used in the OOo build env.)---then 
it works!  I then do not even need the MS runtime libs in the 
C:\TEST\sub directory, the process starts happily with the runtime libs 
just in the C:\TEST directory next to the executable, and the re-thrown 
exception is caught.


So, maybe there is still hope, if we can identify the critical 
difference in the build environments for the two scenarios, and adapt 
the OOo build env. correspondingly...


The magic difference appears to be the way the Windows SDK mt tool is 
called to include XXX.dll.manifest in XXX.dll itself.  The OOo build 
environment uses a resource_id of 2 (i.e., 
ISOLATIONAWARE_MANIFEST_RESOURCE_ID, cf. WinUser.h in the Windows SDK), 
while I used the default (CREATEPROCESS_MANIFEST_RESOURCE_ID, defined as 
1).  There appears to be no particular reason to use 2 in 
solenv/inc/tg_shl.mk:1.98 and following revisions (and 
solenv/inc/_tg_shl.mk generated from it), so I am now doing a DEV300m11 
wntmsci12.pro OOo built with those places changed to the default, hoping 
that the resulting application will work fine.  (However, the sad truth 
is that such a build takes on the magnitude of days rather than hours 
for me, so it will be some time before we know for sure...)


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

Jörg Budischewski wrote:
So, maybe there is still hope, if we can identify the critical 
difference in the build environments for the two scenarios, and adapt 
the OOo build env. correspondingly...
just as an idea, another possibility might be to make 
getCaughtException() inline and enforce by mapfiles, that every shared 
library keeps an instance of getCaughtException() ...


no, the bridge code would then need to be made inline, too...  :(

-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Jörg Budischewski]

So, maybe there is still hope, if we can identify the critical 
difference in the build environments for the two scenarios, and adapt 
the OOo build env. correspondingly...
just as an idea, another possibility might be to make 
getCaughtException() inline and enforce by mapfiles, that every shared 
library keeps an instance of getCaughtException() ...


Bye,

Joerg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

Stephan Bergmann wrote:

Stephan Bergmann wrote:
It has always been made quite clear that calling 
cppu::getCaughtException will only work under tightly restricted 
circumstances 
(). 
 It appears that the combination of two recent changes (the switch to 
Microsoft .Net 2005/2008 compilers together with the Three-Layer 
Office) has killed this feature completely, however.


Debugging  (of 
which  is 
probably a duplicate) shows the following:  On a Windows machine where 
the relevant compiler runtime libraries are not installed system wide 
(msvcr90.dll in the case of the .Net 2008 compiler, OOo code 
wntmsci12), msvcr90.dll is loaded multiple times into the process (it 
has to be present in both the URE\bin and Basis 3.0\program 
directories; otherwise soffice would not even start), and an exception 
thrown at desktop/source/deployment/registry/dp_registry.cxx:1.12 l. 
486 causes a crash when it is caught one stack frame up at 
desktop/source/deployment/registry/package/dp_package.cxx:1.26 l. 1187 
and cppu::getCaughtException is called.  This appears to be due to the 
fact that cppuhelper3MSC.dll and/or msci_uno.dll (implementing 
cppu::getCaughtException) are located in the URE\bin layer and use the 
instance of msvcr90.dll loaded from there while deploymentmi.uno.dll 
(implementing the desktop/source/deployment code) is located in the 
Basis 3.0\program layer and uses the other (identical) instance of 
msvcr90.dll loaded from there.


Further debugging makes the picture clearer:  In general, information 
about a thrown C++ exception (in particular the RTTI, which the C++ UNO 
bridge is interested in) is contained in the Windows SEH (Structured 
Exception Handling) EXCEPTION_RECORD that is made available to SEH 
__except handlers (and the C++ UNO bridge indeed uses such an SEH 
__except handler to get at the wanted RTTI information, see 
bridges/source/cpp_uno/msvc_win32_intel/uno2cpp.cxx:1.14 l. 272 and 
bridges/source/cpp_uno/msvc_win32_intel/except.cxx:1.17 l. 509).


However, when the thrown exception is a re-thrown one, the 
EXCEPTION_RECORD contains null values, and the relevant exception 
information has to be picked up from a per-msvcr90.dll-instance TLS 
(Thread Local Storage) block (see 
bridges/source/cpp_uno/msvc_win32_intel/except.cxx:1.17 l. 519).  Since 
the TLS block is per-msvcr90.dll-instance, and we have two such 
instances in the above scenario, the code in except.cxx looks in the 
wrong instance's block, and fails.  (The C++ Runtime itself somehow 
appears to successfully manage scenarios where an exception is thrown 
and re-thrown in the context of one msvcr90.dll instance and caught in 
the context of another, but I was unable to see the magic that makes it 
work.)


The last part (about the C++ Runtime itself working it out correctly), 
appears to be false, after all.  Stripping down soffice as follows makes 
the problem appear, without any C++ UNO bridge involved:


soffice.bin just calls soffice_main in soffice.dll; soffice.dll is 
stripped to just soffice_main, which in turn is stripped to just


  try {
throw 1;
  } catch (int &) {
TESTIT();
  }

where sal3.dll is stripped to just contain function TESTIT which does

  try {
throw;
  } catch (int &) {}

The resulting soffice.bin and soffice.dll are placed in C:\TEST 
(together with the MS runtime libs), sal3.dll is placed in C:\TEST\sub 
(also together with the MS runtime libs), PATH is set to just 
C:\TEST\sub, and C:\TEST\soffice.bin is executed---and crashes between 
the re-throw in sal3.dll and the corresponding catch.


The interesting thing, however, is that if I re-build this test scenario 
from scratch, with a main.exe and first.dll and second.dll 
(corresponding to soffice.bin, soffice.dll, sal3.dll, resp.) built "by 
hand" (without many of the switches used in the OOo build env.)---then 
it works!  I then do not even need the MS runtime libs in the 
C:\TEST\sub directory, the process starts happily with the runtime libs 
just in the C:\TEST directory next to the executable, and the re-thrown 
exception is caught.


So, maybe there is still hope, if we can identify the critical 
difference in the build environments for the two scenarios, and adapt 
the OOo build env. correspondingly...


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Frank Schönheit - Sun Microsystems Germany]

Hi Stephan,

> And all this weird code in except.cxx is only necessary because our C++ 
> UNO exceptions do not make plain C++ RTTI available (see Frank's post)! 
>   This got me thinking:  What about actually changing the C++ UNO 
> binding, conditionally for _MSC_VER >= 1500 only, for OOo 3.0, by adding 
> a virtual destructor to com::sun::star::uno::Exception?

Well, as much as I'd appreciate RTTI for our Exceptions, doing this on
one platform only is pretty dangerous. People developing on this
platform might be tempted to use RTTI outside of getCaughtException, and
such code will *silently* fail on other platforms. IMO, this is a
predetermined breaking point - if not now, then next year, or the year
after, for some new developer not knowing the backgrounds.

So, for the sake of code quality, I'd give a -1 to this.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Richard Rothwell]

On 29/04/2008, Jörg Budischewski <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> > And all this weird code in except.cxx is only necessary because our C++
> UNO exceptions do not make plain C++ RTTI available (see Frank's post)!
> This got me thinking:  What about actually changing the C++ UNO binding,
> conditionally for _MSC_VER >= 1500 only, for OOo 3.0, by adding a virtual
> destructor to com::sun::star::uno::Exception?
> >
>  I agree to your arguments on that OOo 3.0 will be incompatible eitherway.
>
>  I guess you also need to modify the bridge code to correctly create rtti
> exceptions from bridged calls. They may also be some ugly code, that handles
> exceptions like structs deep in cppu ...
>
>  Sadly I can't recall anymore why the Exception didn't get a virtual
> destructor, it was certainly discussed ...
>
>  So good luck with such a cws :-/
>
>  Bye,
>
>  Joerg
>


Hi Guys,

Please tell me if I've missed something here - because I'm sure I have
as I'm not really a C(++) programmer...

but isn't there a macro way around this?

rgds,

Richard
-- 
Richard Rothwell, [EMAIL PROTECTED]
Education Consultanthttp://m6-it.org

Web services * Back-ups * Support * Training & Certification * E-Mail
M6-IT CIC ``Software Freedom for the Education and Voluntary Sector''

M6-IT is a Community Interest Company, limited by guarantee
Registered in England & Wales,   Registration No: 6040154
11 St Marks Road, Stourbridge, West Midlands, DY9 7DT

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Jörg Budischewski]

Hi,

And all this weird code in except.cxx is only necessary because our C++ 
UNO exceptions do not make plain C++ RTTI available (see Frank's post)! 
 This got me thinking:  What about actually changing the C++ UNO 
binding, conditionally for _MSC_VER >= 1500 only, for OOo 3.0, by adding 
a virtual destructor to com::sun::star::uno::Exception?

I agree to your arguments on that OOo 3.0 will be incompatible eitherway.

I guess you also need to modify the bridge code to correctly create rtti 
exceptions from bridged calls. They may also be some ugly code, that 
handles exceptions like structs deep in cppu ...


Sadly I can't recall anymore why the Exception didn't get a virtual 
destructor, it was certainly discussed ...


So good luck with such a cws :-/

Bye,

Joerg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

Stephan Bergmann wrote:
It has always been made quite clear that calling 
cppu::getCaughtException will only work under tightly restricted 
circumstances 
(). 
 It appears that the combination of two recent changes (the switch to 
Microsoft .Net 2005/2008 compilers together with the Three-Layer Office) 
has killed this feature completely, however.


Debugging  (of 
which  is 
probably a duplicate) shows the following:  On a Windows machine where 
the relevant compiler runtime libraries are not installed system wide 
(msvcr90.dll in the case of the .Net 2008 compiler, OOo code wntmsci12), 
msvcr90.dll is loaded multiple times into the process (it has to be 
present in both the URE\bin and Basis 3.0\program directories; otherwise 
soffice would not even start), and an exception thrown at 
desktop/source/deployment/registry/dp_registry.cxx:1.12 l. 486 causes a 
crash when it is caught one stack frame up at 
desktop/source/deployment/registry/package/dp_package.cxx:1.26 l. 1187 
and cppu::getCaughtException is called.  This appears to be due to the 
fact that cppuhelper3MSC.dll and/or msci_uno.dll (implementing 
cppu::getCaughtException) are located in the URE\bin layer and use the 
instance of msvcr90.dll loaded from there while deploymentmi.uno.dll 
(implementing the desktop/source/deployment code) is located in the 
Basis 3.0\program layer and uses the other (identical) instance of 
msvcr90.dll loaded from there.


Further debugging makes the picture clearer:  In general, information 
about a thrown C++ exception (in particular the RTTI, which the C++ UNO 
bridge is interested in) is contained in the Windows SEH (Structured 
Exception Handling) EXCEPTION_RECORD that is made available to SEH 
__except handlers (and the C++ UNO bridge indeed uses such an SEH 
__except handler to get at the wanted RTTI information, see 
bridges/source/cpp_uno/msvc_win32_intel/uno2cpp.cxx:1.14 l. 272 and 
bridges/source/cpp_uno/msvc_win32_intel/except.cxx:1.17 l. 509).


However, when the thrown exception is a re-thrown one, the 
EXCEPTION_RECORD contains null values, and the relevant exception 
information has to be picked up from a per-msvcr90.dll-instance TLS 
(Thread Local Storage) block (see 
bridges/source/cpp_uno/msvc_win32_intel/except.cxx:1.17 l. 519).  Since 
the TLS block is per-msvcr90.dll-instance, and we have two such 
instances in the above scenario, the code in except.cxx looks in the 
wrong instance's block, and fails.  (The C++ Runtime itself somehow 
appears to successfully manage scenarios where an exception is thrown 
and re-thrown in the context of one msvcr90.dll instance and caught in 
the context of another, but I was unable to see the magic that makes it 
work.)


And all this weird code in except.cxx is only necessary because our C++ 
UNO exceptions do not make plain C++ RTTI available (see Frank's post)! 
 This got me thinking:  What about actually changing the C++ UNO 
binding, conditionally for _MSC_VER >= 1500 only, for OOo 3.0, by adding 
a virtual destructor to com::sun::star::uno::Exception?


- The C++ UNO bridge could be vastly simplified, in that we no longer 
need SEH and fiddling with the internals of the msvcr C++ exception 
handling to obtain the RTTI of a thrown exception.


- All involved OOo code (URE, etc.) is recompiled for OOo 3.0, anyway, 
so OOo code itself would not be affected by the incompatibility of the 
change.


- What about existing C++ extensions?
-- If they were built with an older compiler, they will not work, in 
general, anyway:
--- For one, the necessary runtime libraries for the older compiler will 
probably not be available (see 
).
--- For another, and this just dawned on me, the C++ UNO bridge 
(msci_uno.dll) already does not handle them correctly in all cases.  The 
reason is that there is only a single bridge instance for all compiler 
versions per process (the one msci_uno.dll contained in an OOo 
installation set), but its code is actually compiler dependent (see all 
the #if _MSC_VER stuff in 
bridges/source/cpp_uno/msvc_win32_intel/except.cxx:1.17).
-- If they were built with the latest compiler but before the 
incompatible change to com::sun::star::uno::Exception is made, they will 
have to be rebuilt (which implies that you should probably not 
distribute such extensions until this problem has settled on a decent 
solution...).


Thoughts, anyone?
-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Jörg Budischewski]

Hi,

- Remove all calls of the---dangerous anyway---cppu::getCaughtException 
from the OOo code base 
( lists "245 references 
in 102 files").
well the question would be how to do it, you need to offer the same 
functionality, because the code relies on it. When I got it right, just 
the rethrow causes the problem, correct (if also catching c++ exception 
in the UNO bridge layer fails, all bridges won't work either) ?


Well my C++ knowledge is a little rotten, but I think you could change 
this by  getting a cppu layer into the stack. Code like this


Any anException;
try
{
// do something
}
catch ( Exception &e )
{
anException = ::cppu::getCaughtException();
}

could be changed with a helper

- snip -
// IDL
interface XExceptionHelper : XInterface
{
void invoke();
}

// CPPU
namespace cppu
{
   // do similar cppu magic here as in current getCaughtException()
   Any catchException( const Reference< XExceptionHelper > & ref );
}
snap -

into this code :

- snip -
// declare a uno helper
class MyExceptionCatcher : public 
cppu::WeakComponentImplHelper1

{
private:
 virtual void invoke() { // do something here }
};

// exceute the code ...
Reference< XExceptionHelper > holder( new MyExceptionHelper() );
anException = cppu::catchException( holder );
if( anException.hasValue() )
{
// exception occured
}
else
{
   // all went fine
}
snap -

so replacing all occurences might be a valid solution. The work depends 
on how much is done within the try{} block (and how many reference to 
local variables are used which all must be passed and reextracted from 
the self written ExceptionHelper) ...


> Have your pick, folks.  (Or, have a beer; its Friday after all...)
well I think a beer is quite right now :-).

Bye,

Joerg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Frank Schönheit - Sun Microsystems Germany]

Hi Stephan,

> I do not see any elegant solution for this problem.  Potential but ugly 
> solutions would include:

All are ugly, aren't they ...

Judging from myself: I first got introduced to
::cppu::getCaughtException when I tried to dynamically determine the
type of the caught exception in an "catch( const Exception& e )" block -
which was impossible, since RTTI doesn't work with our exceptions.

I could easily live without getCaughtException, *if* there was another
means getting the same functionality. I think I could hardly live
without it - it makes a certain class of code much easier to write and
maintain, and less error prone.

> - Remove all calls of the---dangerous anyway---cppu::getCaughtException 
> from the OOo code base 
> ( lists "245 references 
> in 102 files").

See above. If we make the C++ UNO binding incompatible, in that we add
some polymorphism to the Exception class, so RTTI works, then I'd be
fine with that.

> - Make sure the relevant compiler runtime libraries will always be 
> installed system wide when running OOo.  (This had been discussed 
> before, but dismissed.)

This is what I consider the only viable option.

> - Use only compilers for which runtime libraries need not be installed 
> either syste wide or next to every DLL that uses them (e.g., older 
> Microsoft compilers, or GCC).

Unrealistic.

> - Turn the Three Layer Office back into a Two Layer Office, where the 
> URE and Basis layers are united (and the above scenario would again only 
> use one instance of msvcr90.dll loaded into the process, and everything 
> would probably work fine; there is also an instance of msvcr90.dll in 
> the Brand layer, but that should not interfere with any 
> cppu::getCaughtException calls).

Well ... I suppose there's a reason why the three layer architecture was
introduced ;), so this is probably not an option, too.


Other than that - is there really *no* possibility to teach shared libs
where to load the runtime libraries from?

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The evil that is cppu::getCaughtException

[Takashi Ono]

Hi all,

I would like to comment as a weekend programmer.

In message "[dev] The evil that is cppu::getCaughtException",
Stephan Bergmann wrote...
 >I do not see any elegant solution for this problem.  Potential but ugly 
 >solutions would include:

IMHO although all four options are ugly, the fourth option is only viable and 
realistic.

 >- Remove all calls of the---dangerous anyway---cppu::getCaughtException 
 >from the OOo code base 
 >(<http://lxr.go-oo.org/ident?i=getCaughtException> lists "245 references 
 >in 102 files").

It will be very difficult as we have to completely redesign bridge 
functionality.

 >- Make sure the relevant compiler runtime libraries will always be 
 >installed system wide when running OOo.  (This had been discussed 
 >before, but dismissed.)

It can be broken by other programs.

 >- Use only compilers for which runtime libraries need not be installed 
 >either syste wide or next to every DLL that uses them (e.g., older 
 >Microsoft compilers, or GCC).
 
As you are aware, MinGW port is still experimental and have problems with COM 
and 
ATL.

And as obo pointed out, older microsoft compliers have problems with Vista.

 >- Turn the Three Layer Office back into a Two Layer Office, where the 
 >URE and Basis layers are united (and the above scenario would again only 
 >use one instance of msvcr90.dll loaded into the process, and everything 
 >would probably work fine; there is also an instance of msvcr90.dll in 
 >the Brand layer, but that should not interfere with any 
 >cppu::getCaughtException calls).

Regards,

Takashi Ono ([EMAIL PROTECTED])


 Takashi Ono(HK Freak)
 mailto:[EMAIL PROTECTED] or [EMAIL PROTECTED]
(Personal Address, checked every morning/evening and holidays)
 mailto:[EMAIL PROTECTED]
(Address for business, checked every working days)
 http://www.hkfreak.net

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] The evil that is cppu::getCaughtException

[Stephan Bergmann]

It has always been made quite clear that calling 
cppu::getCaughtException will only work under tightly restricted 
circumstances 
(). 
 It appears that the combination of two recent changes (the switch to 
Microsoft .Net 2005/2008 compilers together with the Three-Layer Office) 
has killed this feature completely, however.


Debugging  (of 
which  is 
probably a duplicate) shows the following:  On a Windows machine where 
the relevant compiler runtime libraries are not installed system wide 
(msvcr90.dll in the case of the .Net 2008 compiler, OOo code wntmsci12), 
msvcr90.dll is loaded multiple times into the process (it has to be 
present in both the URE\bin and Basis 3.0\program directories; otherwise 
soffice would not even start), and an exception thrown at 
desktop/source/deployment/registry/dp_registry.cxx:1.12 l. 486 causes a 
crash when it is caught one stack frame up at 
desktop/source/deployment/registry/package/dp_package.cxx:1.26 l. 1187 
and cppu::getCaughtException is called.  This appears to be due to the 
fact that cppuhelper3MSC.dll and/or msci_uno.dll (implementing 
cppu::getCaughtException) are located in the URE\bin layer and use the 
instance of msvcr90.dll loaded from there while deploymentmi.uno.dll 
(implementing the desktop/source/deployment code) is located in the 
Basis 3.0\program layer and uses the other (identical) instance of 
msvcr90.dll loaded from there.


I do not see any elegant solution for this problem.  Potential but ugly 
solutions would include:


- Remove all calls of the---dangerous anyway---cppu::getCaughtException 
from the OOo code base 
( lists "245 references 
in 102 files").


- Make sure the relevant compiler runtime libraries will always be 
installed system wide when running OOo.  (This had been discussed 
before, but dismissed.)


- Use only compilers for which runtime libraries need not be installed 
either syste wide or next to every DLL that uses them (e.g., older 
Microsoft compilers, or GCC).


- Turn the Three Layer Office back into a Two Layer Office, where the 
URE and Basis layers are united (and the above scenario would again only 
use one instance of msvcr90.dll loaded into the process, and everything 
would probably work fine; there is also an instance of msvcr90.dll in 
the Brand layer, but that should not interfere with any 
cppu::getCaughtException calls).


Have your pick, folks.  (Or, have a beer; its Friday after all...)

-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]