Created attachment 2548 [details] Test data to reproduce problem 4.3.1git114 Simple test case... (took various tries to get it this reproducible) Using a text editor, open the attachment and copy contents into your copy buffer (I use emacs) Must be in copy buffer as is; no additional wrapping. Compose a new message Edit>Special paste>Unwrapped (this works) Select the just pasted text and cut it (Ctrl+x) Edit->Special paste->Unwrapped CM is now totally unresponsive (100% CPU) with the Edit menu still highlighted. CM must be killed & restarted to recover. Other simple text may not lockup; there appears to be something in this layout that triggers the lockup. I replaced the original text with single letter patterns; but did not change the word lengths or case, and it still locks up. How I stumbled upon this issue: Based on usage experience, CM keeps track of wrapped vs unwrapped text. I wanted the original text (copied from a Signal app message) to appear like it does in Signal, so I simply selected the wrap points and hit Delete a few times to visually unwrap the text; then I selected, cut & pasted it back using Edit>Special paste>Unwrapped to inform CM I wanted it that way. => 100% CPU. 100% reproducible for me. I rebooted my system for new glibc & kernel and the problem persists. HTH
The problem is related to the object replacement character in the text (). This can be reproduced with just pasting the object replacement character alone, without any other text.
On further testing, I find that any type of paste following the cut will cause the lockup.
It seems that this is a GTK3 bug in _gtk_text_buffer_serialize_rich_text()