Created attachment 485715 [details] an example Description of problem: attempting to scroll up the displayed info in terminal freezes all open gnome-terminals (for about 5 minutes? maybe). Version-Release number of selected component (if applicable): $ rpm -q gnome-terminal gnome-terminal-2.32.0-1.fc14.i686 How reproducible: sometimes , often Steps to Reproduce: 1. open terminal maximized 2. have a lot of output 3. scroll up with the mouse wheel Actual results: all gnome-terminals freeze Expected results: the output is scrolled up Additional info: having xmms open from terminal, if i close xmms, all terminals come back to life.
Created attachment 485718 [details] unfreezed terminal to exemplify the kind of output. after taking the screenshot, terminals freezed again.
i repeated today the xmms trick. it didn't work.
i switched to text console and i've noticed in htop that gnome-terminal uses 100% of one of the two cpu cores.
ok, it happens if i simply select (by switching desktops) the above terminal, full with chars.
i wrote a test script: #!/bin/bash for i in `seq 1 9000` do echo -n "$i" done which fills the screen with chars. i tried scroll up and terminal immediately freezed. also it immediately unfreezed but this is on another computer so maybe it's somehow machine dependent.
the more i test, the longer the time it's required to recover from freeze. also, a mplayer process in one of the open terminals, eventually freezes too (maybe it was just buffereing). so it's not just the graphics.
Here's the backtrace of what's going on when it hangs. It seems that the issue is caused by a slow regex in vte, which takes a very long time for long lines. Changing the component of this bug to vte. 0x00007ffff4993a2a in match (eptr= 0x94885c "85668567856885698570857185728573857485758576857785788579858085818582858385848585858685878588858985908591859285938594859585968597859885998600860186028603860486058606860786088609861086118612861386148615"..., ecode=<optimized out>, mstart= 0x947a5a "69767076717672767376747675767676777678767976807681768276837684768576867687768876897690769176927693769476957696769776987699770077017702770377047705770677077708770977107711771277137714771577167717771877"..., markptr=0x0, offset_top=2, md=<optimized out>, ims=1, eptrb=<optimized out>, flags=0, rdepth=0) at pcre_exec.c:2686 2686 RMATCH(eptr, ecode, offset_top, md, ims, eptrb, 0, RM21); Missing separate debuginfos, use: debuginfo-install ORBit2-2.14.19-2.fc15.x86_64 adwaita-gtk3-theme-3.0.2-1.fc15.x86_64 dbus-libs-1.4.6-5.fc15.x86_64 dconf-0.7.5-1.x86_64 expat-2.0.1-11.fc15.x86_64 gamin-0.1.10-9.fc15.x86_64 gvfs-1.8.2-1.fc15.x86_64 ibus-gtk3-1.3.99.20110817-3.fc15.x86_64 ibus-libs-1.3.99.20110817-3.fc15.x86_64 libXau-1.0.6-2.fc15.x86_64 libXrender-0.9.6-2.fc15.x86_64 libcroco-0.6.2-6.fc15.x86_64 librsvg2-2.34.0-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libudev-167-6.fc15.x86_64 libuuid-2.19.1-1.4.fc15.x86_64 libxcb-1.7-2.fc15.x86_64 libxml2-2.7.8-6.fc15.x86_64 ncurses-libs-5.8-2.20110319.fc15.x86_64 pixman-0.20.2-2.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64 (gdb) bt #0 0x00007ffff4993a2a in match (eptr= 0x94885c "85668567856885698570857185728573857485758576857785788579858085818582858385848585858685878588858985908591859285938594859585968597859885998600860186028603860486058606860786088609861086118612861386148615"..., ecode=<optimized out>, mstart= 0x947a5a "69767076717672767376747675767676777678767976807681768276837684768576867687768876897690769176927693769476957696769776987699770077017702770377047705770677077708770977107711771277137714771577167717771877"..., markptr=0x0, offset_top=2, md=<optimized out>, ims=1, eptrb=<optimized out>, flags=0, rdepth=0) at pcre_exec.c:2686 #1 0x00007ffff499ce41 in pcre_exec (argument_re=<optimized out>, extra_data=0x834910, subject= 0x947920 "75917592759375947595759675977598759976007601760276037604760576067607760876097610761176127613761476157616761776187619762076217622762376247625762676277628762976307631763276337634763576367637763876397640"..., length=<optimized out>, start_offset=<optimized out>, options=8192, offsets=0x94a180, offsetcount=6) at pcre_exec.c:6099 #2 0x00007ffff49473ff in g_match_info_next (match_info=0x91e860, error=0x0) at gregex.c:580 #3 0x00007ffff4948207 in g_regex_match_full (regex=<optimized out>, string=<optimized out>, string_len=<optimized out>, start_position=<optimized out>, match_options=<optimized out>, match_info=0x7fffffffd8d0, error=0x0) at gregex.c:1566 #4 0x00007ffff7b69ce2 in vte_terminal_match_check_internal_gregex (end=0x7fffffffd92c, start=0x7fffffffd928, tag=0x8350e8, row=<optimized out>, column=<optimized out>, terminal=0x834b80 [TerminalScreen]) at vte.c:1833 #5 vte_terminal_match_check_internal (terminal=0x834b80 [TerminalScreen], column=<optimized out>, row=<optimized out>, tag= 0x8350e8, start=0x7fffffffd928, end=0x7fffffffd92c) at vte.c:1935 #6 0x00007ffff7b6a03c in vte_terminal_match_hilite_update (terminal=0x834b80 [TerminalScreen], x=<optimized out>, y=<optimized out>) at vte.c:6077 #7 0x00007ffff7b6b08e in vte_terminal_match_hilite (y=358, x=478, terminal=0x834b80 [TerminalScreen]) at vte.c:6179 #8 vte_terminal_match_hilite (terminal=0x834b80 [TerminalScreen], x=478, y=358) at vte.c:6150 #9 0x00007ffff7b6b186 in vte_terminal_motion_notify (event=0x9475b0, widget=<optimized out>) at vte.c:7284 #10 vte_terminal_motion_notify (widget=<optimized out>, event=0x9475b0) at vte.c:7255 #11 0x00007ffff76812c8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x652bf0, return_value=0x7fffffffdb50, n_param_values=<optimized out>, param_values=0x7fffdc003b00, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gtkmarshalers.c:85 #12 0x00007ffff546534e in g_closure_invoke (closure=0x652bf0, return_value=0x7fffffffdb50, n_param_values=2, param_values= 0x7fffdc003b00, invocation_hint=0x7fffffffdb10) at gclosure.c:767 #13 0x00007ffff547601a in signal_emit_unlocked_R (node=<optimized out>, detail=0, instance=0x834b80, emission_return= 0x7fffffffdcb0, instance_and_params=0x7fffdc003b00) at gsignal.c:3290 #14 0x00007ffff547f78b in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>) at gsignal.c:2993 #15 0x00007ffff547fb72 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3040 #16 0x00007ffff77a3c59 in gtk_widget_event_internal (widget=0x834b80 [TerminalScreen], event=0x9475b0) at gtkwidget.c:6116 #17 0x00007ffff7680b2a in gtk_propagate_event (widget=0x834b80 [TerminalScreen], event=0x9475b0) at gtkmain.c:2597 #18 0x00007ffff7680ec3 in gtk_main_do_event (event=0x9475b0) at gtkmain.c:1872
The issue seems to be the regex that finds links (defined in src/vteapp.c as DINGUS1 and DINGUS2). What I think is happening is that when the scroll wheel is used, a ton of update events get sent to vte, each of which triggers a regex match on those two regexes. I did a quick, unscientific test with the below Perl script, and even 100 matches of those two regexes against your test string take a noticeable amount of time. If there are more long lines in the history buffer, then it'll take several times longer than that. Perhaps we could add code to vte that does not perform this regex matching for extremely long lines? Other options would be: 1) Not doing this regex matching on *every* motion notification, but only when the scrolling is finished (although this wouldn't help for history buffers with a large number of very long lines). 2) Optimizing the regex more, if possible #!/usr/bin/perl use strict; use warnings; my $str = ""; for my $i (1..9000) { $str .= $i; } my $r1 = "(((gopher|news|telnet|nntp|file|http|ftp|https)://)|(www|ftp)[-A-Za-z0-9]*\\.)[-A-Za-z0-9\\.]+(:[0-9]*)?"; my $r2 = "(((gopher|news|telnet|nntp|file|http|ftp|https)://)|(www|ftp)[-A-Za-z0-9]*\\.)[-A-Za-z0-9\\.]+(:[0-9]*)?/[-A-Za-z0-9_\\\$\\.\\+\\!\\*\\(\\),;:@&=\\?/~\\#\\%]*[^]'\\.}>\\); ,\\\"]"; print "Starting\n"; for (1..100) { $str =~ /$r1/o; $str =~ /$r2/o; } print "Done\n";
Looks like this is upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=350015.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Does this issue still occur with vte/f16 ? (note that gnome-terminal would be using vte3) Can you duplicate it with Terminal (Xfce's terminal)?
Unfortunately, I don't have an F16 machine available for testing yet, but I'm pretty sure that the underlying design flaw hasn't been addressed upstream (based on reading vte code from git). This does affect Terminal in F15, since it uses vte. To test, I did this: 1. Open a new Terminal or gnome-terminal 2. Run for x in {1..100}; do perl -e 'print "A"x30000'; done 3. Perform a mousewheel scroll You may need to adjust the numbers above to see the effect more clearly. For me, the scrolling lags horribly, and the terminal process's CPU usage goes to 100%.
Yep. I see this with f16 as well. Will dig around some more.
Confirmed: this bug is in f16's gnome-terminal too. However, Terminal works fine, in that cpu usage is not going to 100% and the info can be scrollwheeled up and down. I'm using gnome 3 in fallback mode. Also, i don't have a full XFCE install, i only installed Terminal.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.