GNOME Bugzilla – Bug 118264
Pan's autowrap code too slow & conflicts w/gtkspell
Last modified: 2006-10-06 21:05:40 UTC
Using CVS extract of today, July 25 When I posted something I noticed that for every character I enter it uses up a lot of CPU time causing the entry to slow. It also causes a bunch of messages saying: 'You can apply tags and insert marks without invalidating your interators,' where the comma seems to suggest that more text is to follow, but I don't see any more.
Just saw the 'save log' feature ;pp Fri, 25 Jul 2003 07:56:23 - Gtk - Invalid text buffer iterator: either the iterator is uninitialized, or the characters/pixbufs/widgets in the buffer have been modified since the iterator was created. You must use marks, character numbers, or line numbers to preserve a position across buffer modifications. You can apply tags and insert marks without invalidating your iterators, but any mutation that affects 'indexable' buffer contents (contents that can be referred to by character offset) will invalidate all outstanding iterators Fri, 25 Jul 2003 07:56:23 - Gtk - file gtktextbuffer.c: line 3616 (_gtk_text_buffer_get_line_log_attrs): assertion `GTK_IS_TEXT_BUFFER (buffer)' failed
Forgot this one :-( Fri, 25 Jul 2003 07:56:23 - Gtk - file gtktextbuffer.c: line 3616 (_gtk_text_buffer_get_line_log_attrs): assertion `GTK_IS_TEXT_BUFFER (buffer)' failed
I'm not getting the CPU lag, nor the errors. Hmm. What version of gtk+ are you running? Also helpful: start pan inside of gdb, and set a breakpoint for log_error_breakpoint, then try typing in the compose window so that you can get backtraces for these error messages: % gdb pan (gdb) break log_error_breakpoint Breakpoint 1 at 0x808a55e: file pan.c, line 145. (gdb) r Starting program: /home/charles/src/pan/pan/pan [New Thread 16384 (LWP 4269)] [New Thread 32769 (LWP 4270)] [New Thread 16386 (LWP 4271)] [New Thread 32771 (LWP 4272)] [New Thread 49156 (LWP 4273)] [New Thread 65541 (LWP 4274)] [New Thread 81926 (LWP 4275)] [New Thread 98311 (LWP 4276)] [Switching to Thread 16384 (LWP 4269)] [try composing an article until you reach the breakpoint] Breakpoint 1, log_error_breakpoint () at pan.c:145 145 } (gdb) thread apply all bt [and attach the output of that to this bug report]
[cvs today] gtk: libgtk-2.2.2 The slowdown is still present, but the errors in the log seem to appear only when pressing 'post'. What's even more weird: after I tried running it through gdb I can't seem to get that error anymore. Am I going delerious? ;p
OK! I managed to trigger it again (needed to type a lot of text before it triggers) Appending gdb trace
Created attachment 18673 [details] GDB Trace
aaaahh... looks like I need to dust off a spellchecked copy of Pan. :)
This is consistently reproducable with gtkspell turned on.
Fixed in CVS: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan&command=DIFF_FRAMESET&file=ChangeLog&rev1=1.1918&rev2=1.1919&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=message-window.c&rev1=1.374&rev2=1.375&root=/cvs/gnome
Only one part of this bug is fixed: the high cpu usage is still present!
-N - 10208/10237: Bobby D. Bryant > Something's really wrong with the composition window. > When typing in a reply my CPU usage will jump to over > 50% after a few keystrokes, and not drop back until a > couple of seconds after I quit typing. > > Things were formerly kind of slow if you typed in the > middle of a paragraph and forced re-wrap calculations > with every keystroke, but what I'm seeing with '94 happens > even if you start typing on a blank line.
I can't reproduce this -- when I'm typing, even with spellcheck turned on, my PC barely shows a blip on the CPU monitor (and my PC is no speed demon). So there is most likely something different between my configuration and yours. Jan & Bobby: what version of gtk+ are you using?
I am currently using GTK+ 2.2.2. However, this problem only happened when I tried Pan 0.14.0.94; when I failed back to 0.14.0 the problem went away, even building with the same version of GTK+. Tentative conclusion: if it's a bug in GTK+, it must be in something 0.14.0.94 is using that 0.14.0 isn't. FWIW, I do use spellchecking, and my Pan builds are based on gtkspell 2.2.2. My pango is 1.2.1. Holler if anything else may be relevant. Thanks.
Just out of curiosity, could you try upgrading to pango 1.2.2?
(yes, I'm grasping at straws. ;)
> Just out of curiosity, could you try upgrading to pango 1.2.2? I just tried that, but it broke Pan and several other applications so I had to fail back to 1.2.1. Don't know what the problem is.
Using Debian Unstable, gtk2 2.2.2 pango1 1.2.3 gtkspell 2.0.4
On my system, typing normal text drives my CPU to about 35% (800MHz), with none of the mentioned error messages. The only way I can reproduce this, is to type a big block of text, copy it and then paste it *at the end of the line*, i.e. not on a new line, but at the end of the previous line. This pegs the CPU at 100% for a while and produces a burst of the mentioned error messages. GProf has the following to say: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 40.00 0.02 0.02 10100 1.98 1.98 wrap_line_at_column 20.00 0.03 0.01 9256 1.08 1.08 text_massager_get_wrap_column 20.00 0.04 0.01 mark_set_cb 10.00 0.04 0.01 text_was_inserted_cb 10.00 0.05 0.01 wrap_tb_toggled_cb If helpful, I can see if I can build a gprof-enabled version of gtkspell.
Created attachment 18969 [details] backtrace using paste
Sped up the text wrapping algorithm by ~25%: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan/base&command=DIFF_FRAMESET&file=text-massager.c&rev1=1.1&rev2=1.2&root=/cvs/gnome Chris, does this help any?
Another speedup in the message-window wrapping code: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=message-window.c&rev1=1.376&rev2=1.377&root=/cvs/gnome Does this help any either?
Changes to text-massager.c were already in. The changes to message-window.c help somewhat, according to gprof. The gtk errors on paste, along with the 100% CPU spike remain.
Created attachment 18972 [details] same error, different backtrace
Fixed the error messages: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=message-window.c&rev1=1.379&rev2=1.380&root=/cvs/gnome When we changed the text buffer due to wrap, we invalidated the insert_pos iterator passed into text_was_inserted_cb(). Under certain circumstances, that iterator is actually used again, so we need to revalidate it before text_was_inserted_cb() returns. Chris, please do another CPU test with a fresh CVS build that has the above change. If the CPU usage is reasonable, this issue should be marked as fixed.
Error messages are gone, as are the CPU spikes. Pasting a big block in spell-mode is now near-instantaneous (same as no-spell mode). Marking as fixed (nice work, again).
I've just double-checked my cvs source vs the bonsai-visible changes to make sure I'd gotten all the changes... Unfortunately the problem is still present... If I press any key in the composing window, the system will spike to 100%, and it is very sluggish. The same effect one would get if you would run Wordperfect 6 on a 286 box ;pp Could you give me some pointers (a howto? ;p) on how to build a gprof enabled pan copy?
Well, that's nice, isn't it? :) Just to rule out any CVS sync lag, this is the ChangeLog entry you're looking for: * pan/message-window.c (text_was_inserted_cb): remember that if we change the text that was inserted, that we need to revalidate the GtkTextIterator passed into us by the signal's source. (118264, Bobby D. Bryant) Can you verify that the error messages are now gone? To build a gprof-enabled version of pan: $ CFLAGS="-Wall -ggdb3 -pg" $ ./autogen.sh $ make clean all Running pan then produces a file gmon.out, which you run through gprof: $ gprof pan gmon.out
What can I say ;p Anyway, the entry is present in the ChangeLog, doing a profile build now.
Created attachment 18991 [details] gprof output
This output spent more time indexing your cache than it did wrapping text. :) For a gprof output to make any sense, you need to hit the rewrap code as much as possible. In short, type more. :)
Created attachment 18992 [details] Gprof output, attempt 2 ;p
(i don't know Pan well enough to say this, so hit me if I'm saying something stupid) It seems to me that it doesn't really happen to be the wrapping code. if i post a new message, only the sig is present. if i start typing then, the effect is already visible - even with only 1 character.
That was my experience as well. I was replying to an existing message, but typing into a blank line below the quoted text. The CPU spike occurred regardless of where I was on the line.
Jan, Bobby: what happens if you run without spellcheck?
Jan, Bobby: I was thinking about what differences between your setups and mine and Chris' that could cause the problem. To help narrow down the possible sources of problems. Try doing these one by one and see which one (if any) helps. (1) Run without spellcheck. (2) Turn off your signature file. (3) Post a completely new message so there's no quoted text. Even if things are still slow w/o spellcheck, w/o a signature file, and w/o quoted text, we've still narrowed down the possible causes of the problem.
I'm currently rebuilding pan without spellchecking. I've tried a few things with spellchecking enabled (from today's CVS ofcourse ;p). I'm always trying to post new messages, and with or without signature doesn't really make a difference. When the build has completed I'll test without spellchecking.
Without spellchecking, without signature file, still cpu spikes and the 'laggyness'
<shrug> Maybe the stable release of 0.14.1 will shake out some new testers and insights on this. I've got no idea why you're seeing the behavior that yoou're seeing.
Mass-bumping of 0.14.2 features to 0.14.3 to make way for an emergency 0.14.2 release.
*** Bug 121700 has been marked as a duplicate of this bug. ***
I get this same bug, (with both 0.14.2 and 0.14.2.90) only it's even more annoying than noted here; it actually causes text loss. It happens in both gtkspell-enabled and disabled versions, so long as "wrap text" is turned on. Steps to reproduce: 1) Followup to a news post. 2) Make sure "wrap text" is selected as on. 3) Start adding text to the middle of a line, say a line of quoted text. 4) When the current line hits the 80 column limit and should re-wrap, instead everything in the current paragraph to the right of the cursor is magically deleted. The error message: "Gtk - Invalid text buffer iterator: either the iterator is uninitialized, or the characters/pixbufs/widgets in the buffer have been modified since the iterator was created. You must use marks, character numbers, or line numbers to preserve a position across buffer modifications. You can apply tags and insert marks without invalidating your iterators, but any mutation that affects 'indexable' buffer contents (contents that can be referred to by character offset) will invalidate all outstanding iterators Gtk - file gtktextbuffer.c: line 1697 (gtk_text_buffer_set_mark): assertion `gtk_text_iter_get_buffer (iter) == buffer' failed " Very, very frustrating, as this results in lost text unless "wrap text" is deselected each time.
So, I noticed that the version of the above problem I mention only happens when using a GTK input method, specifically im-ja. im-ja.sourceforge.net It doesn't happen with XIM; I assume there's some sort of conflict between the word wrap and the input method, but I don't know where the blame lies.
*** Bug 127739 has been marked as a duplicate of this bug. ***
*** Bug 147976 has been marked as a duplicate of this bug. ***
Today I removed my custom gtk-2.0 theme and switched to a gtk2-qt based rendering theme, and this problem is _gone_. When I switch back, it's there again. So it seems somehow intermixed with that? Or is it a problem with the text box used (different widget now drawn by QT)? Weird.
It's been literally years since I've seen this problem. Some of the rewrap code was ported over to the C++ rewrite, so I'm hesitant to mark this as `obsolete' yet. I'll hedge my bets and mark this as `needinfo'. If anyone is still getting these problems in the new versions of Pan, please change it to reopened and let me know. Also, running Pan and sysprof at the same time so that you can profile where Pan's running away with the CPU would be _great_.
Updating target release.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information Charles asked for in comment 46. Thanks in advance!
Sorry, forgot to add a while back, that I can't trigger this bug in the C++ rewrite, no matter what I do. So yes, closing it is ideal :) Jan