Xed freezes opening a non-standart file

[JimusHimus]

* xed - Version 3.0.2
* Distribution - Linux Mint 20.2 Cinnamon

Issue
When I open .nvram file from VirtualBox VM directory xed freezes.

Steps to reproduce
Open Test.nvram

Expected behaviour
The file is expected to load without freezing.

Other information
If I do head -c 4096 Test.nvram > Test2.nvram and open Test2.nvram it loads slowly but without completely freezing.
Attached file Test.nvram but with .txt extension.
Test.txt

[jmccardle]

This bug is still present on xed version 3.8.9. I've noticed this same behavior myself: large unformatted JSON files also trigger xed to lock up. I've found the root cause using the test file provided by JimusHimus and synthetic single-very-long-line files.

Root Cause Analysis

The freeze is caused by Pango/HarfBuzz text shaping being called on the entire line as a single unit, regardless of wrap mode. The call chain on the main thread is:

gtk_text_layout_get_line_display
  → pango_shape_item
    → hb_shape_full (HarfBuzz)

This blocks the GTK main loop — the UI is completely unresponsive until shaping completes. It happens with both GTK_WRAP_WORD and GTK_WRAP_NONE because GTK needs the full line layout even just for scrollbar sizing (gtk_text_layout_validate_yrange).

Replication

The original .nvram file has 469 lines, but one line is 497,717 bytes long. A minimal reproduction is:

python3 -c "import random, string; chars=string.printable.replace('\n','').replace('\r',''); print(''.join(random.choice(chars) for _ in range(200000)))" > /tmp/longline.txt
xed /tmp/longline.txt

Benchmarks (varied ASCII content, single line, CPU usage measured after 5 seconds):

Line length	CPU %	Status
10,000	8%	Responsive
50,000	13%	Responsive
100,000	39%	Sluggish
200,000	100%	Frozen
500,000	100%	Frozen

Uniform content (e.g. 'x' * 500000) shapes much faster due to HarfBuzz optimizations — varied character sequences are what trigger the worst case. The original .nvram binary data is the worst case.

Confirmed via GDB stack sampling — the main thread is consistently stuck in:

#0  hb_shape_full () at libharfbuzz.so.0
#6  pango_shape_item () at libpango-1.0.so.0
#8  gtk_text_layout_get_line_display () at libgtk-3.so.0
#11 gtk_text_layout_validate_yrange () at libgtk-3.so.0

[jmccardle]

0001-Fix-freeze-when-opening-files-with-very-long-lines.patch

0002-Cap-long-line-detection-read-to-1MB-and-minor-review.patch

4 files changed, fixing the freeze when opening files with extremely long lines:

xed/xed-tab.c: main fix for GitHub issue #491

• content_has_long_lines(): O(n) scan of raw file bytes for any line >10,000 bytes
• split_long_lines_in_content(): Splits long lines by inserting newlines at the threshold
• In _xed_tab_load(): Pre-reads the file with g_file_load_contents(). If long lines are detected, splits them, sanitizes to valid UTF-8, and inserts directly into the buffer via gtk_text_buffer_set_text(). This bypasses GtkSourceFileLoader whose per-chunk async loading triggers expensive GtkSourceView signal handlers. Sets the document read-only and shows a warning info bar.
• XED_MAX_LINE_LENGTH is a compile-time #define set to 10,000

xed/xed-window.c: secondary optimization

• update_cursor_position_statusbar(): Replaced the O(n) char-by-char column counting loop with gtk_text_iter_get_line_offset() for lines without tabs. The old loop was a separate freeze vector: called on every buffer change, it iterated character-by-character through binary content.

xed/xed-io-error-info-bar.c + .h: warning UI

• New xed_long_lines_info_bar_new() following existing info bar patterns

is this ideal?

I'm not sure. Honestly I think 50,000 would work just as well for max line length, even 150k might be worth it. The current patch basically says that single-line files over 10kB can't be edited by xed, and it might be better if that limit were 150kB. But I still think this patch should be considered because attempting to open the wrong file currently crashes the entire text editor, which is a frequent enough peril that I finally tried to fix it myself.