Description: LibreOffice crashes when I try to make a space using the space bar and then put a : or a ! or a ; Steps to Reproduce: 1.click several time and the space bar 2.put a : or ; or ! Actual Results: LibreOffice crash Expected Results: Just write " :" Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
I can't reproduce the issue: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
You must click at least 6 times on the space bar and then put a : Then libreoffice crash
I can't reproduce it in Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0f82e9d42822e627edd1fb3b3c87e1f8a22136a4 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
ran the test on 3 different computers (laptop and desktop) and reset the user profile, nothing changed.
Again, I can't reproduce with: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Created attachment 191461 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I got an assertion.
I also got a crash with LO Debian package 7.6.4.1, I got a crash and noticed these logs: terminate called after throwing an instance of 'std::out_of_range' what(): basic_string_view::substr: __pos (which is 4) > __size (which is 3) Unspecified Application Error
It's specific to French UI since LO goes into SvxAutoCorrect::FnAddNonBrkSpace and rTxt is changed afterwards.
It resembles the pb which has been fixed with 971c9945825db02a4809538d26fff3ae77d16866 1) const OUString& rTxt which had been replaced with std::u16string_view rTxt 2) as Mike indicated: // rTxt may refer to the frame text that will change in the calls to rDoc.Delete / rDoc.Insert; // keep a local copy for later use OUString aOrigTxt = rTxt; I tried to apply the same but it still crashes. After this part: 730 if ( nEndPos - nPos > 0 ) 731 rDoc.Delete( nPos, nEndPos ); rTxt has a smaller size whereas nEndPos hasn't changed so crash. No idea what to do.
Also reproduced in Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: c94961c6869c34b3874d21cfaa5ec1488609acfe CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: fr-FR (es_ES.UTF-8); UI: en-US Calc: threaded it's important to use the French locale
(In reply to Julien Nabet from comment #9) > It resembles the pb which has been fixed with > 971c9945825db02a4809538d26fff3ae77d16866 > > 1) const OUString& rTxt which had been replaced with std::u16string_view rTxt > 2) as Mike indicated: > // rTxt may refer to the frame text that will change in the calls to > rDoc.Delete / rDoc.Insert; > // keep a local copy for later use > OUString aOrigTxt = rTxt; > > I tried to apply the same but it still crashes. > After this part: > 730 if ( nEndPos - nPos > 0 ) > 731 rDoc.Delete( nPos, nEndPos ); > > rTxt has a smaller size whereas nEndPos hasn't changed so crash. > > No idea what to do. Hi Mike, I thought you might be interested in this issue
https://gerrit.libreoffice.org/c/core/+/160924 French locale is not required: the only required thing is French text (so it initiates specific autocorrection rules).
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1325d66a7f8657aaf9951a0664fbf14cca86905b tdf#158703: return updated position from FnAddNonBrkSpace It will be available in 24.8.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/64e371c6db51a2be53e0436b762fd96e84f49e04 tdf#158703: return updated position from FnAddNonBrkSpace It will be available in 24.2.0.0.beta2. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/7eac2d2fded789a3dd64b738d816ce0b6270decc tdf#158703: return updated position from FnAddNonBrkSpace It will be available in 7.6.5. 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.
*** Bug 158529 has been marked as a duplicate of this bug. ***
(In reply to Xisco Faulí from comment #16) > *** Bug 158529 has been marked as a duplicate of this bug. *** Well, in theory, it was the other way around, bug 158703 is/was a dupe of bug 158529, which already had the problematic setting identified several days before bug 158703 even existed. But since Mike already committed his patch in relation to bug 158703, let's leave it as-is.
(In reply to ady from comment #17) Please note, that it is reasonable to mark older bugs as dupes of newer ones, if latter provide better discussion (better description, code pointers, less "me-too" comments etc.) - even when the bug isn't solved. There is no bounty paid for "first report", so the date of bug creation / its number bears no value, only its data, dupe count, CC count, stuff like that.
(In reply to Mike Kaganski from comment #18) > (In reply to ady from comment #17) > > Please note, that it is reasonable to mark older bugs as dupes of newer > ones, if latter provide better discussion (better description, code > pointers, less "me-too" comments etc.) - even when the bug isn't solved. > There is no bounty paid for "first report", so the date of bug creation / > its number bears no value, only its data, dupe count, CC count, stuff like > that. I am aware of it, and it indeed makes sense. IMHO, this was not the case. The behavior and the actions to trigger the problem were already available days before the newer report was even filed in. It just happened, by chance, that the older report was still set as unconfirmed whereas (again, by chance) the newer one was confirmed by Julien, so the newer one was more visible. The older report was clearly aimed at the origin of problem after the initial tests. Of course I'm not blaming anyone; it was just a comment about the "direction" of the dupe. Anyway, hopefully it will be verified as solved in the very newer future. TY.
With master sources updated today (included Mike's patch), I confirm I don't reproduce the crash. Thank you Mike! :-)