On 23 May 2016 at 12:57, Stephan Bergmann wrote:
>
> The crash handling code called from within the signal handler is just a
> big mess of illegal activity (that apparently happens to work some of the
> time, but is also known to fail spectacularly sometimes). Locking the
> SolarMutex is just on
On 05/18/2016 08:22 PM, Norbert Thiebaud wrote:
If we want to use multi-threading. we will have, at least, to solve
the signal handler situation, since as it stand it makes the 'promise
that this worker thread won't try to hold the solarmutex' impossible
to uphold.
The crash handling code calle
Hi Norbert,
thanks a lot for the extensive answer. Comments inline...
Am 18.05.2016 um 20:22 schrieb Norbert Thiebaud:
On Wed, May 18, 2016 at 3:43 AM, Armin Le Grand wrote:
Hi Norbert,
thanks for also having an eye on this - I am looking for the failure reports
on ci.libreoffice.org current
On Wed, May 18, 2016 at 3:43 AM, Armin Le Grand wrote:
> Hi Norbert,
>
> thanks for also having an eye on this - I am looking for the failure reports
> on ci.libreoffice.org currently, too.
> Last is from http://ci.libreoffice.org/job/lo_tb_master_linux_dbg/7195/, so
> last is from Friday, 13th (u
Hi Norbert,
thanks for also having an eye on this - I am looking for the failure
reports on ci.libreoffice.org currently, too.
Last is from http://ci.libreoffice.org/job/lo_tb_master_linux_dbg/7195/,
so last is from Friday, 13th (uhhh...)
Have you seen such or similar stacks anywhere else? In
On Tue, May 17, 2016 at 6:44 AM, Thorsten Behrens wrote:
> Norbert Thiebaud wrote:
>> The threaded work then raise() due to some memory problem and out
>> signal handler try to acquire the solar mutex ->deadlock
>>
> Eek, that's ugly. Then again, at the core is the OOM condition, which
> needs sol
Norbert Thiebaud wrote:
> The threaded work then raise() due to some memory problem and out
> signal handler try to acquire the solar mutex ->deadlock
>
Eek, that's ugly. Then again, at the core is the OOM condition, which
needs solving independently. Per chance, is that happening on a box
with ma
Recently I have had linux dbgutil build hang on occasion
The issue is that recently drawinlayer is starting using threadpool
(
https://cgit.freedesktop.org/libreoffice/core/commit/?id=657413b5deea11a850970f23cba2cf34a5bdf8ea
)
and is issuing a waitUntilEmpty() on a threadpool, while holding the
s
