[Libreoffice] subsequenttest hang ...

[Michael Meeks]

I'm poking at an endless hang in the smoketest:

#12  0xb7d24aec in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libc.so.6
#3  0xb7f1b6c0 in osl_waitCondition ()
from /data/opt/libreoffice/core/solver/unxlngi6.pro/lib/libuno_sal.so.3
#4  0xb72db42a in osl::Condition::wait (this=0xbfffb8c4, pTimeout=0x0)
at /data/opt/libreoffice/core/solver/unxlngi6.pro/inc/osl/conditn.hxx:84
#5  0xb72d9024 in (anonymous namespace)::Test::test (this=0xb7c16008)
at /data/opt/libreoffice/core/smoketestoo_native/smoketest.cxx:200
#6  0xb72d9e2e in CppUnit::TestCaller<<unnamed>::Test>::runTest(void)
(this=0xb73ac0a8)
at /data/opt/libreoffice/core/solver/unxlngi6.pro/inc/cppunit/TestCaller.h:166

	If I were a betting man I'd say this is down to us waiting on a
condition, and not spinning the main-loop; but (to be honest) this
remote-control nonsense is somewhat opaque to me. I see no live
soffice.bin process being controlled. I was slightly amazed to read:

toolkit/source/awt/AsyncCallback::addCallback()

	which seems to do nothing / not fire an exception if
Application::IsInMain() is not true - which is in itself odd.

	I have another quiescent thread:

#2  0xb7d24b44 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/libc.so.6
#3  0xb7f3f18e in ?? ()
from /data/opt/libreoffice/core/solver/unxlngi6.pro/lib/libuno_sal.so.3
#4  0xb7c28b05 in start_thread (arg=0xb7c0fb70) at pthread_create.c:297
#5  0xb7d16d5e in clone () from /lib/libc.so.6

	So - I'm tempted to say:

    Result result;
    // Shifted to main thread to work around potential deadlocks
(i112867):
    com::sun::star::awt::AsyncCallback::create(
        connection_.getComponentContext())->addCallback(
            new Callback(
                disp, url, css::uno::Sequence< css::beans::PropertyValue
>(),
                new Listener(&result)),
            css::uno::Any());
    result.condition.wait();
    CPPUNIT_ASSERT(result.success);

	should be a timed wait - but only if we fail if the timeout is
triggered (ie. not on the common path). I've committed that at 30
seconds - possibly this needs tweaking to be infinite when under the
debugger.

	Of course, the problem could well be something I've broken ;-) how to
debug it though is rather opaque to me sadly.

	HTH,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot