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
Created attachment 132409 [details] Database file that causes Base to hang.
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.
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
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
regression
mutex release/continue problem, judging by Apple stack trace
Created attachment 132439 [details] Apple stack / backtrace
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
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
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
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 ?
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.
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.
Tested on 5.3.3.2 (x64), reproduced the same bug.
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.
Created attachment 134149 [details] Relevant procmon output
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.
Hi Matt, Thanks for testing it again. Maybe I did something wrong when I tested it. Could someone reproduce it on Linux ?
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.
I am having this same problem on windows 10 with version 5.4.1.2 (x64). Using a database connection type: PostgreSQL.
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
(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)
(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
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...
The issue is not reproducible in the bisect repositories...
Adding Jan-Marek just in case he might have any idea about it...
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
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.
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.
(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.
*** Bug 114032 has been marked as a duplicate of this bug. ***
*** Bug 105062 has been marked as a duplicate of this bug. ***
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>?)
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.
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
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.
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
Thanks, Matt. Indeed, hangs for me, too. (Also on Linux, built from master branch.)
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
Tentative fix in https://gerrit.libreoffice.org/#/c/47249/
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.
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.
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
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.
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.
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.
Well, the patch has been committed to the master branch only, not the 6.0 branch. As comment #42 says.
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?
(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".
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 ?
If we are reasonably sure that it doesn't cause any new problems, then sure, should be back-ported.
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
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.
*** Bug 113915 has been marked as a duplicate of this bug. ***
A polite ping to Tor Lillqvist: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
You verified it yourself in comment #50 ;)
(In reply to Tor Lillqvist from comment #56) > You verified it yourself in comment #50 ;) True ;) Thanks for closing it!
https://www.jualtasmurahbbs.com/ toko tas murah kampus maupun di sekolah belum pas kalo belum pakai tas ransel berkualitas dari kami jual tas export di jakarta harga tas terbaru dengan harga murah belanja jual tas export di jakarta tas https://www.jualtasmurahbbs.com/category/tas-sekolah-anak/ jual tas anak wanita ceviro handbag ceviro handbag terbaru backpack wanita handbag wanita tas rangsel wanita posted on june by ikawulan posted indonesia tas model ransel tas ukuran sedang tagged backpack https://www.jualtasmurahbbs.com/category/kipling/ tas selempang kipling aneka tas anak sekolah gambar tas grosir tas murah tas lokal berkualitas cantik wanita cantik tas toko tas dan free gantungan monyet jual tas laptop murah grosir tas laptop tas laptop jual tas ransel https://www.jualtasmurahbbs.com/category/tas-ransel-wanita/ jual tas ransel wanita bags berkualitas beragam pilihan model model tas terbaru beragam pilihan model model tas terbaru olshop belanja tas wanita tote bags tas tote bags wanita murah berkualitas terbaru tas merupakan https://www.jualtasmurahbbs.com/category/tote-bag/ tote bag murah bandung murah travel bag anak travel bag kanvas tas traveling wanita tas travelling wanita tas traveller jual tas traveller tas untuk traveller harga tas traveller handbag traveller travel bag murah berkualitas https://www.jualtasmurahbbs.com/category/cath-kidston/ cath kidston murah digunakan untuk berpegian jauh serta lama atau bila anda grossir goodie bag murah di palembang tas kain spundbond grossirtasblacupalembang belanja grossir goodie bag murah di palembang tas https://www.jualtasmurahbbs.com/category/anello/ toko online tas anello murah murah belanja blog toko online yang menjual grosir tas murah dengan merk branded batamtas keren dengan model tas terbaru di galeri kami tote bag jenis tote bag adalah tas bentuknya besar https://www.jualtasmurahbbs.com/category/jansport/ jual tas jansport di bandung pelanggan tote bag dog jakarta toko grosir tas tokogrosir online tas produk tote bag dog jakarta toko grosir tas toko grosir tas jual tas murah kualitas import home my account sample harga reviews