Bug Hunting Session
Bug 113160 - CRASH: When closing the document before handling the warning about pasting data into cells that already contain data
Summary: CRASH: When closing the document before handling the warning about pasting da...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: highest critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.0.0
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: Dialog-Msgbox
  Show dependency treegraph
 
Reported: 2017-10-16 19:59 UTC by Telesto
Modified: 2017-11-23 14:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (13.24 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-16 19:59 UTC, Telesto
Details
bt with debug symbols (8.49 KB, text/plain)
2017-10-16 20:27 UTC, Julien Nabet
Details
Screencast (931.88 KB, video/mp4)
2017-11-02 18:43 UTC, Telesto
Details
File that produces a dialog on opening and cannot be repaired (2.02 KB, application/vnd.oasis.opendocument.text)
2017-11-21 11:43 UTC, Armin Le Grand
Details
A GereralError dialog (3.95 KB, image/png)
2017-11-21 11:49 UTC, Armin Le Grand
Details
SolarMutex added (1.11 KB, patch)
2017-11-22 12:56 UTC, Armin Le Grand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-10-16 19:59:09 UTC
Description:
CRASH: When closing the document before handling the warning about pasting data into cells that already contain data (not quite likely to happen, I suppose)




Steps to Reproduce:
1. Open the attached file
2. Copy for example the cell content of A5-C26
3. Select cell E5 and paste
4. Ignore the warning; close the document; dont'save
5. Now press Yes/NO in the Warning dialog -> CRASH

Actual Results:  
Crash

Expected Results:
No Crash


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 6.0.0.0.alpha0+
Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25
Locale: en-US (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Telesto 2017-10-16 19:59:39 UTC
Created attachment 137019 [details]
Example file
Comment 2 Julien Nabet 2017-10-16 20:22:01 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

Eike: shouldn't the warning message popup be modal so we shouldn't be able to close the document before having responded?
Comment 3 Julien Nabet 2017-10-16 20:27:07 UTC
Created attachment 137020 [details]
bt with debug symbols
Comment 4 Xisco Faulí 2017-10-19 20:15:49 UTC
Regression introduced by:

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2017-08-24 16:32:38 (GMT)
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2017-08-25 09:31:42 (GMT)
commit	db6b703d391838c481fd090065f6d329edcd4efa (patch)
tree	c17b58ca1f9e0f0beaa3b1b5c89d0e85bdaedaf7
parent	69cfafef7a28aad7a013bb440e15e23e59ea628c (diff)
Allow non-modal Dialogs during FileImport/Load
When opening a file that triggers Dialogs (e.g. cannot
read/repair/FileType) the Frame from which it was
initialized gets blocked. This irritates quite some
people. Changed this to a non-modal Dialog so that
the user can continue to work with all opened docs,
open new ones, close and print/PDF/export these.

Bisected with: bibisect-linux64-6.0

Adding Cc: to Armin Le Grand
Comment 5 Caolán McNamara 2017-11-02 17:10:56 UTC
Not sure what the original problem was, but it may have been that the problem to be solved was to ensure that the parents of message dialogs were explicitly set to the window they should block (instead of null to select a default parent) rather than making dialogs non-modal
Comment 6 Telesto 2017-11-02 18:43:15 UTC
Created attachment 137480 [details]
Screencast

(In reply to Caolán McNamara from comment #5)
> Not sure what the original problem was, but it may have been that the
> problem to be solved was to ensure that the parents of message dialogs were
> explicitly set to the window they should block (instead of null to select a
> default parent) rather than making dialogs non-modal

Still a repro... Attached a screencast to make things clear..
Comment 7 Caolán McNamara 2017-11-03 09:11:35 UTC
caolanm->telesto: sorry, I meant the problem that the commit that made these dialogs non-modal wanted to fix, I was speculating that the wrong parent might have been autodetected and another solution might be to set an explicit parent.
Comment 8 Caolán McNamara 2017-11-03 15:37:24 UTC
have a solution here that seems to work
Comment 9 Commit Notification 2017-11-03 21:07:04 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#113160 changing all warning dialogs to non-modal is unsafe

It will be available in 6.0.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 10 Commit Notification 2017-11-04 19:27:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#113160 set parent of warning dialogs during load

It will be available in 6.0.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 11 Xisco Faulí 2017-11-08 08:04:21 UTC
Verified in

Version: 6.0.0.0.alpha1+
Build ID: 5e0022c90c4125a1590b3688dfec73c271b7aedd
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 12 Armin Le Grand 2017-11-21 09:45:26 UTC
@Caolán: Thanks for taking care so far. The initial problem happens when opening a doc that immediately triggers a dialog at load time. There *is* no window at load time, so this blocks the whole office with a single modal dialog.
I thought about 'forcing' the office to open a win and view for the doc in loading state, but could not find a way to do so.
Since of course the initial problem is back, do you have suggestions...?
Comment 13 Caolán McNamara 2017-11-21 09:52:04 UTC
Can you give me a sample document for that. Perhaps we can force explicit parents for the specific dialog(s) and explicitly force disable-pick-auto-parent for it/them
Comment 14 Armin Le Grand 2017-11-21 11:43:26 UTC
Created attachment 137889 [details]
File that produces a dialog on opening and cannot be repaired

Took a while - had to create an own file due to the orig being from customer. It triggers the same dialog now when trying to open.
So:
- Try to open
- when dialog is open, it's not possible to work with office anymore
- try repair -> new dialog
- same state: not possible to work with office
Customer wants to be able to continue work on open docs, esp. save them or similar. Possible for all except the one where you started to open the new doc. That one is blocked (of course), but from user's view this is not logical (in contrary to us who know what happens and why it's blocked).
BG seems to be that some users (sigh) 'forget' that (non-huge) dialog or move it to some place where they see it no longer.
Comment 15 Armin Le Grand 2017-11-21 11:49:06 UTC
Created attachment 137891 [details]
A GereralError dialog

By pure coincidence I just produced the attached dialog. That one did not block any of the three open docs, I could close them all and office still running with only that dialog remaining.
Do not know how to reproduce. Problem is that after closing that dialog the office does not terminate, keeps running as task.
Comment 16 Armin Le Grand 2017-11-21 11:50:13 UTC
That is more or less what I wanted to achieve with the original change, plus the working office termination, of course.
HTH, please ask questions if needed!
Comment 17 Caolán McNamara 2017-11-21 16:33:35 UTC
The dialog appears from the type detection, and the toplevel frame for the document is created later before loading the document so that's why my earlier changes didn't affect this dialog to make the new document window the parent. Though it does work for errors during the load of the document, just not for errors during the preload type detection.

What we could try is a temporary unshown toplevel window to use as parent during typedection, that results in modal dialogs that are modal to a unused window so they appear visible and don't block the other visible window and the dialog parent window can listen to terminate to close itself and destroy its children automatically. https://gerrit.libreoffice.org/#/c/45044/
Comment 18 Armin Le Grand 2017-11-22 08:36:52 UTC
Caolan, thanks, I will take a look, get the patch and experiment with it...
Comment 19 Armin Le Grand 2017-11-22 12:56:56 UTC
Created attachment 137916 [details]
SolarMutex added

Have added the possible patch tat adds the SolarMutex. Not sure how to add this to logerrit, though. This makes the test 'CppunitTest_dbaccess_empty_stdlib_save'work.
On Win, I got an error now with CppunitTest_dbaccess_nolib_save, so not sure how to proceed.
I have added quite some comments to logerrit, see https://gerrit.libreoffice.org/#/c/45044/1
Comment 20 Armin Le Grand 2017-11-22 13:41:29 UTC
Crash for dbaccess_nolib_save inits from DialogSaveTest::test() line 87, xBasLib->loadLibrary(sStandard); with sStandard->"Standard". It calls SfxLibraryContainer::loadLibrary, there maNameContainer *has* no entries which leads to an exception
Comment 21 Armin Le Grand 2017-11-22 14:11:42 UTC
Strange - that last one worked now, but got a problem in CppunitTest_sw_ooxmlexport7, trying again - may be instable..?
Comment 22 Commit Notification 2017-11-23 14:14:22 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#113160 set a temporary dialog parent during type detection

It will be available in 6.0.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.