JL on vacation... taking sb

taking p1 back, since we can't always reproduce it;
since developer has no clue, I have to try to find something....

"Exception not caught: URP_Bridge: disposed; (tid=8) Unexpected connection
closure" indicates that soffice crashed.  Without further information (stack
trace, crash report) it is hard to tell who can fix this.

@tbo:  Please provide the necessary information.

I have also experienced this one. But I saw it happening. 
- A dialogue-box came up, showing the message. And the office in the background,
had frozen. 

Optimistically as I was, I thought I'd just re-run the test and it would be
reproducable, 
but nope. (I therefore didn't make any screendump. Sorry)

But I also just noticed how the Office later suddenly drew ca 80% of my
system-resources, 
and that was several minutes after the Testtool had finished the last test. 
Everything looked fine, the Office was responding on interaction, 
but still had 80% load with, or without any work being done. 
I'm investigating further. 

Please see internal issue 144504 and stack Report ID 814389 could this be the one?

The mentioned stack report occurs when setting up an URP connection, and will
only occur since the integration of CWS sb36 on SRC680m196.  According to tbo
this matches the behavior observed in this issue, so, yes, it is most likely
that the mentioned stack report is the OOo counterpart of this remote
communication issue.  From that stack report:

#144702# Stacktrace ID: 803847
SRC680m199 unxlngi6.pro

uno_threadpool_enter [+0x1A17: after "call
_ZN15cppu_threadpool10ThreadPool5enterERKN3rtl12ByteSequenceEx@PLT", at "jmp
<uno_threadpool_enter+0x82>]
bridges_urp::ClientJob::wait
bridges_urp::localCommitChange
bridges_urp::PropertySettterThread::run
[bridges/soruce/remote/urp/urp_environment.cxx:1.20 l. 136]
...

#144504# Stacktrace ID: 814389
SRC680m199 unxsols4.pro
from Report data for report id 2710682:

rel="0x267f8" name="libuno_sal.so.3"
rel="0x27158" name="libuno_sal.so.3"
rel="0xbc52c" name="libc.so.1"
rel="0xb1998" name="libc.so.1" ordinal="_sema_post+0x5fc" path="/lib/"
rel="0x28848" name="libuno_cppu.so.3" [00028818 t
__1cPcppu_threadpoolKThreadPoolFenter6MrknDrtlMByteSequence_x_pv_; +0x30: after
"or %g0,%i0,%o1", at "call
__1cE_STLJhashtable4n0AEpair4CknDrtlMByteSequence_n0AEpair4CpnPcppu_threadpoolIJobQdDueue_C6____n0C_n0DMHashThreadId_n0AK_Select1st4n0G___n0DNEqualThreadId_n0AJallocator4n0G____Efind6Mrk2_n0AM_Ht_iterator4n0G_n0AQ_Nonconst_traits4n0G___n0C_n0H_n0I_n0J_n0K____",
before "or %g0,%i1,%o2"; cppu/source/threadpool/threadpool.cxx:1.16 l. 369]
rel="0x28ae8" name="libuno_cppu.so.3" ordinal="uno_threadpool_enter+0x38"
[00028ab0 T uno_threadpool_enter]
rel="0xc37c" name="liburp_uno.so" [0000c354 t __1cLbridges_urpJClientJobEwait6M_v_]
rel="0x17fd4" name="liburp_uno.so" [00017d08 t
__1cLbridges_urpOPropertyObjectRlocalCommitChange6MrknDrtlIOUString_pC_v_]
rel="0x4e70" name="liburp_uno.so" [00004e38 t
__1cLbridges_urpUPropertySetterThreadDrun6M_v_]
...

A useful SRC680m199 unxsols4.pro core

[1] cppu_threadpool::ThreadPool::enter(this = ???, aThreadId = CLASS, nDisposeId
= ???) (optimized), at 0xfb638858 (line ~372) in "threadpool.cxx"
[2] uno_threadpool_enter(hPool = ???, ppJob = ???) (optimized), at 0xfb638ae8
(line ~451) in "threadpool.cxx"
[3] bridges_urp::ClientJob::wait(this = ???) (optimized), at 0xf27ac37c (line
~500) in "urp_job.cxx"
[4] bridges_urp::PropertyObject::localCommitChange(this = ???, sProps = CLASS,
pbExceptionThrown = ???) (optimized), at 0xf27b7fd4 (line ~732) in
"urp_propertyobject.cxx"
[5] bridges_urp::PropertySetterThread::run(this = ???) (optimized), at
0xf27a4e70 (line ~134) in "urp_environment.cxx"
[6] threadFunc(param = ???) (optimized), at 0xf27a48d8 (line ~196) in "thread.hxx"
[7] osl_thread_start_Impl(pData = ???) (optimized), at 0xfdb1e258 (line ~279) in
"thread.c"

shows that probably ii==m_mapQueue.end() at
cppu/source/threadpool/threadpool.cxx:1.16 l. 372 ThreadPool::enter, i.e.,
ThreadPool::prepare has not been called (from
bridges/source/remote/urp/urp_job.cxx:1.16 l. 463 ClientJob::pack), i.e., the
call to pack at bridges/source/remote/urp/urp_propertyobject.cxx:1.9 l. 731
probably returned false (which is not checked for at the call side).  More
investigation necessary to tell why pack returns false.

More experimentation showed that ClientJob::pack returns false due to
"m_pBridgeImpl->m_bDisposed" at bridges/source/remote/urp/urp_job.cxx:1.16 l.
259.  On the one hand, the calling code should handle that properly, on the
other hand it is still unclear why the bridge is already disposed.

Created attachment 42479 [details]
avoid crash if bridge is disposed

Patch applied.  See testtools/bridgetest for regression testing.

@tbo: please verify

couldn't reproduce with master, but I tested the patch some time ago - there it
was ok;
verified.

integrated into src680m206 - closing

*** Issue 73595 has been marked as a duplicate of this issue. ***