Created attachment 33786 [details]
resultfile with error

JSI takes it

JSI -> SUS: The testcase "tToolsXMLFilterSettings" is freezing (only in Calc,
only Linux) the office. I was nbot be able to do it manually but we have the
defined test scenario in c_updt.bas

cc'ing PJ, JSI:
JSI->PJ: I will exclude the testcase from your Calc update test include file
that the complete test can run again. SRC680m150 was the last successfull
complete run. So, there seems to be a change from m151 on.

#8  0x4194096c in __pthread_sighandler () from /lib/i686/libpthread.so.0
#9  <signal handler called>
#10 0x41b7fb71 in kill () from /lib/i686/libc.so.6
[.. 3 libc frames omitted ]
#14 0x41b80e8c in abort () from /lib/i686/libc.so.6
#15 0x4cc64515 in os::abort(int) () from
/usr/java/jre1.5.0_03/lib/i386/client/libjvm.so
#16 0x4ccecc54 in VMError::report_and_die() () from
/usr/java/jre1.5.0_03/lib/i386/client/libjvm.so
#17 0x4cc68982 in JVM_handle_linux_signal () from
/usr/java/jre1.5.0_03/lib/i386/client/libjvm.so
#18 0x4cc660b4 in signalHandler(int, siginfo*, void*) () from
/usr/java/jre1.5.0_03/lib/i386/client/libjvm.so
#19 0x41940a05 in __pthread_sighandler_rt () from /lib/i686/libpthread.so.0
#20 <signal handler called>
#21 0xbfffbb34 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb) quit

looks like a crash in Java, so probably in the dialog. It hangs because Java
locks in shutdown. 

Now, in m154, we ahve it on all platforms. Onliest difference: The other test
runs running after detecting that error.... Linux freezes the test.

SUS->PL:
When I took a look through the pp2 CWS with changes on the filter project since
m152, I recognized your fixes/enhancements on the xmfiltersettings dialog in VCL49.

There seem to be some regression when being tested by the testtool.

We created a stacktrace #1211427 by testing on my PC.
00ead328 603f32e2 xsltdlg680mi!XMLFilterTestDialog::~XMLFilterTestDialog( void
)+0x5f [o:\src680\src.m152\filter\source\xsltdialog\xmlfiltertestdialog.cxx @ 276]

There you see, that it is most likely that your changes brought up some existing
problem, calling 'delete' twice on a reference.

I workaround this and tested the changed DLL. Although both work manually, the
testtool fails without an fix.

You might want to take a look on it..
BTW was your CWS tested by the testtool?

Created attachment 33882 [details]
Diff of fix for testtool

pl->sus: if that patch fixes the problem, then it's  obvious that someone is
destroying your XMLFilterTestDialog twice. That should rather be fixed than
surviving the destructor on an already dead object in my opinion.

Now the changes in xmlfiltersettingsdialog have not changed the lifetime of the
testdialog at all, so i fail to see (it's only used as a stack object, this was
not changed), how this would be able to affect the test dialog at all is beyond me.

Evaluation has been finished:
The behaviour is different from the past-VCL49 MASTER (=>see: #i52570#. A XSLT
document which is being tested can not be closed anymore if the 'Test XSLT'
dialog is opened.
The test failed also in the VCL49 CWS but has been ignored an manually it is
impossible to close the imported XSLT document.

SUS->PL, JSI:
The problem occurs, when only an untitled/empty document is open, when the XML
FILTER SETTINGS dialog is opened.
When a Test Dialog is opened and an document is opend (for the same appication
as the open document) by browse, the empty document is exchange by the test
document (a new view in an old frame is loaded). By this the window hierachy is
changed, which is a problem for modal dialog.

Please discuss if to change the modal dialog or the automated test.

take it back to me to close it, the test have to be changed...

The test have to be changed, after discussion with LO and TPF.

closed

reopen

reassign

discussed with jsi, sus: we will backout the "fix" (actually a workaround the
Sunray XServer) for issue  52570, since it
a) introduces a usability issue by making a dialog modal that wasn't before
b) creates a crash in the test tool

Issue 52570 will be reopened and set to 2.0.3 respectively, in which timeframe i
will seek another workaround for that

fixed in CWS fix61515

please verify in CWS fix61515

re-open issue and reassign to jsi@openoffice.org

reassign to jsi@openoffice.org

reset resolution to FIXED

verified in CWS fix61515

verified in MWS m162