Bug 107039 - Hang on Close after acknowledging save changes - mutex issue (steps in comment 34)
Summary: Hang on Close after acknowledging save changes - mutex issue (steps in commen...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.3.1.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Tor Lillqvist
URL:
Whiteboard: target:6.1.0 target:6.0.0.2
Keywords: bibisectRequest, regression
: 105062 113915 114032 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-04-08 20:53 UTC by Matt
Modified: 2018-02-14 10:03 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Database file that causes Base to hang. (40.89 KB, application/vnd.sun.xml.base)
2017-04-08 20:54 UTC, Matt
Details
Apple stack / backtrace (840.13 KB, text/plain)
2017-04-10 07:46 UTC, Alex Thurgood
Details
Relevant procmon output (164.61 KB, text/plain)
2017-06-20 02:58 UTC, Matt
Details
LLDB backtrace after forced quit from Dock (8.89 KB, text/plain)
2017-10-05 13:52 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt 2017-04-08 20:53:08 UTC
Description:
Opened database, made changes, and when I closed, it asked to save changes.
I said yes. It hangs. I have to "end task" to get it off my screen. Now, when I open that database, I have to recover it. I make simple change again, close, say "yes" to save changes, and the same thing happens.

Steps to Reproduce:
1.Open attached GarageDatabase2.odb. Recover if necessary.
2.Edit OtherMaintenanceForm. Delete the "Notes" text box.
3.Save and close the form edit window.
4. Press red X in upper right of Base to close down. 
5. Answer appropriately to save changes (not sure why it asks me this...the changes should be saved already since it is a database, but whatever).
6. Base hangs.
7. Changes are lost.

Actual Results:  
Hang forever.

Expected Results:
Close quickly.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Comment 1 Matt 2017-04-08 20:54:02 UTC
Created attachment 132409 [details]
Database file that causes Base to hang.
Comment 2 Matt 2017-04-09 10:47:37 UTC
If instead of the steps to reproduce, I change step 4 and 5 (marked with **), everything works as expected:

1.Open attached GarageDatabase2.odb. Recover if necessary.
2.Edit OtherMaintenanceForm. Delete the "Notes" text box.
3.Save and close the form edit window.
**4. Save the database with the "Save" button in the toolbar.
**5. Press the white/red X to exit base. It doesn't have to ask the question about saving since I just saved.
6. Base exits.
7. Changes are saved.

From what I can tell, if you don't save things before clicking the X in the upper corner of base, and if therefore it has to ask you to save the changes, it hangs.
Comment 3 Alex Thurgood 2017-04-10 07:21:58 UTC
No repro with

Version: 5.3.0.3
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
Threads CPU : 2; Version de l'OS :Mac OS X 10.12.3; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 4 Alex Thurgood 2017-04-10 07:42:28 UTC
Confirming with 

Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 2; OS Version: Mac OS X 10.12.3; UI Render: default; Layout Engine: new; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group

Enclosing trace
Comment 5 Alex Thurgood 2017-04-10 07:42:52 UTC
regression
Comment 6 Alex Thurgood 2017-04-10 07:44:31 UTC
mutex release/continue problem, judging by Apple stack trace
Comment 7 Alex Thurgood 2017-04-10 07:46:38 UTC
Created attachment 132439 [details]
Apple stack / backtrace
Comment 8 Alex Thurgood 2017-04-10 07:49:41 UTC
 Thread 0x149              56 samples (1-56)         priority 81 (base 81)
  <IO tier 0>
 *56  call_continuation + 23 (kernel + 658167) [0xffffff80002a0af7] 1-56
   *56  ??? (kernel + 3675647) [0xffffff80005815ff] 1-56
     *56  ??? (kernel + 5813123) [0xffffff800078b383] 1-56
       *56  lck_mtx_sleep + 132 (kernel + 1049444) [0xffffff8000300364] 1-56
         *56  thread_block_reason + 222 (kernel + 1091230) [0xffffff800030a69e] 1-56
           *56  ??? (kernel + 1095803) [0xffffff800030b87b] 1-56
             *56  machine_switch_context + 206 (kernel + 2102494) [0xffffff80004014de] 1-56
Comment 9 Alex Thurgood 2017-04-10 07:56:35 UTC
Ignore comment 8, wrong process, pasted below the mutex lock/wait on soffice process :


56  _pthread_mutex_lock_slow + 285 (libsystem_pthread.dylib + 5769) [0x7fff8bd94689] 1-56
                                                                                                                                                                            56  __psynch_mutexwait + 10 (libsystem_kernel.dylib + 105654) [0x7fff8bcadcb6] 1-56
                                                                                                                                                                             *56  psynch_mtxcontinue + 0 (pthread + 31396) [0xffffff7f80efaaa4] 1-56
Comment 10 Alex Thurgood 2017-04-10 07:59:46 UTC
With the activity that occurs beforehand :
56  _os_activity_initiate + 61 (libsystem_trace.dylib + 23613) [0x7fff8bdb1c3d] 1-56
56  -[NSApplication terminate:] + 773 (AppKit + 2391190) [0x7fff742b3c96] 1-56
56  -[NSApplication _shouldTerminate] + 843 (AppKit + 2393591) [0x7fff742b45f7] 1-56
56  -[NSDocumentController(NSInternal) __closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 307 (AppKit + 2394534) [0x7fff742b49a6] 1-56
56  -[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 1318 (AppKit + 2395891) [0x7fff742b4ef3] 1-56
56  __91-[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:]_block_invoke + 567 (AppKit + 2396884) [0x7fff742b52d4] 1-56
56  -[NSApplication _docController:shouldTerminate:] + 71 (AppKit + 2397216) [0x7fff742b5420] 1-56
Comment 11 Xisco Faulí 2017-06-19 18:43:55 UTC
I can't reproduce it in

Version: 5.3.3.2
Build ID: 1:5.3.3~rc2-0ubuntu0.16.10.1~lo0
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

nor in

Version: 6.0.0.0.alpha0+
Build ID: 08f6f9dded1b142b858c455da03319abac691655
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Could you please check again if it's fixed already? Otherwise, is it an only MAC issue ?
Comment 12 Matt 2017-06-19 20:16:49 UTC
I am running 5.3.1.2 and I can reproduce it.

1.Open attached GarageDatabase2.odb. Recover if necessary.
2.Edit OtherMaintenanceForm. Delete something.
3.Save (click disk icon) and close the form edit window (File | Close).
4. Press red X in upper right of Base to close down. 
5. Answer appropriately to save changes (not sure why it asks me this...the changes should be saved already since it is a database, but whatever).
6. Base hangs.
7. Changes are lost.

A couple of times it worked, but it still often reproduces the bug.

I'm running on Windows 7 Pro, NOT MAC.
Comment 13 Xisco Faulí 2017-06-19 20:59:28 UTC
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
Comment 14 Matt 2017-06-19 21:11:46 UTC
Tested on 5.3.3.2 (x64), reproduced the same bug.
Comment 15 Matt 2017-06-20 02:35:24 UTC
Tested version
/daily/master/Win-x86_64@42/2017-06-19_02.13.03
libo-master64~2017-06-19_02.13.03_LibreOfficeDev_6.0.0.0.alpha0_Win_x64.msi 
By the way, this took an exceedingly long time to download.

aka Version: 6.0.0.0.alpha0+ (x64)

Build ID: 493407c470e7051a801e2a0ad8253f7b87c4434f
CPU threads: 8; OS: Windows 6.1; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-19_02:13:03
Locale: en-US (en_US); Calc: CL

The bug happens in this version too.
Comment 16 Matt 2017-06-20 02:58:09 UTC
Created attachment 134149 [details]
Relevant procmon output
Comment 17 Matt 2017-06-20 03:00:29 UTC
See soffice.procmon.log. 

I cannot deciper what is happening between 10:53:19 (when I hit the red x to close base) and 10:53:28.

At that point it seems that every 10 seconds, soffice.bin is writing or trying to write to file database.odb.lck. It just keeps doing that forever.
Comment 18 Xisco Faulí 2017-06-20 07:18:28 UTC
Hi Matt,
Thanks for testing it again. Maybe I did something wrong when I tested it.
Could someone reproduce it on Linux ?
Comment 19 Matt 2017-06-20 12:41:34 UTC
Tried to test on Linux
Version: 5.1.6.2
Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group

When I open the database file (attachment #1), LibreOffice errors out:

General Error.
General input/output error.

So I can't run the test we want, at least not yet.
Comment 20 wdehoog 2017-09-26 11:18:16 UTC
I am having this same problem on windows 10 with version 5.4.1.2 (x64). Using a database connection type: PostgreSQL.
Comment 21 Ferry Toth 2017-09-27 13:29:48 UTC
I can easily reproduce this LibO 5.4.1.2 on Ubuntu:

- Create a new empty database
- Create a new empty table using the wizard

Don't save the modified database now

- Press the close button in the title bar or click <File><Quit>
- Save dialog box appears
- Click OK

LibO hangs forever with 0% CPU usage. Needs to be KILL, TERM won't work.

Start LibO again, recovery starts. Changes to the database structure have been saved (not recovered as the save button shows no changes needed to be saved).

Reproducible: every time

Time needed to reproduce: 2 min
Comment 22 Vladimir Potapov 2017-10-03 08:23:01 UTC
(In reply to Ferry Toth from comment #21)
> - Press the close button in the title bar or click <File><Quit>
> - Save dialog box appears
> - Click OK
> 
> LibO hangs forever with 0% CPU usage. Needs to be KILL, TERM won't work.
I confirm the issue for ROSA Linux with two arch (i586 and X64)
Comment 23 Vladimir Potapov 2017-10-03 08:29:32 UTC
(In reply to Vladimir Potapov from comment #22)
> I confirm the issue for ROSA Linux with two arch (i586 and X64)
for versions 5.4.1.2 and 5.4.2.1
Comment 24 Xisco Faulí 2017-10-03 08:33:32 UTC
Confirmed in

Version: 6.0.0.0.alpha0+
Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

bisecting...
Comment 25 Xisco Faulí 2017-10-03 08:50:18 UTC
The issue is not reproducible in the bisect repositories...
Comment 26 Xisco Faulí 2017-10-03 08:51:26 UTC
Adding Jan-Marek just in case he might have any idea about it...
Comment 27 Alex Thurgood 2017-10-05 13:49:04 UTC
Still happening on :

Version: 6.0.0.0.alpha0+
Build ID: 0cb424fec7389801578085b618c5ad68a98f4637
CPU threads: 4; OS: Mac OS X 10.13; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 28 Alex Thurgood 2017-10-05 13:52:51 UTC
Created attachment 136780 [details]
LLDB backtrace after forced quit from Dock

Enclosing LLDB backtrace after forced quit from OSX Dock. 

After the app hangs, I right mouse button clicked on the LO icon in the OSX Dock and chose Force Quit from the context menu. The LO icon then disappears from the Dock, but the main ODB window is left hanging on the screen.

The lldb trace was obtained with the main ODB window still displayed after the app icon had disappeared from the OSX Dock.
Comment 29 Alex Thurgood 2017-10-05 13:56:43 UTC
Notice how :

frame #3: 0x00000001000cabae libuno_sal.dylib.3`::osl_acquireMutex(pMutex=<unavailable>) at mutex.cxx:97
    frame #4: 0x000000017d8aa5bc libfwklo.dylib`osl::Mutex::acquire(this=<unavailable>) at mutex.hxx:56


an attempt is made to acquire a mutex lock on a mutex that doesn't exist...seems like there is a synchronization issue here when the user invokes the Save routine after ordering the main window to close.
Comment 30 Jan-Marek Glogowski 2017-10-05 17:06:35 UTC
(In reply to Alex Thurgood from comment #29)
> Notice how :
> 
> frame #3: 0x00000001000cabae
> libuno_sal.dylib.3`::osl_acquireMutex(pMutex=<unavailable>) at mutex.cxx:97
>     frame #4: 0x000000017d8aa5bc
> libfwklo.dylib`osl::Mutex::acquire(this=<unavailable>) at mutex.hxx:56
> 
> 
> an attempt is made to acquire a mutex lock on a mutex that doesn't
> exist...seems like there is a synchronization issue here when the user
> invokes the Save routine after ordering the main window to close.

That just means the value is optimized out and the function is inlined. This is no problem. Locking in the DB code OTOH is problematic.
Comment 31 Matt 2017-11-24 22:04:28 UTC
*** Bug 114032 has been marked as a duplicate of this bug. ***
Comment 32 robert 2017-12-09 16:56:26 UTC
*** Bug 105062 has been marked as a duplicate of this bug. ***
Comment 33 Tor Lillqvist 2018-01-01 10:20:04 UTC
Is anybody able to reproduce this in a current master build on Linux or macOS? Please provide *exact* reproduction details. Don't leave out details that you think "surely developers get this". Be sure to mention whether using a HSQLDB or Firebird database.

(For instance, comment #21 talks about <File><Quit>. There is no such menu entry. Does it mean <File><Exit LibreOfficeDev>?)
Comment 34 Matt 2018-01-01 13:28:24 UTC
Reproduced in 5.4.3.2 on Windows 7 x64.

1. Start LibreOffice. Create new Base Database
2. Use default settings - Create a new database, HSQLDB Embedded. Click Finish.
3. Save as New Database.odb (default name)
4. Use Wizard to Create Table
5. Click Available fields Notes and move it to the Selected fields column.
6. Click Finish
7. Close the resulting Tasks table using the red/white x in the upper right of the window.
8. Close the database entirely using the red/white x in the upper right of the window.
9. When it asks, click Save.
10. Base hangs. Wait forever or kill it.
Comment 35 Matt 2018-01-01 13:46:37 UTC
Reproduced on 5.4.4.2 Windows x64, same steps as Comment #34 (https://bugs.documentfoundation.org/show_bug.cgi?id=107039#c34)

Version: 5.4.4.2 (x64)
Build ID: 2524958677847fb3bb44820e40380acbe820f960
CPU threads: 8; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: group
Comment 36 Matt 2018-01-01 13:53:32 UTC
I had previously reproduced this on 
Version: 6.0.0.0.alpha0+ (x64)
Build ID: 493407c470e7051a801e2a0ad8253f7b87c4434f
CPU threads: 8; OS: Windows 6.1; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-19_02:13:03
Locale: en-US (en_US); Calc: CL

Now I try with the latest alpha:
Version: 6.0.0.1 (x64)
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 8; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: group

And it reproduces here too, same steps as in Comment 34.

I am attempting to get the 6.0.0.1 running on my Linux. Stand by.
Comment 37 Matt 2018-01-01 14:54:54 UTC
Reproduced on 6.0.0.1 Linux Ubuntu 17.10
Same steps as Comment 34

Version: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 2; OS: Linux 4.13; UI render: default; VCL: gtk2;
Locale: en-CA (en_CA.UTF-8); Calc: group
Comment 38 Tor Lillqvist 2018-01-01 15:06:46 UTC
Thanks, Matt. Indeed, hangs for me, too. (Also on Linux, built from master branch.)
Comment 39 Tor Lillqvist 2018-01-01 17:00:55 UTC
Here are the backtraces from the two threads that deadlock, as far as I understand:

(gdb) i thr
  Id   Target Id         Frame 
* 1    Thread 0x7f4957d49ac0 (LWP 3567) "soffice.bin" 0x00007f4956ee23bd in __lll_lock_wait () from /lib64/libpthread.so.0
  2    Thread 0x7f492f897700 (LWP 3569) "rtl_cache_wsupd" 0x00007f4956edf1f6 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  3    Thread 0x7f492d28e700 (LWP 3572) "PipeIPC" 0x00007f49572085eb in accept () from /lib64/libc.so.6
  4    Thread 0x7f4925d1b700 (LWP 3574) "SelectionManage" 0x00007f49571fb30b in poll () from /lib64/libc.so.6
  5    Thread 0x7f492551a700 (LWP 3576) "ICEConnectionWo" 0x00007f49571fb30b in poll () from /lib64/libc.so.6
  6    Thread 0x7f492dca1700 (LWP 3583) "DocumentEventNo" 0x00007f4956ee23bd in __lll_lock_wait () from /lib64/libpthread.so.0
  7    Thread 0x7f490c90e700 (LWP 3584) "UNO AffineBridg" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  8    Thread 0x7f490c10d700 (LWP 3585) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  9    Thread 0x7f48f664f700 (LWP 3586) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  10   Thread 0x7f48f654e700 (LWP 3587) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  11   Thread 0x7f48f644d700 (LWP 3588) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  12   Thread 0x7f48f634c700 (LWP 3589) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  13   Thread 0x7f48f624b700 (LWP 3590) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  14   Thread 0x7f48f614a700 (LWP 3591) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  15   Thread 0x7f48f6049700 (LWP 3592) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  16   Thread 0x7f48ef1f1700 (LWP 3593) "soffice.bin" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  17   Thread 0x7f48ef0f0700 (LWP 3594) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  18   Thread 0x7f48ee8ef700 (LWP 3595) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  19   Thread 0x7f48ee0ee700 (LWP 3596) "soffice.bin" 0x00007f4956ee1986 in do_futex_wait.constprop () from /lib64/libpthread.so.0
  20   Thread 0x7f48ed8ed700 (LWP 3597) "soffice.bin" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  21   Thread 0x7f48ed7ec700 (LWP 3598) "soffice.bin" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  22   Thread 0x7f48ed6eb700 (LWP 3599) "soffice.bin" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  23   Thread 0x7f48ed5ea700 (LWP 3600) "soffice.bin" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  24   Thread 0x7f48ed4e9700 (LWP 3601) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  25   Thread 0x7f48ecce8700 (LWP 3602) "soffice.bin" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  26   Thread 0x7f48ecbe7700 (LWP 3603) "UNO AffineBridg" 0x00007f4956edf14a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  27   Thread 0x7f491a3df700 (LWP 3604) "soffice.bin" 0x00007f4956edec4b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

(gdb) bt
#0  0x00007f4956ee23bd in __lll_lock_wait () at /lib64/libpthread.so.0
#1  0x00007f4956edb1d8 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2  0x00007f4957945743 in osl_acquireMutex(oslMutexImpl*) (pMutex=0x22b29a0) at /ssd1/lo/fedora/sal/osl/unx/mutex.cxx:97
#3  0x00007f492687ff78 in osl::Mutex::acquire() (this=0x1f4c858) at /ssd1/lo/fedora/include/osl/mutex.hxx:56
#4  0x00007f49268a0203 in osl::Guard<osl::Mutex>::Guard(osl::Mutex&) (this=0x7ffd92ccedd0, t=...) at /ssd1/lo/fedora/include/osl/mutex.hxx:129
#5  0x00007f49269b8819 in (anonymous namespace)::CacheLockGuard::lock(bool) (this=0x7ffd92cceee8, bLockForAddRemoveVectorItems=false) at /ssd1/lo/fedora/framework/source/services/autorecovery.cxx:1131
#6  0x00007f49269b6b69 in (anonymous namespace)::CacheLockGuard::CacheLockGuard((anonymous namespace)::AutoRecovery*, osl::Mutex&, int&, bool) (this=0x7ffd92cceee8, 
    pOwner=0x1f4c7e0, rMutex=..., rCacheLock=@0x1f4c9b8: 1, bLockForAddRemoveVectorItems=false) at /ssd1/lo/fedora/framework/source/services/autorecovery.cxx:1119
#7  0x00007f49269c923f in (anonymous namespace)::AutoRecovery::implts_markDocumentModifiedAgainstLastBackup(com::sun::star::uno::Reference<com::sun::star::frame::XModel> const&) (this=0x1f4c7e0, xDocument=uno::Reference to (dbaccess::ODatabaseDocument *) 0x218a0f8) at /ssd1/lo/fedora/framework/source/services/autorecovery.cxx:2540
#8  0x00007f49269b154c in (anonymous namespace)::AutoRecovery::modified(com::sun::star::lang::EventObject const&) (this=0x1f4c7e0, aEvent=...) at /ssd1/lo/fedora/framework/source/services/autorecovery.cxx:1657
#9  0x00007f4919183eee in comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::util::XModifyListener, com::sun::star::lang::EventObject>::operator()(com::sun::star::uno::Reference<com::sun::star::util::XModifyListener> const&) const (this=0x7ffd92ccf0a0, listener=uno::Reference to ((anonymous namespace)::AutoRecovery *) 0x1f4c850) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:272
#10 0x00007f4919183cc2 in comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::util::XModifyListener, comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::util::XModifyListener, com::sun::star::lang::EventObject> >(comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::util::XModifyListener, com::sun::star::lang::EventObject> const&) (this=0x218a1b8, func=...)
    at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:285
#11 0x00007f4919173037 in comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::util::XModifyListener, com::sun::star::lang::EventObject>(void (com::sun::star::util::XModifyListener::*)(com::sun::star::lang::EventObject const&), com::sun::star::lang::EventObject const&) (this=0x218a1b8, NotificationMethod=&virtual table offset 32, Event=...) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:298
#12 0x00007f491915f214 in dbaccess::ODatabaseDocument::impl_setModified_nothrow(bool, dbaccess::DocumentGuard&) (this=0x218a090, _bModified=true, _rGuard=...)
    at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/databasedocument.cxx:1313
#13 0x00007f491916651e in dbaccess::ODatabaseDocument::setModified(unsigned char) (this=0x218a090, _bModified=1 '\001') at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/databasedocument.cxx:1291
#14 0x00007f49191f1b58 in dbaccess::ODatabaseModelImpl::setModified(bool) (this=0x1f4ae20, _bModified=true) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/ModelImpl.cxx:884
#15 0x00007f49191f972a in dbaccess::ODatabaseModelImpl::storageIsModified() (this=0x1f4ae20) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/ModelImpl.cxx:1310
#16 0x00007f4951c69c57 in sfx2::DocumentStorageModifyListener::modified(com::sun::star::lang::EventObject const&) (this=0x24dc310) at /ssd1/lo/fedora/sfx2/source/doc/docstoragemodifylistener.cxx:59
#17 0x00007f490e1133e2 in OStorage::BroadcastModifiedIfNecessary() (this=0x24e6310) at /ssd1/lo/fedora/package/source/xstor/xstorage.cxx:1940
#18 0x00007f490e12c0c1 in OStorage::setModified(unsigned char) (this=0x24e6310, bModified=1 '\001') at /ssd1/lo/fedora/package/source/xstor/xstorage.cxx:3743
#19 0x00007f490e12a8aa in OStorage::commit() (this=0x2567160) at /ssd1/lo/fedora/package/source/xstor/xstorage.cxx:3608
#20 0x00007f4919240037 in dbaccess::tools::stor::commitStorageIfWriteable(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&) (_rxStorage=uno::Reference to (OStorage *) 0x2567168)
    at /ssd1/lo/fedora/dbaccess/source/core/misc/sdbcoretools.cxx:139
#21 0x00007f49191f1048 in dbaccess::DocumentStorageAccess::commitEmbeddedStorage(bool) (this=0x24eb620, _bPreventRootCommits=false) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/ModelImpl.cxx:269
#22 0x00007f49191f6a8e in dbaccess::ODatabaseModelImpl::commitEmbeddedStorage(bool) (this=0x1f4ae20, _bPreventRootCommits=false) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/ModelImpl.cxx:858
#23 0x00007f491919771d in dbaccess::ODatabaseSource::flushed(com::sun::star::lang::EventObject const&) (this=0x22e9230) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/datasource.cxx:1260
#24 0x00007f491918ce10 in dbaccess::FlushNotificationAdapter::flushed(com::sun::star::lang::EventObject const&) (this=0x2874720, rEvent=...) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/datasource.cxx:166
#25 0x00007f490d02cace in comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::util::XFlushListener, com::sun::star::lang::EventObject>::operator()(com::sun::star::uno::Reference<com::sun::star::util::XFlushListener> const&) const (this=0x7ffd92ccffc0, listener=uno::Reference to (dbaccess::FlushNotificationAdapter *) 0x2874748) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:272
#26 0x00007f490d02c882 in comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::util::XFlushListener, comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::util::XFlushListener, com::sun::star::lang::EventObject> >(comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::util::XFlushListener, com::sun::star::lang::EventObject> const&) (this=0x25842b0, func=...)
    at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:285
#27 0x00007f490d0283f7 in comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::util::XFlushListener, com::sun::star::lang::EventObject>(void (com::sun::star::util::XFlushListener::*)(com::sun::star::lang::EventObject const&), com::sun::star::lang::EventObject const&) (this=0x25842b0, NotificationMethod=&virtual table offset 32, Event=...) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:298
#28 0x00007f490d025f70 in connectivity::hsqldb::OHsqlConnection::flush() (this=0x2584200) at /ssd1/lo/fedora/connectivity/source/drivers/hsqldb/HConnection.cxx:160
#29 0x00007f492e27f4ae in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) (pThis=0x2584250, nVtableIndex=3, pRegisterReturn=0x7ffd92cd0fc0, pReturnTypeRef=0xbcfb50, bSimpleReturn=true, pStack=0x7ffd92cd0250, nStack=0, pGPR=0x7ffd92cd0560, pFPR=0x7ffd92cd0520) at /ssd1/lo/fedora/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
#30 0x00007f492e27e045 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) (pThis=0x2577e10, aVtableSlot=..., pReturnTypeRef=0xbcfb50, nParams=0, pParams=0x0, pUnoReturn=0x7ffd92cd0fc0, pUnoArgs=0x7ffd92cd09e0, ppUnoExc=0x7ffd92cd0b08)
    at /ssd1/lo/fedora/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233
#31 0x00007f492e27d7c1 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) (pUnoI=0x2577e10, pMemberDescr=0x2ca40e0, pReturn=0x7ffd92cd0fc0, pArgs=0x7ffd92cd09e0, ppException=0x7ffd92cd0b08) at /ssd1/lo/fedora/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:420
#32 0x00007f490d99986d in com::sun::star::uno::UnoInterfaceReference::dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const (this=0x2ca1338, pMemberType=0x2ca40e0, pReturn=0x7ffd92cd0fc0, pArgs=0x7ffd92cd09e0, ppException=0x7ffd92cd0b08) at /ssd1/lo/fedora/include/uno/dispatcher.hxx:173
#33 0x00007f490d9960f6 in (anonymous namespace)::binuno_proxy_dispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) (pUnoI=0x2ca1310, pMemberType=0x2ca40e0, pReturn=0x7ffd92cd0fc0, pArgs=0x7ffd92cd09e0, ppException=0x7ffd92cd0b08) at /ssd1/lo/fedora/stoc/source/proxy_factory/proxyfac.cxx:275
#34 0x00007f490d99986d in com::sun::star::uno::UnoInterfaceReference::dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const (this=0x2ca1598, pMemberType=0x2ca40e0, pReturn=0x7ffd92cd0fc0, pArgs=0x7ffd92cd09e0, ppException=0x7ffd92cd0b08) at /ssd1/lo/fedora/include/uno/dispatcher.hxx:173
#35 0x00007f490d9960f6 in (anonymous namespace)::binuno_proxy_dispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) (pUnoI=0x2ca1570, pMemberType=0x2ca40e0, pReturn=0x7ffd92cd0fc0, pArgs=0x7ffd92cd09e0, ppException=0x7ffd92cd0b08) at /ssd1/lo/fedora/stoc/source/proxy_factory/proxyfac.cxx:275
#36 0x00007f492e26bbe1 in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) (pThis=0x2335350, pMemberTypeDescr=0x2ca40e0, pReturnTypeRef=0xbcfb50, nParams=0, pParams=0x0, gpreg=0x7ffd92cd0fe8, fpreg=0x7ffd92cd1010, ovrflw=0x7ffd92cd1060, pRegisterReturn=0x7ffd92cd0fc0)
    at /ssd1/lo/fedora/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:184
#37 0x00007f492e26b38b in cpp_vtable_call(sal_Int32, sal_Int32, void**, void**, void**, sal_uInt64*) (nFunctionIndex=3, nVtableOffset=0, gpreg=0x7ffd92cd0fe0, fpreg=0x7ffd92cd1010, ovrflw=0x7ffd92cd1060, pRegisterReturn=0x7ffd92cd0fc0) at /ssd1/lo/fedora/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:372
#38 0x00007f492e28e28e in privateSnippetExecutor () at /ssd1/lo/fedora/instdir/program/libgcc3_uno.so
#39 0x00007f491842a8a1 in dbaui::OApplicationController::disconnect() (this=0x23301c0) at /ssd1/lo/fedora/dbaccess/source/ui/app/AppController.cxx:311
#40 0x00007f491842aceb in dbaui::OApplicationController::disposing() (this=0x23301c0) at /ssd1/lo/fedora/dbaccess/source/ui/app/AppController.cxx:346
#41 0x00007f4953bdccce in cppu::WeakComponentImplHelperBase::dispose() (this=0x23301c0) at /ssd1/lo/fedora/cppuhelper/source/implbase.cxx:102
#42 0x00007f49185475e5 in cppu::PartialWeakComponentImplHelper<com::sun::star::frame::XDispatch, com::sun::star::frame::XDispatchProviderInterceptor, com::sun::star::util::XModifyListener, com::sun::star::frame::XFrameActionListener, com::sun::star::lang::XInitialization, com::sun::star::lang::XServiceInfo, com::sun::star::frame::XDispatchInformationProvider, com::sun::star::frame::XController2, com::sun::star::frame::XTitle, com::sun::star::frame::XTitleChangeBroadcaster, com::sun::star::awt::XUserInputInterception>::dispose() (this=0x23301c0) at /ssd1/lo/fedora/include/cppuhelper/compbase.hxx:93
#43 0x00007f491853fbb6 in dbaui::OGenericUnoController::dispose() (this=0x23301c0) at /ssd1/lo/fedora/dbaccess/source/ui/browser/genericcontroller.cxx:1302
#44 0x00007f49269f1e52 in (anonymous namespace)::Frame::setComponent(com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&, com::sun::star::uno::Reference<com::sun::star::frame::XController> const&) (
    this=0x1f36140, xComponentWindow=empty uno::Reference, xController=empty uno::Reference) at /ssd1/lo/fedora/framework/source/services/frame.cxx:1474
#45 0x00007f49269f452e in (anonymous namespace)::Frame::close(unsigned char) (this=0x1f36140, bDeliverOwnership=0 '\000') at /ssd1/lo/fedora/framework/source/services/frame.cxx:1681
#46 0x00007f49269dc085 in framework::Desktop::impl_closeFrames(bool) (this=0x1e8eb50, bAllowUI=true) at /ssd1/lo/fedora/framework/source/services/desktop.cxx:1741
#47 0x00007f49269db363 in framework::Desktop::terminate() (this=0x1e8eb50) at /ssd1/lo/fedora/framework/source/services/desktop.cxx:231
#48 0x00007f49268be07b in framework::CloseDispatcher::implts_terminateApplication() (this=0x2a536e0) at /ssd1/lo/fedora/framework/source/dispatch/closedispatcher.cxx:548
#49 0x00007f49268bd1fa in framework::CloseDispatcher::impl_asyncCallback(LinkParamNone*) (this=0x2a536e0) at /ssd1/lo/fedora/framework/source/dispatch/closedispatcher.cxx:402
#50 0x00007f49268bb928 in framework::CloseDispatcher::LinkStubimpl_asyncCallback(void*, LinkParamNone*) (instance=0x2a536e0, data=0x0) at /ssd1/lo/fedora/framework/source/dispatch/closedispatcher.cxx:247
#51 0x00007f494bf8cc28 in Link<LinkParamNone*, void>::Call(LinkParamNone*) const (this=0x2d065a8, data=0x0) at /ssd1/lo/fedora/include/tools/link.hxx:84
#52 0x00007f494c3eae38 in vcl::EventPoster::DoEvent_Impl(void*) (this=0x2d065a0) at /ssd1/lo/fedora/vcl/source/helper/evntpost.cxx:52
#53 0x00007f494c3eadf8 in vcl::EventPoster::LinkStubDoEvent_Impl(void*, void*) (instance=0x2d065a0, data=0x0) at /ssd1/lo/fedora/vcl/source/helper/evntpost.cxx:48
#54 0x00007f494bef2678 in Link<void*, void>::Call(void*) const (this=0x2abf178, data=0x0) at /ssd1/lo/fedora/include/tools/link.hxx:84


(gdb) thr 6
[Switching to thread 6 (Thread 0x7f492dca1700 (LWP 3583))]
#0  0x00007f4956ee23bd in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007f4956ee23bd in __lll_lock_wait () at /lib64/libpthread.so.0
#1  0x00007f4956edb1d8 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2  0x00007f4957945743 in osl_acquireMutex(oslMutexImpl*) (pMutex=0xb9f150) at /ssd1/lo/fedora/sal/osl/unx/mutex.cxx:97
#3  0x00007f49542eb698 in osl::Mutex::acquire() (this=0xb9f128) at /ssd1/lo/fedora/include/osl/mutex.hxx:56
#4  0x00007f495442eb87 in comphelper::GenericSolarMutex::doAcquire(unsigned int) (this=0xb9f120, nLockCount=1) at /ssd1/lo/fedora/comphelper/source/misc/solarmutex.cxx:64
#5  0x00007f4919179ff8 in comphelper::SolarMutex::acquire(unsigned int) (this=0xb9f120, nLockCount=1) at /ssd1/lo/fedora/include/comphelper/solarmutex.hxx:72
#6  0x00007f4919179f9a in osl::ClearableGuard<comphelper::SolarMutex>::ClearableGuard(comphelper::SolarMutex&) (this=0x7f492dca01e0, t=...) at /ssd1/lo/fedora/include/osl/mutex.hxx:163
#7  0x00007f4919179f57 in osl::ResettableGuard<comphelper::SolarMutex>::ResettableGuard(comphelper::SolarMutex&) (this=0x7f492dca01e0, rT=...) at /ssd1/lo/fedora/include/osl/mutex.hxx:208
#8  0x00007f4919179dc5 in SolarMutexResettableGuard::SolarMutexResettableGuard() (this=0x7f492dca01e0) at /ssd1/lo/fedora/include/vcl/svapp.hxx:1412
#9  0x00007f4919179c10 in dbaccess::ModelMethodGuard::ModelMethodGuard(dbaccess::ModelDependentComponent const&) (this=0x7f492dca01e0, _component=...) at /ssd1/lo/fedora/dbaccess/source/core/inc/ModelImpl.hxx:545
#10 0x00007f49191718da in dbaccess::DocumentGuard::DocumentGuard(dbaccess::ODatabaseDocument const&, dbaccess::DocumentGuard::MethodWithoutInit_) (this=0x7f492dca01e0, _document=...)
    at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/databasedocument.hxx:713
#11 0x00007f491916280d in dbaccess::ODatabaseDocument::getLocation() (this=0x218a090) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/databasedocument.cxx:945
#12 0x00007f49191628c0 in non-virtual thunk to dbaccess::ODatabaseDocument::getLocation() () at /ssd1/lo/fedora/include/cppu/unotype.hxx:296
#13 0x00007f49269c84ca in (anonymous namespace)::AutoRecovery::implts_markDocumentAsSaved(com::sun::star::uno::Reference<com::sun::star::frame::XModel> const&) (this=0x1f4c7e0, xDocument=uno::Reference to (dbaccess::ODatabaseDocument *) 0x218a0f8) at /ssd1/lo/fedora/framework/source/services/autorecovery.cxx:2631
#14 0x00007f49269b101a in (anonymous namespace)::AutoRecovery::documentEventOccured(com::sun::star::document::DocumentEvent const&) (this=0x1f4c7e0, aEvent=...)
    at /ssd1/lo/fedora/framework/source/services/autorecovery.cxx:1568
#15 0x00007f49269d6d9c in framework::WeakDocumentEventListener::documentEventOccured(com::sun::star::document::DocumentEvent const&) (this=0x1ef1910, rEvent=...) at /ssd1/lo/fedora/framework/inc/helper/mischelper.hxx:242
#16 0x00007f4951db1dbe in comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>::operator()(com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> const&) const (this=0x7f492dca06c0, listener=uno::Reference to (framework::WeakDocumentEventListener *) 0x1ef1938)
    at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:272
#17 0x00007f4951db1bd2 in comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener, comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent> >(comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent> const&) (this=0x1fc2370, func=...) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:285
#18 0x00007f4951db1867 in comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>(void (com::sun::star::document::XDocumentEventListener::*)(com::sun::star::document::DocumentEvent const&), com::sun::star::document::DocumentEvent const&) (this=0x1fc2370, NotificationMethod=
    &virtual com::sun::star::document::XDocumentEventListener::documentEventOccured(com::sun::star::document::DocumentEvent const&), Event=...) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:298
#19 0x00007f4951dafe47 in (anonymous namespace)::SfxGlobalEvents_Impl::implts_notifyListener(com::sun::star::document::DocumentEvent const&) (this=0x1fc22e0, aEvent=...)
    at /ssd1/lo/fedora/sfx2/source/notify/globalevents.cxx:395
#20 0x00007f4951dae26d in (anonymous namespace)::SfxGlobalEvents_Impl::documentEventOccured(com::sun::star::document::DocumentEvent const&) (this=0x1fc22e0, Event=...)
    at /ssd1/lo/fedora/sfx2/source/notify/globalevents.cxx:211
#21 0x00007f49191e81fe in comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>::operator()(com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> const&) const (this=0x7f492dca08f0, listener=uno::Reference to ((anonymous namespace)::SfxGlobalEvents_Impl *) 0x1fc2330)
    at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:272
#22 0x00007f49191e7fd2 in comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener, comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent> >(comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent> const&) (this=0x22f14b0, func=...) at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:285
#23 0x00007f49191e70b7 in comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>(void (com::sun::star::document::XDocumentEventListener::*)(com::sun::star::document::DocumentEvent const&), com::sun::star::document::DocumentEvent const&) (this=0x22f14b0, NotificationMethod=&virtual table offset 32, Event=...)
    at /ssd1/lo/fedora/include/comphelper/interfacecontainer2.hxx:298
#24 0x00007f49191e66ce in dbaccess::DocumentEventNotifier_Impl::impl_notifyEvent_nothrow(com::sun::star::document::DocumentEvent const&) (this=0x22f1460, _rEvent=...)
    at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/documenteventnotifier.cxx:196
#25 0x00007f49191e6a3f in dbaccess::DocumentEventNotifier_Impl::processEvent(comphelper::AnyEvent const&) (this=0x22f1460, _rEvent=...) at /ssd1/lo/fedora/dbaccess/source/core/dataaccess/documenteventnotifier.cxx:229
#26 0x00007f495438e4ac in comphelper::AsyncEventNotifierBase::execute() (this=0x24c40c0) at /ssd1/lo/fedora/comphelper/source/misc/asyncnotification.cxx:158
#27 0x00007f495438f1a7 in comphelper::AsyncEventNotifierAutoJoin::run() (this=0x24c40c0) at /ssd1/lo/fedora/comphelper/source/misc/asyncnotification.cxx:258
#28 0x00007f495439516e in threadFunc(void*) (param=0x24c40d0) at /ssd1/lo/fedora/include/osl/thread.hxx:185
#29 0x00007f495795ddca in osl_thread_start_Impl(void*) (pData=0x24d6580) at /ssd1/lo/fedora/sal/osl/unx/thread.cxx:234
#30 0x00007f4956ed8619 in start_thread () at /lib64/libpthread.so.0
#31 0x00007f49572078bf in clone () at /lib64/libc.so.6
Comment 40 Tor Lillqvist 2018-01-02 12:34:49 UTC
Tentative fix in https://gerrit.libreoffice.org/#/c/47249/
Comment 41 Tor Lillqvist 2018-01-02 13:44:34 UTC
Explanation to the backtraces in Comment #39: 

Thread 1 is attempting to lock the oslMutexImpl at 0x2ad7eb0. It has already locked the SolarMutex at slot #16, in DocumentStorageModifyListener::modified().

Thread 6 is attempting to lock the SolarMutex. It has already locked the same mutex that thread 1 is attempting to lock when creating the AutoRecovery object being used around slot #14.

Thus the suggested patch makes sure we lock the SolarMutex first, in the code at slot #14.
Comment 42 Commit Notification 2018-01-03 16:38:39 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=de84816c1acefe0607827418f73477ff7163728d

tdf#107039: Avoid deadlock by locking the SolarMutex early on in one place

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 43 Matt 2018-01-05 20:26:17 UTC
Unfortunately...it still hangs on Windows 7.

This is today's current build:
Version: 6.0.0.1.0+ (x64)
Build ID: c678dc5309741097d9b0265f03dd279a8794d256
CPU threads: 8; OS: Windows 6.1; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:libreoffice-6-0, Time: 2017-12-28_05:32:34
Locale: en-US (en_US); Calc: CL

Still repeated writes to databasename.odb.lck
Any possibility that Dropbox could be messing with you? I mean, since the lock file resides in a Dropbox'd folder?

Here is a few lines from ProcMon. Any significance to the changing Offsets in these writes?

3:22:54.5235543 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 8, Length: 1, Priority: Normal
3:22:54.5237011 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 9, Length: 1, Priority: Normal
3:22:54.5238180 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 10, Length: 1, Priority: Normal
3:22:54.5239221 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 11, Length: 1, Priority: Normal
3:22:54.5240464 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 12, Length: 1, Priority: Normal
3:22:54.5241795 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 13, Length: 1, Priority: Normal
3:22:54.5242511 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 14, Length: 1, Priority: Normal
3:22:54.5243189 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 15, Length: 1, Priority: Normal
3:23:03.5656477 PM	soffice.bin	8916	Thread Exit		SUCCESS	Thread ID: 7560, User Time: 0.0000000, Kernel Time: 0.0000000

...

3:24:34.5217365 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 8, Length: 1, Priority: Normal
3:24:34.5218665 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 9, Length: 1, Priority: Normal
3:24:34.5219666 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 10, Length: 1, Priority: Normal
3:24:34.5220624 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 11, Length: 1, Priority: Normal
3:24:34.5221542 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 12, Length: 1, Priority: Normal
3:24:34.5222460 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 13, Length: 1, Priority: Normal
3:24:34.5223384 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 14, Length: 1, Priority: Normal
3:24:34.5224310 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 15, Length: 1, Priority: Normal
3:24:44.5217824 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 8, Length: 1, Priority: Normal
3:24:44.5219007 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 9, Length: 1, Priority: Normal
3:24:44.5219868 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 10, Length: 1, Priority: Normal
3:24:44.5220709 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 11, Length: 1, Priority: Normal
3:24:44.5221533 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 12, Length: 1, Priority: Normal
3:24:44.5222352 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 13, Length: 1, Priority: Normal
3:24:44.5223164 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 14, Length: 1, Priority: Normal
3:24:44.5223977 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 15, Length: 1, Priority: Normal
3:24:54.5214694 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 8, Length: 1, Priority: Normal
3:24:54.5216011 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 9, Length: 1, Priority: Normal
3:24:54.5217032 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 10, Length: 1, Priority: Normal
3:24:54.5218010 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 11, Length: 1, Priority: Normal
3:24:54.5218942 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 12, Length: 1, Priority: Normal
3:24:54.5219871 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 13, Length: 1, Priority: Normal
3:24:54.5220795 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 14, Length: 1, Priority: Normal
3:24:54.5221747 PM	soffice.bin	8916	WriteFile	D:\Users\postiffm\Dropbox\Documents\Garage\New Database.odb.lck	SUCCESS	Offset: 15, Length: 1, Priority: Normal
Comment 44 Tor Lillqvist 2018-01-06 09:12:22 UTC
The deadlock fix has nothing to do with a problem that would manifest itself as "repeated writes to databasename.odb.lck". That must be a completely separate bug. Please file a new bug report.
Comment 45 Matt 2018-01-06 17:22:50 UTC
I'm sorry that I confused the issue by supplying the log from ProcMon. 

Bottom line: I followed the same steps as in Comment 34 and get the exact same behavior, so I believe this is still the same bug. I have not tried on Linux with the daily build, but I will endeavor to do that and report back here.

Back story: when I originally filed the bug, I tried to observe what was going on behind the scenes. As I described in Comment 17, while soffice was hung, there were repeated writes to the database .lck file during the hang. Since I observe the same behavior now as I did back then (in June 2017), I have a strong suspicion that it is the same bug.
Comment 46 Matt 2018-01-06 18:57:41 UTC
Tested on 
Version: 6.0.0.1.0+
Build ID: 54801ad8e88ea3dafeb4442b9b926404a8caf336
CPU threads: 2; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-0, Time: 2018-01-05_10:04:50
Locale: en-CA (en_CA.UTF-8); Calc: group

and the hanging bug remains.
Comment 47 Tor Lillqvist 2018-01-07 22:15:16 UTC
Well, the patch has been committed to the master branch only, not the 6.0 branch. As comment #42 says.
Comment 48 Matt 2018-01-07 22:27:53 UTC
Sorry, my bad. I am obviously unfamiliar with how to access the master branch...I thought the patch would be in the daily builds after a day or two, so I used what was available at http://dev-builds.libreoffice.org/daily/

How can I test the master branch if I don't have the environment set up to compile from source?
Comment 49 Lionel Elie Mamane 2018-01-08 06:37:02 UTC
(In reply to Matt from comment #48)
> Sorry, my bad. I am obviously unfamiliar with how to access the master
> branch...I thought the patch would be in the daily builds after a day or
> two, so I used what was available at http://dev-builds.libreoffice.org/daily/

It is, in http://dev-builds.libreoffice.org/daily/master/ but not in http://dev-builds.libreoffice.org/daily/libreoffice-6-0/

http://dev-builds.libreoffice.org/daily/master/ is the master branch and http://dev-builds.libreoffice.org/daily/libreoffice-6-0/ is the libreoffice-6-0 branch (which will become LibreOffice 6.0).

Do check the build date/time, to see it is later than the patch application.
The directory timestamp gives you a first approximate clue, but there can be a 1h difference or so: it gives the time of *end* of build, while the code built is the one at the *beginning* of the build "obviously".

There is a *build_info.txt file that gives the exact git commit id built, and "pull time". The git commit id should be the latest (in that branch) as of that "pull time".
Comment 50 Xisco Faulí 2018-01-08 10:28:29 UTC
Verified in

Version: 6.1.0.0.alpha0+
Build ID: 0ef0740298b45379bbf8d00d50beffee7a2f812a
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

as Lionel suggested, you should try with a master build from http://dev-builds.libreoffice.org/daily/master/

@Tor, should it be backported to 6.0 and 5.4 ?
Comment 51 Tor Lillqvist 2018-01-08 11:23:26 UTC
If we are reasonably sure that it doesn't cause any new problems, then sure, should be back-ported.
Comment 52 Matt 2018-01-08 12:41:40 UTC
Bug is fixed in /daily/master/Win-x86_64@42/current/libo-master64~2018-01-08_01.06.29_LibreOfficeDev_6.1.0.0.alpha0_Win_x64.msi

Version: 6.1.0.0.alpha0+ (x64)
Build ID: dbf83d315acc454b576355f2e5bd8412586827ac
CPU threads: 8; OS: Windows 6.1; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-08_01:06:29
Locale: en-US (en_US); Calc: CL
Comment 53 Commit Notification 2018-01-10 10:44:01 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d5d2c5666cd95070f17614219c3fabe9f20a370&h=libreoffice-6-0

tdf#107039: Avoid deadlock by locking the SolarMutex early on in one place

It will be available in 6.0.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 54 Buovjaga 2018-01-14 06:30:00 UTC
*** Bug 113915 has been marked as a duplicate of this bug. ***
Comment 55 Xisco Faulí 2018-02-14 09:40:23 UTC
A polite ping to Tor Lillqvist: is this bug fixed? if so, could you
please close it as RESOLVED FIXED ? Thanks
Comment 56 Tor Lillqvist 2018-02-14 09:51:08 UTC
You verified it yourself in comment #50 ;)
Comment 57 Xisco Faulí 2018-02-14 10:03:26 UTC
(In reply to Tor Lillqvist from comment #56)
> You verified it yourself in comment #50 ;)

True ;) Thanks for closing it!