Created attachment 98741 [details]
this is the file that causes the crash

When creating a text file from the attached file, the file must be named with a .html extension. Also, its a lockup, not a crash. I assume this is caused by the html syntax highlighting. Possibly due to how the code is all on one line with no carriage returns. Modifying of the text while the window is open causes the syntax highlighting to be recalculated, and again an apparent lockup. Window responds again after about 10 seconds, and my machine is fast. Also, this file is fairly short.

Created attachment 98923 [details] [review]
patch

The problem here is that GtkSourceView calls bunch of gtk_text_buffer_apply_tag() in a row, and each call in turn leads to gtk_text_view_update_im_spot_location() call, which is very expensive since it recaculates the line cache.
Attached patch moves gtk_text_view_update_im_spot_location() into an idle, as suggested by Owen.

Comment on attachment 98923 [details] [review]
patch

Please commit

2007-11-11  Yevgen Muntyan  <muntyan@tamu.edu>

	* gtk/gtktextview.c: Moved gtk_text_view_update_im_spot_location()
	calls into an idle, fixes #494776.
	GtkTextViewPrivate:im_spot_idle, do_update_im_spot_location(),
	queue_update_im_spot_location(), flush_update_im_spot_location(): new
	field and functions to queue the call;
	(changed_handler): call queue_update_im_spot_location() instead of
	gtk_text_view_update_im_spot_location();
	(gtk_text_view_key_press_event): flush the idle here.

It seems this bug effects any html file that has long lines which lack carriage returns. Does this effect other syntax highlights besides html?

Yes, any syntax highlighting. If a line is long and has lot of highlighted things (like html - lots of tags and attributes and whatnot), then you get the problem.