GNOME Bugzilla – Bug 127731
GtkTextView: Problems with very long lines.
Last modified: 2018-05-02 13:54:08 UTC
Hello, I discover a strange but simple buffer overflow in gedit. I am using RH9, to demostrate the buffer here is a simple file buffer generator: ===========buffer.c == cut here=============== /* simple buffer overflow generator by MegaHz megahz@megahz.org */ #include <iostream> using namespace std; int main() { int i; for (i=0;i<=9999999;i++) { cout << "A"; } return 0; } =========================================== # g++ -o buffer buffer.c # ./buffer > lala # gedit lala Segmentation fault # MegaHz (Andreas Constantinides) www.megahz.org www.cyhackportal.com
Are you able to reproduce it using the testtext program in gtk+/tests ?
This is a GtkTextView bug, it seems to have big problems with long lines.
Backtrace? Do you think you could try to debug the problem, Paolo? (Note that this is expected to be *very* slow. And for that reason, gedit should probably check for this when loading text files. But it shouldn't crash.)
Well, I tried with a shorter file, it didn't crash for me but after a *very* long period (about 10 minutes) it gave me an unreadable line of text (the characters was placed one upon another) See also the related bug #114337. I will try again with a bigger file when I will be back at work.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
This bug would appear to be causing Eclipse users some trouble. Any chance of this getting some attention? https://bugs.eclipse.org/bugs/show_bug.cgi?id=87299 cheers, jed.
*** Bug 431636 has been marked as a duplicate of this bug. ***
Anyone can take a look to this bug? This bug is 10 years old!!! Please!!! Gedit, Anjuta and a lot of applications use GtkTextView (GtkSourceView in this case) and In my job y cannot open large json, xml etc files to work with it. I don't know how to fix it, I haven't got the knowlege to do it :( Really it is so difficult? If someone helps me I can try to fix it.
*** Bug 709899 has been marked as a duplicate of this bug. ***
*** Bug 605978 has been marked as a duplicate of this bug. ***
*** Bug 669650 has been marked as a duplicate of this bug. ***
*** Bug 735327 has been marked as a duplicate of this bug. ***
*** Bug 741358 has been marked as a duplicate of this bug. ***
*** Bug 741499 has been marked as a duplicate of this bug. ***
*** Bug 746919 has been marked as a duplicate of this bug. ***
This bug is now close to 12 years old. To help add some incentive to fix it, I put a $50 bounty on this bug. I encourage others to add to the bounty. https://www.bountysource.com/issues/3553416-gtktextview-problems-with-very-long-lines
If this bug is about a crash, I still haven't seen a backtrace. If this bug is, on the other hand, about performance issues with long lines of text inside GtkTextView, then it's highly unlikely that this bug can be fixed without side effects or in a reasonable amount of time — even with a bounty. After all, it's not like this bug has been left open for 12 years because it's trivial to fix. Measuring text is an inherently expensive operation, and GtkTextView already tries to minimise it by splitting up paragraphs into separate PangoLayouts; this is obviously not going to work if the whole file is inside a single line. Ideally, the editor could apply some sort of normalization rule for structured text contents, and add line breaks where semantically makes more sense — i.e. XML could be "prettified" on load, and "unprettified" on save — but that's something that can only be done at a layer above the tool kit (a GtkTextView has no idea what it's currently displaying).
Steps to reproduce: 1. wget https://cdnjs.cloudflare.com/ajax/libs/extjs/6.0.0/ext-all.js 2. gedit ext-all.js Result: gedit will freeze Notes: This minified javascript file is only 2.1 MB, but it is one line that is 2067722 characters long. Opens in vim, firefox, chromium, and Kate just fine.
Just hanging. No crash here. $:andre\> rpm -q gedit gedit-3.16.2-1.fc22.x86_64 $:andre\> wget https://cdnjs.cloudflare.com/ajax/libs/extjs/6.0.0/ext-all.js $:andre\> gdb gedit (gdb) run ext-all.js [...] (gedit:5001): GtkSourceView-CRITICAL **: Highlighting a single line took too much time, syntax highlighting will be disabled [...] ^C Program received signal SIGINT, Interrupt. process_item (layout=layout@entry=0x17b2230, line=line@entry=0x2c59e80, state=state@entry=0x7fffffff7b10, force_fit=force_fit@entry=1, no_break_at_end=no_break_at_end@entry=0) at pango-layout.c:3438 3438 width += state->log_widths[state->log_widths_offset + i]; (gdb) thread apply all bt
+ Trace 235316
Thread 1 (Thread 0x7ffff7fb9980 (LWP 5252))
(gdb) info register rax 0x185eed 1597165 rbx 0x0 0 rcx 0x592e1f4 93512180 rdx 0x1eb831 2013233 rsi 0x6d595400 1834570752 rdi 0x166c00 1469440 rbp 0x7fffffff7b10 0x7fffffff7b10 rsp 0x7fffffff7980 0x7fffffff7980 r8 0x0 0 r9 0x2400 9216 r10 0x2400 9216 r11 0x0 0 r12 0x0 0 r13 0x17b2230 24846896 r14 0x7fffffff7ad0 140737488321232 r15 0x0 0 rip 0x7ffff6334550 0x7ffff6334550 <process_item+240> eflags 0x216 [ PF AF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) list 3433 width = pango_glyph_string_get_width (state->glyphs); 3434 } 3435 else 3436 { 3437 for (i = 0; i < item->num_chars; i++) 3438 width += state->log_widths[state->log_widths_offset + i]; 3439 } 3440 3441 if ((width <= state->remaining_width || (item->num_chars == 1 && !line->runs)) && 3442 !no_break_at_end)
*** Bug 756086 has been marked as a duplicate of this bug. ***
*** Bug 756400 has been marked as a duplicate of this bug. ***
I tried even a 150kB single line file and it froze up. This along with it freezing up with binary files (bug 676526) and freezing up searching files with long lines (bug 756086) are all still alive and well in 3.22.0. The biggest problem I have with these bugs is having other files open which happen to not be saved and having gedit freeze up for an unknown amount of time, sometimes having to just kill gedit and lose my work. It's rare since I'm addicted to Ctrl-S but when it does happen, it's insanely frustrating, and gedit doesnt have a restore after crash. If it's not easy to fix properly, can't these operations at least be made completely asynchronous (see comment on bug 676526#c14) so at least the rest of gedit remains usable?
FTR: Loading the file generated by python -c 'print "A"*18192' > /tmp/crash.yml crashes gedit for me.
OK, proper fixes aside, since this is an *extremely* old bug that warrants its own entries on both https://wiki.gnome.org/Apps/Gedit/ReportingBugs and https://wiki.gnome.org/Apps/Gedit/FAQ, and is very painful if the user has unsaved files already open (and so can't readily kill gedit) it would make a huge amount of sense to just add a trivial check along the lines of "wc -L $filename", then warn "this file has very long lines and is likely to freeze Gedit for several minutes when opening/searching/whatever, continue?" before opening. Even better, (or as well), offer to use standalone mode (gedit -s) so that it doesn't wreck the existing instance for several minutes.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/229.