Bug 76429 - Mutex lock when resizing floating panels
Summary: Mutex lock when resizing floating panels
Status: CLOSED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.2.2.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-21 07:48 UTC by mahfiaz
Modified: 2020-02-28 21:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Backtrace (8.08 KB, text/plain)
2014-03-21 07:49 UTC, mahfiaz 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mahfiaz 2014-03-21 07:48:03 UTC 
So I had floating panel which I tried to drag with mouse from the handles to make it wider (IIRC). LO hanged.

The backtrace from later attached gdb is as attachment.
Comment 1 mahfiaz 2014-03-21 07:49:21 UTC 
Created attachment 96142 [details]
Backtrace
Comment 2 Julien Nabet 2014-03-21 23:32:05 UTC 
Stephan: thought you might be interested in this tracker (considering your work on mutex on master sources)
Comment 3 Stephan Bergmann 2014-03-24 11:20:27 UTC 
Mattias, the backtrace is unfortunately not very useful, as it only covers a single thread; what would be necessary instead is the output of "thread apply all backtrace".  (The output does contain frames 0--8 twice, but that rather looks like a copy/paste error.)  Also, frame 0 being pthread_mutex_unlock (rather than pthread_mutex_lock), I'm not sure this is a dead- or livelock.  Did the soffice.bin process consume any CPU?  But "IIRC" makes it look like you cannot reproduce this, right?
Comment 4 mahfiaz 2014-03-24 11:45:05 UTC 
It did consume all the CPU it could.

You are correct about that it did happen only once and I haven't been able to reproduce it. From now on I will keep in mind to get a backtrace on all threads when things go bad again.

Thanks a lot for the insight and your work.
Comment 5 Stephan Bergmann 2014-03-24 11:52:17 UTC 
(In reply to comment #4)
> It did consume all the CPU it could.

...so it looks more like an endless loop involving an (unknown) top part of the given (single) backtrace.  But hard to diagnose without a reproducer...
Comment 6 rishav raj 2018-07-20 10:08:22 UTC Comment hidden (spam)
Comment 7 martin loozer 2020-02-11 09:05:29 UTC Comment hidden (spam)