Apache OpenOffice (AOO) Bugzilla – Issue 73595
TestTool: adjust handling of URP bridge handling in testtool
Last modified: 2007-05-02 16:58:41 UTC
With CWs sb23, integrated into SRC680m196, the handling of remote UNO was enhanced a little. The current resulting behaviour that sometimes occurres is as following: On establishing the remote UNO connection by TestTool with the command 'getUnoApp' A messagebox comes up: Exception not caught: URP_Bridge: disposed (tid=...) Unexpected connection closure [OK] After clicking OK, TestTool vanishes/crashes, OOo already crashed before... see also issue 73372 for fixing this in OOo there is currently no hint, how to reproduce it, it just happens sometimes. Seen on Solaris Sparc and Linux. This issue is for fixing the TestTool, not to crash because of this. (Or do I need to use a TestTool based on Version SRC680m196 or later to not get the crash?)
the dialog is just there to show why the testtool crashes. It afterwards rethrows the exception (which leads to the crash) I Assume that the problem also resides in the URP bridge code or maybe AB can fix it in BASIC itself So forst assigning to AB
ab->gh: Sorry, but I don't understand what I could do in Basic to fix this. During runtime Basic usually catches all Exceptions including RuntimeException and Exception. So obviously this happens in code where not all exceptions are caught. Then I need at least a good de- scription or better a stack. Besides this: Even if Basic catched this exception what can it do besides mapping it to an error message and stop working. That's the same as the testtool application does. I think the problem is that the "Unexpected connection closure" exception is thrown at all. Who should take care of something like this, e.g. by trying to re- connect, if not the testtool application? Basic doesn't even know if it is used inside the testtool or inside an Office.
TestTool doesn't crash anymore with fixed issue 73372 in OOo, but I would have loved, that TestTool won't crash, when such an error occures.
It doesn't seem that there would be a general solution for this in the future; closing *** This issue has been marked as a duplicate of 73372 ***
.