In my master debug build LO530 alpha on OSX 10.11.6, I can not save a form in which I have added a control from the control toolbar. When I attempt to save the form, LO hangs, requiring a forced kill. Steps to reproduce: 1) Open a database file 2) Create a new blank form 3) Select a control from the control toolbar with the mouse, and then draw a rectangle on the form to insert the control. 4) Now try and save the form by clicking on the Save icon in the main toolbar (Cmd-S). 5) The Save dialog window is displayed. Both the "Help" and "Save" buttons are highlighted. 6) Click on the "Save" button. 7) The dialog does not disappear, and LO hangs (spinning beachball mode).
lldb output seems to suggest that a thread gets stuck waiting for a mutex sync operation (something is not releasing the mutex) ? We seem to be beset by these mutex release/locking problems.
Created attachment 127061 [details] backtrace from lldb debugging session
Tested against production release : Version: 5.2.0.4 Build ID: 066b007f5ebcc236395c7d282ba488bca6720265 Threads CPU : 2; Version de l'OS :Mac OS X 10.11.6; UI Render : par défaut; Locale : fr-FR (fr.UTF-8) No repro. So either a recent regression in master, or else the problem only shows in debug builds.
Tested against : Version: 5.3.0.0.alpha0+ Build ID: d7ce684cae03e97b23f916a90db55e49f17a1601 Threads CPU : 4; Version de l'OS :Linux 4.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group on LinuxMint 18 and reproducible. In this build, the Save dialog disappears, but then the Form design window becomes unresponsive, and the mouse cursor displays as crosshairs as if one could draw a new control, but in fact it is impossible to click anywhere in the window other than on the window border "Close" icon. If one attempts to close the window in this way, the system returns a message that the app is unresponsive and offers to kill it.
Created attachment 127067 [details] bt with symbols On pc Debian x86-64 with master sources updated yesterday, I could reproduce the crash. I noticed that if you waited (about a minute) once the form was created or perhaps once the rectangle was created, it didn't crash.
huh, was sure I could reproduce this, reverted... commit 403eefe81b8a0afe888c60452c17d6b2c5d8343f Author: Michael Stahl <mstahl@redhat.com> Date: Wed Jul 27 15:02:52 2016 +0200 tdf#101136 dbaccess: use SolarMutex in ModelMethodGuard and it worked, but then when I restored that it still worked. Still suspicious I guess, but not certain now.
Adding keyword 'bibisectRequest'.
Created attachment 127297 [details] bibisect output Heh. I was just saving this until I had internet access again. Working in the Win32-5.3 bibisect repository on Windows Vista (details in attachment), I have determined: commit s-h committed ------- ------- --------------------- good f76ed2d 4acac00 2016-08-03 11:26:42 Z bad 8a5bc37 403eefe 2016-08-03 11:27:44 Z so I am setting keyword bisected. Funny workaround: command line parameter --norestore, at least in the dbgutil repository versions.
I have also provoked a similar hang of the main database window when saving the file during File > Close. I am assuming it is the same bug because bibisect points to the same commit. Please excuse the length of this comment: I wrote thinking it would be a new bug report. STR --- (1) From Start Center, create database with embedded Firebird. (2) In database window, take menu options Tools > SQL... . Program presents window "Execute SQL Statement". (3) In control "Command to execute", enter create table t1 ( id integer not null, field1 varchar(20) not null ); and click button <Execute>. Control Status shows "1: Command successfully executed.". (4) Click button <Close>. Program closes window "Execute SQL Statement" and return focus to the database window. (5) Take menu options File > Close. Program presents prompt "Save Document?". (6) Click button <Save>. Expected : program closes database window and displays Start Center. Observed : After about 10 seconds, the window title changes to "... - LibreOfficeDev Base (Not Responding)" and the cursor changes to the dreaded circling blue whatever-it-is. It is necessary to cancel the program, e.g., with <Alt>+F4. Some odd points, mostly from the daily build noted below ... (*) With an existing .odb, there is no hang. (*) With embedded HSQLDB, the hang occurs in step (5) before the program prompts to save the document. (*) If at the prompt in step (6) I decline to save the file, there is no hang. (*) If I save the the .odb explictly after step (4), there is no hang. (*) If instead of steps (2) through (4), I create a table in Table Design view and save the definition first, the program hangs closing the Table Design window. (*) Given command line parameter --norestore, dbgutil version from 2016-08-23, at least, does not hang. These observations are from Windows Vista; LibreOffice versions are daily build Version: 5.3.0.0.alpha0+ Build ID: ce95e39f8e952159844e9dc04a1df402bb103634 CPU Threads: 2; OS Version: Windows 6.0; UI Render: default; Locale: en-CA (en_CA); Calc: group and some versions from the Win32-5.3 bibisect repository. Working in the Win32-5.3 bibisect repository, I have determined: commit s-h committed ------- ------- --------------------- good f76ed2d 4acac00 2016-08-03 11:26:42 Z bad 8a5bc37 403eefe 2016-08-03 11:27:44 Z
Just an aside ... Not remembering why O/S=All in this report, I tried to reproduce the problem on windows. All I got was another example of tdf#101771 "FORM creation - hang/crash - impossible to save a control created from control toolbar".
With pc Debian x86-64 with master sources updated 2 days ago (ba269f7294e2416659011cbb498a2c6b5f9d5199), I don't reproduce the crash but it hangs.
the commit in comment #6 was a huge change in Base threading, it is quite likely that it causes some deadlocks somewhere... on Linux, can't reproduce the deadlock in comment #2 but i think i fixed it the assertion in comment #5 probably indicates that there's a stale iterator contained in m_aDocuments; probably that's an unrelated problem? it's not clear to me how this could happen from looking at the ODefinitionContainer... on Linux, can't reproduce the deadlock in comment #9 with the first fix applied, it's quite likely that it's the same deadlock, given that --norestore is a work-around and it was in AutoRecovery please continue testing master Base for deadlocks
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=437377bbda0ac6b0be3c4f6fac59a4c782eecef8 tdf#101771 framework: avoid deadlock in AutoRecovery It will be available in 5.3.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.
lets set this to fixed cause we think it is
I see that the reported bug is fixed between daily Linux dbgutil bibisect repository versions 2016-09-15 and 2016-09-16. Alex, can you verify that it is fixed for you? The problem I mentioned in comment 09 persists. I shall file a new bug report for it.
I am abandoning my intention to file a new bug report, as I am unable to get consistently reproducible results. Sigh!