Thanks for the bug report. Unfortunately, that stack trace is not very
useful in determining the cause of the crash.  Please make sure that
the package was compiled with debugging symbols and see
http://bugzilla.gnome.org/getting-traces.cgi for more information
about useful stack traces.  Note that you can download debuginfo rpm
packages to install from
http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/debug/

I tried getting a better backtrace two different ways, and neither of
them seemed to produce much more useful results. First I downloaded
and installed the debuginfo rpm and recreated the crash. Here's the
output from bug-buddy:

Backtrace was generated from '/usr/bin/gedit'

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 10627)]
0x43c63008 in waitpid () from /lib/i686/libpthread.so.0

+ Trace 44293

The program is running.  Exit anyway? (y or n) y

It seems unusual that it tried to allocate 400000004 bytes of memory
because the file only contained 100000000 characters. This would
definitely be a problem because I only have 256M of RAM. Also seems
weird that first it said "No such process." but then "The program is
running.".

Any ideas on how I could get a better backtrace?

The problem is:

GLib-ERROR **: gmem.c:140: failed to allocate 400000004 bytes
aborting...

i.e. OUT OF MEMORY.

There is nothing we can do it.

BTW, as I already wrote in another bug report (don't ask me the number
:), gedit/GtkSourceView/GtkTextBuffer has grear problems when dealing
with files containing huge lines.
As the reported (and Owen a few time ago) suggested gedit should
probably refuse to open files with too large lines.

There are two kinds of problem here:

1. GtkTextBuffer/View should not crash when handling texts with huge
lines (

I can reproduce by:
perl -e 'print "testing" x 99999' > test.txt
Open test.txt in gedit
Hasn't crashed yet but hangs 

Gedit should be able to handle large lines more gracefully than by
crashing/locking up.  Either with a message, or actually getting it to
display.
Changing status to new.  Adding GNOMEVER2.4, GNOMEVER2.5, bugsquad 

actually did the above, ooops

I am seeing a similar thing with a 100K line (FYI the RH bugzilla
component list, ie a "real" file). No crash, but a hang in gedit when
trying to edit that file(/line). I am able to force quit gedit however.

I can edit the same file with kedit with no problem.

I see that Paolo's comment was cut off. Line too long? :-)

Theodore, I could open and close your test.txt file. However, contents
are printed garbled on one line. And when I try to move the text
cursor, gedit consumes about 98% of the cpu.

I also tried the file submitted at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117151 and
attached a gdb session. When I used pageup/pagedown over the long
line, and interrupted gdb a few times to print a backtrace with "bt",
then I saw that gedit is busy-busy-busy in these functions:

+ Trace 44670

At first sight this seems to match with the remark of Paolo on
GtkTextBuffer.

In another test, I tried the using the gedit menu, while alt-tabbing
to other windows. This made my X session hang. I didn't have the
patient to wait longer than a minute, so I ctrl-alt-F1'd to kill -9
gedit and gdb.

A short term solution could be to have gedit refuse files with long
lines, like Paolo already suggested.

Apparently the bug paolo was referring to is bug 127731.

Is this a dup of bug 127731?

oops, I meant, is this a dup of bug 114337?

I guess it's not a dup since what everybody seems to be saying is that gedit
needs to be temporarily patched to deal with Gtk-TextWidget's current inability
to handle long lines.

Sorry for the spam.
Changing the summary again.

*** Bug 143180 has been marked as a duplicate of this bug. ***

For reference, also see bug #73119.  This is the bug where Pango needs to
somehow deal with layouts wider than 32767 pixels.

*** Bug 157049 has been marked as a duplicate of this bug. ***

Editing documents with long lines in gedit is an absolute nightmare. It doesn't
crash for me, but it's just really /really/ slow when you try to select the long
line and type anything.

This is a 20,000 column line. Turn on line wrapping and it works much better,
although programming is a bit odd like that.

Basically this comes from me viewing the source of an XHTML document that has no
white-space formatting.

Should I be harking on at GtkTextView/Buffer people, instead?

yes and no... yes in the sense that TextView is to 'blame', no in the sense that
it is a known and expected limitation of TextView design. see bug 114337 for details

*** Bug 318060 has been marked as a duplicate of this bug. ***

This is Debian bug http://bugs.debian.org/360535.

Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/gedit/+bug/37511

I can confirm that this does not happens with gedit 2.30.3 IMO this bug should be closed. Can anyone change the status to OBSOLETE please?

It happens with me in gedit 2.30.3 on Ubuntu 10.10. Status needs to be revised to REOPENED.

Also happens in gedit 2.30.4 on Ubuntu 11.04. Bug should be reopened.

In gedit 3.2.3, If I search something in file that contains long lines the computer hangs. I'm using Ubuntu 11.10

Created attachment 232341 [details]
gedit crashes on this image file generated with scanimage

gedit 3.6.2 hangs also when opening files with long lines.
Example file: test.ppm obtained with scanimage.