Bug 166354 - Crash when em dash is used in notes
Summary: Crash when em dash is used in notes
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2025-04-26 11:43 UTC by MherDelight
Modified: 2025-11-25 15:27 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MherDelight 2025-04-26 11:43:30 UTC
Description:
After adding a note to some text, if the em dash is added by writing :---:, the program crashes. This includes other dashes, such as :--: and :-:.

Steps to Reproduce:
1. Add a note by right-clicking some text and selecting "Insert Comment"
2. Type in :---:

Actual Results:
The program crashes.

Expected Results:
The :---: to be replaced with the em dash, just like in the normal text input.


Reproducible: Always


User Profile Reset: No

Additional Info:
I still haven't tested if this bug happens when changing the author name or with different characters other than the em dash and the :--:
Comment 1 Mateusz Wlazłowski 2025-04-26 12:05:08 UTC
No crash for me. 

Try in Safe mode in Help > Restart in Safe Mode

Also please give us your version information in Help > About Libreoffice



Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded
Comment 2 BogdanB 2025-04-26 18:40:20 UTC
if I press Enter after :---: I get

!!br0ken!!
!!br0ken!!

If I move the cursor then press Enter I get an em dash..

No crash.
Comment 3 BogdanB 2025-04-26 18:41:19 UTC
Tested with
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 356f916d0e7dbab7f871c3feb19c6e1292c2a2f5
CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Also with
Version: 25.2.3.1 (X86_64) / LibreOffice Community
Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b
CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 4 BogdanB 2025-04-26 18:42:44 UTC
:~/core/core$ git grep 'br0ken'

include/rtl/ustrbuf.hxx:        rtl_uString_newFromLiteral( &pData, "!!br0ken!!", 10, 0 ); // set to garbage
include/rtl/ustrbuf.hxx:        rtl_uString_newFromLiteral( &pData, "!!br0ken!!", 10, 0 ); // set to garbage
include/rtl/ustring.hxx:        rtl_uString_newFromLiteral( &pData, "!!br0ken!!", 10, 0 ); // set to garbage
include/rtl/ustring.hxx:        rtl_uString_newFromLiteral( &pData, "!!br0ken!!", 10, 0 ); // set to garbage
sal/rtl/strtmpl.hxx:        return newFromStr_WithLength(ppThis, "!!br0ken!!", 10);
sw/qa/uitest/writer_tests7/tdf104795.py:            # AssertionError: '12/19/2016, 23:06:31, timur.davletshin' != '12/19/2016, 00:00:00, !!br0ken!!'
Comment 5 V Stuart Foote 2025-04-27 11:25:44 UTC
Can not reproduce with
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6869da60961a6213fc961c2ece371c0f18038cde
CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Thought perhaps it was corrupt user copy of the autocorrect list (created per user in profile once user adds a 'New' entry to their list). Otherwise uses the default shared. Check Tools -> Options -> Paths for location of the acor*.dat file.

Clean profile will use the language appropriate from the $ORIGIN/share directory.

Simple rename of the acor*.dat (profile and share) does not crash. Just no substitution gets performed.

Still need to know if profile reset clears it for OP.
Comment 6 QA Administrators 2025-11-25 15:27:08 UTC
Dear MherDelight,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping