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
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.
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 ?
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!
Ok thank you for your feedback. I don't have more questions so put back to UNCONFIRMED and uncc myself.
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
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
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
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
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!
[Automated Action] NeedInfo-To-Unconfirmed
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.
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...
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
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?
(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.
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
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.
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.
(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".
(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
(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.
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!
*** Bug 144098 has been marked as a duplicate of this bug. ***
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.