Bug 144106 - FILEOPEN: LibreOffice crashes on opening CSV file with "Trim spaces" option enabled
Summary: FILEOPEN: LibreOffice crashes on opening CSV file with "Trim spaces" option e...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: high normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:7.3.0 target:7.2.2
Keywords: bibisected, bisected, regression
: 144098 (view as bug list)
Depends on:
Blocks: CSV-Dialog
  Show dependency treegraph
 
Reported: 2021-08-26 16:47 UTC by robert
Modified: 2021-09-27 11:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["lcl_appendLineData"]
Regression By:


Attachments
File than cannot be opened (805.48 KB, text/csv)
2021-08-26 16:48 UTC, robert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robert 2021-08-26 16:47:26 UTC
Description:
The attached CSV file immediately crashes Calc when double-clicked to open it.

Steps to Reproduce:
1. Double click the attached "lift.csv"

Actual Results:
Crash

Expected Results:
Open, like in the previous versions


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.4 (x64) / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-US
Calc: threaded
Comment 1 robert 2021-08-26 16:48:48 UTC
Created attachment 174565 [details]
File than cannot be opened

This file immediately crashed LO when I'm trying to open it by double clicking it.
Comment 2 Julien Nabet 2021-08-26 18:15:00 UTC
On pc Debian x86-64 with master sources updated today or with LO Debian package 7.4.5, I don't reproduce this.

Could you test with LO 7.1.5 or brand 7.2.0 ?
Also, can you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ?
Comment 3 robert 2021-08-26 19:20:27 UTC
It works abso-fluck-ingly flawlessly with 7.1.5.2, to which I had to revert, by uninstalling 7.2, which wiped out I don't know how many settings - suddenly the Spanish dictionary came back as did South-African English as a interface language... 

Needlessly to say, I will stay on 7.1.5.2, as this situation should never ever have passed any QA. 

And as for "Corrupted user profile", if you don't know what causes it, *I* am not going to reset anything!
Comment 4 Julien Nabet 2021-08-26 20:33:11 UTC
Ok thank you for your feedback.
I don't have more questions so put back to UNCONFIRMED and uncc myself.
Comment 5 [REDACTED] 2021-08-26 20:59:47 UTC
No repro

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded


No repro

Version: 7.1.5.2 / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

No repro

Version: 7.2.0.4 (x64) / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 1; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded
Comment 6 [REDACTED] 2021-08-26 21:02:50 UTC
No repro

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4debb7e8cc12563f46d1aaa58afdcb831f21cc83
CPU threads: 1; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded
Comment 7 Alex Thurgood 2021-08-27 09:15:14 UTC
No repro with

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded
Comment 8 Roman Kuznetsov 2021-08-28 17:41:19 UTC
No problem in

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4debb7e8cc12563f46d1aaa58afdcb831f21cc83
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL

nor in

Version: 7.2.0.4 (x64) / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

Robert, please try follow steps:

1. Select menu Help->Restart in Safe mode
2. After LO restarted in opened Safe mode dialog select "Reset user profile" option (it will drop your LibreOffice's user profile, but not system!)
3. Press "Apply and Restart" button

I think it should just help you
Comment 9 robert 2021-08-31 09:32:33 UTC
Let me understand this...

I've been upgrading LO without any problem from at least version 5.x to the current 7.1.5.2, and 99.9% of my use id for one single spreadsheet that contains my hitchhike data, and which is augmented with a few rows every month. All I do is open the ODS, open the CSV with the new rows at the bottom, import those new rows, add a column, and copy the new data to the existing sheet.

And this, which is what I've been doing for about a decade or so, is supposed to corrupt my user profile?

I might try 7.2 once it appears in PortableApps, but that's it. Opening the CSV that I've been using for a decade, and even a slimmed down version that just contained the 9 additional rows causes a crash, and when you tell me that it can be caused by a corrupt user profile, you tell me why the profile is corrupted, and don't suggest any "maybe reboot" type solutions that do not resolve the root of the problem!
Comment 10 QA Administrators 2021-09-01 04:18:53 UTC Comment hidden (obsolete)
Comment 11 Timur 2021-09-06 11:48:44 UTC
Hi Robert. 
Please understand you're communicating with LO volunteers, who all tried their best. 

Nobody reproduced the problem, that should be done with 7.2.0. Me also, 7.2.0 and 7.3+ in Windows.
Maybe it's about CSV import options? Please attach screenshot of your import options or write if you can, what you set on import. 

As for User profile reset, that's a standard procedure when bug cannot be reproduced. 
You can do safe test to see the bug status, get LO master 7.3+ from https://dev-builds.libreoffice.org/daily/master/current.html and install - it will be separate to your working LO 7.1 and won't take over shortcuts.
Comment 12 robert 2021-09-11 20:52:22 UTC
I just installed 7.1.6.2, and guess what? It worked flawlessly, so please do not suggest corrupt user profiles, or invalid import options, which by the way have not been changed for about umpteen years, other than that at least a full version ago, i.e. 6.x, I told it to trim spaces.

I might try 7.3 in a few months, and that doesn't work? I still use WinRAR 4.2, GIMP 2.8.22, and Inkscape 0.92.4, for similar reasons...

"New and now even whiter" doesn't impress me, if this is the end of the line for LO upgrades, so be it, I'm quite likely one of the 80% that only uses 20% (or more likely one of the 95% that uses 5%) of the features anyway.

As for the volunteers, trying to help, I've reported bugs in the handling of RTF files as early as 2016 (See e.g. 104390, LO 5.2.3.3) that are still not resolved...
Comment 13 QA Administrators 2021-09-12 03:49:31 UTC Comment hidden (obsolete)
Comment 14 Ming Hua 2021-09-12 05:07:03 UTC
Hi Robert,

LibreOffice's CSV import feature has many options, which you probably already saw in the import dialog.  Also it remembers the options you've set last time to use them on future imports.  So if you are using non-default options, other people would have difficulties reproducing your problem, unless you tell them what options you used.

This is the reason QA people have been telling you to reset user profile -- that way you'll realize what options you have been accustomed to are actually non-default and need to be set from a fresh user profile.  Another way is providing a screenshot of your CSV import dialog, as Timur suggested in comment #11.

(In reply to robert from comment #12)
> other than that at least
> a full version ago, i.e. 6.x, I told it to trim spaces.
With all that said, I *think* I can reproduce this now.  When trying to import the attached sample CSV file in 7.2.0 RC3 and choosing "Trim spaces" in the import dialog, my LibreOffice hangs immediately.  The import dialog disappears, no document is opened, the UI freezes and LO has to be killed in task manager.

Version: 7.2.0.3 (x64) / LibreOffice Community
Build ID: 2a7ea282da28d665a7dc086360567b4aea27bf08
CPU threads: 2; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: en-US
Calc: threaded
Comment 15 robert 2021-09-12 10:21:50 UTC
Import options:

UTF-8
Default - English UK
Separated by
Comma
Trim spaces
String delimiter "
Detect special numbers
Columns 3 & 6: Date (YMD)

And as far as remembering goes, every time "Space" (for "Separated by") is also checked when I open a CSV file, it is ***NOT*** remembered!

And if it is a corrupt user profile problem, why didn't it happen after reverting to 7.1.5.2, or just yesterday, after upgrading to 7.1.6.2?
Comment 16 Ming Hua 2021-09-12 10:41:48 UTC
(In reply to robert from comment #15)
> And if it is a corrupt user profile problem, why didn't it happen after
> reverting to 7.1.5.2, or just yesterday, after upgrading to 7.1.6.2?
In this case it's not a *corrupted* user profile, but it's still related to user profile (or more specifically, the remembered CSV import options), therefore other people testing with a fresh user profile could not reproduce.

You've likely encountered a real bug, but one that only happens for non-default setting, therefore wasn't discovered in the testing process until now.
Comment 17 Roman Kuznetsov 2021-09-12 14:54:31 UTC
Aha! After Ming's comment I could repro it, really if you selected Trim spaces option then LO crashes.

So, I bisected it and got

https://git.libreoffice.org/core/commit/1efec9ec21dba32335e311d367b636538e219621

https://gerrit.libreoffice.org/c/core/+/107425

Added to CC: Stephan Bergmann

Stephan, could you please look at this
Comment 18 Commit Notification 2021-09-13 19:27:28 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4a4be7a1edead11b48e1a8598e52a3246e6744bb

tdf#144106 Don't proceed ptrim_i past ptrim_f

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2021-09-14 05:58:09 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/141c6f932ed6eb52b3da99143520f058bb3b4a99

tdf#144106 Don't proceed ptrim_i past ptrim_f

It will be available in 7.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Stephan Bergmann 2021-09-14 09:26:12 UTC
(In reply to Roman Kuznetsov from comment #17)
> So, I bisected it and got
> 
> https://git.libreoffice.org/core/commit/
> 1efec9ec21dba32335e311d367b636538e219621
> 
> https://gerrit.libreoffice.org/c/core/+/107425

Roman, just to make sure, you bisected this with a 32-bit LO Windows build, not with a 64-bit one, right?  (In case you use bibisect repos for bisecting: please always state which repo you use and which commit in that repo was identified as the problematic one.)  That would be my only explanation how your identification of <https://git.libreoffice.org/core/+/1efec9ec21dba32335e311d367b636538e219621%5E!/> "Tighten rtl_{string,uString}_newFromStr_WithLength implementation" as the problematic commit would match my analysis in the commit message of <https://git.libreoffice.org/core/+/4a4be7a1edead11b48e1a8598e52a3246e6744bb%5E%21> "tdf#144106 Don't proceed ptrim_i past ptrim_f".
Comment 21 Roman Kuznetsov 2021-09-14 09:44:17 UTC
(In reply to Stephan Bergmann from comment #20)
> (In reply to Roman Kuznetsov from comment #17)
> > So, I bisected it and got
> > 
> > https://git.libreoffice.org/core/commit/
> > 1efec9ec21dba32335e311d367b636538e219621
> > 
> > https://gerrit.libreoffice.org/c/core/+/107425
> 
> Roman, just to make sure, you bisected this with a 32-bit LO Windows build,
> not with a 64-bit one, right?  (In case you use bibisect repos for
> bisecting: please always state which repo you use and which commit in that
> repo was identified as the problematic one.)  That would be my only
> explanation how your identification of
> <https://git.libreoffice.org/core/+/
> 1efec9ec21dba32335e311d367b636538e219621%5E!/>

I used win64-7.2 bisect repo on Windows 7 64 bit and I double checked the result at once because I was not sure in the result

There are no 32 bit win bisect repos since 6.4 version
Comment 22 Stephan Bergmann 2021-09-14 12:02:54 UTC
(In reply to Roman Kuznetsov from comment #21)
> (In reply to Stephan Bergmann from comment #20)
> > (In reply to Roman Kuznetsov from comment #17)
> > > So, I bisected it and got
> > > 
> > > https://git.libreoffice.org/core/commit/
> > > 1efec9ec21dba32335e311d367b636538e219621
> > > 
> > > https://gerrit.libreoffice.org/c/core/+/107425
> > 
> > Roman, just to make sure, you bisected this with a 32-bit LO Windows build,
> > not with a 64-bit one, right?  (In case you use bibisect repos for
> > bisecting: please always state which repo you use and which commit in that
> > repo was identified as the problematic one.)  That would be my only
> > explanation how your identification of
> > <https://git.libreoffice.org/core/+/
> > 1efec9ec21dba32335e311d367b636538e219621%5E!/>
> 
> I used win64-7.2 bisect repo on Windows 7 64 bit and I double checked the
> result at once because I was not sure in the result

That's odd, as for a Windows x86-64 build it should have hit

        if (sv.size() > sal_uInt32(std::numeric_limits<sal_Int32>::max())) {
            throw std::bad_alloc();
        }

in OUString::operator+=(std::u16string_view) (include/rtl/ustring.hxx) before hitting 1efec9ec21dba32335e311d367b636538e219621 "Tighten rtl_{string,uString}_newFromStr_WithLength implementation".  But anyway, the commit from comment 18 should fix this for all kinds of 32- and 64-bit builds, on all platforms.
Comment 23 Roman Kuznetsov 2021-09-14 20:09:04 UTC
Verified in

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 80a47aae1419842f4496f02028e2b49763aea25b
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded

Thank you, Stephan!
Comment 24 Xisco Faulí 2021-09-27 10:09:48 UTC
*** Bug 144098 has been marked as a duplicate of this bug. ***
Comment 25 kubbugrep 2021-09-27 11:12:46 UTC
As written in Bug report 144098 it is not just the "Trim spaces" option, but that option in combination with the "Separated by" "Space" option.