Bug 108991 - Bad allocation or crash on cut text in attached ODT (with Non-Printing Characters hidden) (LibreOffice not maximized?)
Summary: Bad allocation or crash on cut text in attached ODT (with Non-Printing Charac...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2 all versions
Hardware: All All
: high critical
Assignee: Michael Stahl
QA Contact:
URL:
Whiteboard: target:6.0.0, backportRequest target:...
Keywords: haveBacktrace, regression
Depends on:
Blocks: Assert
  Show dependency treegraph
 
Reported: 2017-07-06 14:51 UTC by Timur
Modified: 2017-08-02 08:18 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Test ODT for select text (13.01 KB, text/odt)
2017-07-06 14:51 UTC, Timur
Details
Cut text - Bad allocation in 5.2.7 with WinDBG (3.70 KB, text/plain)
2017-07-06 14:52 UTC, Timur
Details
Cut text - Assertion failed in 6.0+ with WinDBG (12.16 KB, text/plain)
2017-07-06 14:53 UTC, Timur
Details
Test ODT for cut text (13.44 KB, text/odt)
2017-07-06 15:14 UTC, Timur
Details
gdb backtrace (33.67 KB, text/plain)
2017-07-11 12:50 UTC, Xisco Faulí
Details
Crash Report in Linux Ubuntu (28.56 KB, image/png)
2017-07-19 11:22 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2017-07-06 14:51:49 UTC
Created attachment 134517 [details]
Test ODT for select text

I was using LO 5.2.7 in Windows 7 to edit 46-pages ODT. On cut text I got "Bad allocation" and LO crashed. Reproducible also with master~2017-06-28_00.51.05_LibreOfficeDev_6.0.0.0.alpha0_Win_x86. Both WinDBG attached after. 
Didn't reproduce with 5.0.4, got "Stack overflow" with 5.0.6 and "Bad allocation" with 5.1. So I set version to 5.1.

Since original document is both private and long, I tried to create a minimal test case (Test ODT for cut text) that I don't attach so far. 
While doing so, I noticed another problem, only with master: "Assertion failed" just on select text in another test case attached here (Test ODT for select text), like this: 
- put cursor at the beginning of marked row, press shift and then right arrow.
Assertion failed - crash on Retry.
Comment 1 Timur 2017-07-06 14:52:42 UTC
Created attachment 134518 [details]
Cut text  - Bad allocation in 5.2.7 with WinDBG
Comment 2 Timur 2017-07-06 14:53:11 UTC
Created attachment 134519 [details]
Cut text  - Assertion failed in 6.0+ with WinDBG
Comment 3 Timur 2017-07-06 15:14:39 UTC
Created attachment 134520 [details]
Test ODT for cut text

Test case ODT for select and cut text. Reproducible on 5.2.7 and 5.4.0. Master 6.0+ has another issue with select text. I select with keyboard, shift+arrow. 
Document has some recorded changes, crash is not dependent on Show/Record on/off.
Comment 4 Timur 2017-07-11 10:26:26 UTC
"Assertion failed" from Comment 0 that was repro with master~2017-06-28_00.51.05_LibreOfficeDev_6.0.0.0.alpha0_Win_x86, no repro with libo-master~2017-07-11_04.22.25_LibreOfficeDev_6.0.0.0.alpha0_Win_x86.

What remains is crash on cut from Comment 3. 
I select with keyboard, shift+arrow. I noticed if I select just till the end of "SELECT TILL THE END OF THIS TEXT AND CUT" I may not have crash, but if I select more and then select back till the end of that text, I still get the crash.
Comment 5 Xisco Faulí 2017-07-11 12:01:07 UTC
I can confirm it in

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

using the following steps:
1. Download attachment 134520 [details]
2. Using the mouse select from the second line until the end of 'SELECT TILL THE END OF THIS TEXT AND CUT'
3. Use shift + down keys
4. Use shift + up keys
5. Ctrl + X
6. CRASH
Comment 6 Xisco Faulí 2017-07-11 12:35:16 UTC
I can reproduce it back to

Version: 4.2.0.0.alpha0+
Build ID: 6e2ff4edb2aae441142280ef31286f4627347fb

using the lo-linux-dbgutil-daily-till repos. however, I can't reproduce it using the bibisect-XXmax repos
Comment 7 Xisco Faulí 2017-07-11 12:50:10 UTC
Created attachment 134588 [details]
gdb backtrace
Comment 8 Timur 2017-07-12 10:11:39 UTC
(In reply to Xisco Faulí from comment #6)
> I can reproduce it back to
> Version: 4.2.0.0.alpha0+
I guess you mean Linux. 
Don't know why I cant repro with 4.2 in Windows. I repro with 4.3.0 and on. Sometimes, looks in older version, if there's no crash, undo cut and again the same procedure gives crash.
The reason I didn't repro with 5.0.4 previously is because I had Non-Printing Characters on. They should be hidden to reproduce. Same for master.
Comment 9 Xisco Faulí 2017-07-12 12:49:05 UTC
it seems the behaviour is different on Windows and on Linux:

I can reproduce the crash in

Versión: 4.4.0.3
Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Configuración regional: es_ES

while I can't in

Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: ca_ES

but I can in

Version: 4.2.0.0.alpha0+
Build ID: 6e2ff4edb2aae441142280ef31286f4627347fb

which is a debug build...
Comment 10 Xisco Faulí 2017-07-12 12:57:26 UTC
I've also reported bug 109081, which might be related
Comment 11 Xisco Faulí 2017-07-12 13:04:49 UTC
Bisecting it with bibisect-releases it started crashing at 5.1.0.1 for non-debug builds on linux.
I guess the behaviour is different among Window, Linux and debug/non-debug builds...
Comment 12 Xisco Faulí 2017-07-12 13:32:41 UTC
Anyway, this is definitely a regression
Comment 13 Xisco Faulí 2017-07-14 16:32:00 UTC
In my case, I can only reproduce the crash when LibreOffice is not maximized, otherwise it's not reproduced.
@Timur: Can you reproduce it when LibreOffice is maximized?
Comment 14 Timur 2017-07-18 09:14:33 UTC
(In reply to Xisco Faulí from comment #13)
> In my case, I can only reproduce the crash when LibreOffice is not
> maximized, otherwise it's not reproduced.
> @Timur: Can you reproduce it when LibreOffice is maximized?

I can reproduce this from 5.3, regardless of window state. I don't see how that cold be related. 
I can't repro with 5.2 neither in Windows nor Linux. Tested with non-debug builds. 
Windows crashes without crash report. Linux has crash report but I can't see ID (that line is empty, don't know why, is it a bug?).  For example, I had crash now on Ubuntu 14.04 VM with master_dbg~2017-07-17_23.22.57_LibreOfficeDev_6.0.0.0.alpha0_Linux_x86-64_archive at 11:04 CET which is I guess 09:04 at crash server.
Comment 15 Timur 2017-07-19 11:22:06 UTC
Created attachment 134732 [details]
Crash Report in Linux Ubuntu

Xisco, why Windows crashes without crash report and more important why Linux has crash report but I can't see ID, that line is empty, don't know why, is it a bug?
As shown on attachment. 
If off-topic, we may hide this conversation.
Comment 16 Xisco Faulí 2017-07-19 13:33:35 UTC
(In reply to Timur from comment #15)
> Created attachment 134732 [details]
> Crash Report in Linux Ubuntu
> 
> Xisco, why Windows crashes without crash report and more important why Linux
> has crash report but I can't see ID, that line is empty, don't know why, is
> it a bug?
> As shown on attachment. 
> If off-topic, we may hide this conversation.

Hi Timur,
I mentioned it to moggi in IRC:
<moggi> x1sc0: no idea, might be that we can not allocate any memory in the signal handler so crash again which causes an abort

Using bibisect-releases I can reproduce it in libreoffice-5.1.0.1
 but not in libreoffice-5.0.6.3. Odd!
Comment 17 Michael Stahl 2017-07-27 20:09:56 UTC
wow, that was a special corner case, good work coming
up with bugdoc & steps to reproduce that.

i don't think it's really a regression, although maybe in older versions
something happened to be done differently so that the bug was hidden.

fixed on master
Comment 18 Commit Notification 2017-07-27 20:11:09 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#108991 sw: fix crash due to not formatted but "valid" SwTextFrame

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 19 Timur 2017-07-28 09:02:35 UTC
Thanx!
Please backport.
Comment 20 Commit Notification 2017-08-02 08:18:37 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2af9630349011a192b21b65c49c91d64a5562fdf&h=libreoffice-5-4

tdf#108991 sw: fix crash due to not formatted but "valid" SwTextFrame

It will be available in 5.4.1.

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.