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.
Created attachment 134518 [details] Cut text - Bad allocation in 5.2.7 with WinDBG
Created attachment 134519 [details] Cut text - Assertion failed in 6.0+ with WinDBG
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.
"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.
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
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
Created attachment 134588 [details] gdb backtrace
(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.
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...
I've also reported bug 109081, which might be related
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...
Anyway, this is definitely a regression
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?
(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.
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.
(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!
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
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.
Thanx! Please backport.
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.