GNOME Bugzilla – Bug 104328
gedit segfault with huge file
Last modified: 2004-12-22 21:47:04 UTC
Package: gedit Severity: normal Version: 2.0.6 Synopsis: gedit segfault with huge file Bugzilla-Product: gedit Bugzilla-Component: general Description: Description of Problem: I was opening a mysql database dump (22mb) in gedit to cut out a few bits and pieces, and this is what happened (bt in gdb because I didn't get the gnome-segfault-dialog) Program received signal SIGSEGV, Segmentation fault. 0x40cca7d2 in pango_get_mirror_char () from /usr/lib/libpango-1.0.so.0 (gdb) bt
+ Trace 33091
I can reproduce that using the database dump every time I open it, but I don't know for sure what is causing it. Probably because the dump is not UTF-8 but something really strange (users like to enter weird characters into my database and I forgot to encode the dump properly) I know this will end up with NEEDINFO, but I don't know what more info to give, so just tell me :) ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-01-24 10:26 ------- The original reporter (bugs@johannes.sipsolutions.de) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, maggi@athena.polito.it.
hmmm... it seems a gtk+ bug but I'm not sure. Please, if you have compiled gtk+ by yourself, try to load the file using the testtext program you find in the gtk+/tests directory and lemme know if it works or not. I don't think the problem is due to the fact the dump is not UTF-8. Thanks.
I had not built gtk myself, but here's what I did now: a) download gtk2 sources a1) ./configure a2) cd tests; make testtext # error due to library not built yet b) link using the .la files present on my system $ /bin/sh libtool --mode=link gcc -g -O2 -Wall -o testtext prop-editor.o testtext.o /usr/lib/libgdk_pixbuf-2.0.la /usr/lib/libgdk-x11-2.0.la /usr/lib/libgtk-x11-2.0.la c) ./testtext Well, then I loaded the document into testtext and after about 480 lines it complained that it wasn't valid UTF-8, clipped the text there and showed the top 480 lines of the document, but other than that nothing happened PS: Cannot reopen since I'm not the owner/submitter (because I used bug-buddy, sorry)
Looks like a similar trace to bug 86713, but upgraded to the newer version of gedit :)
give me a bit, and I'll try to reproduce with a smaller file so you can try it
I'm getting the impression that its related to *extremely* long lines (like 7mb in a line or so)
attaching the best I can do - few hundred k file with nothing but a's in it (and a few special symbols).. its my db dump where I replaced all characters/numbers by a to protect my database and to make it compressible... bunzip2 it and load it, segfaults for me right away (gedit cut4.dump)
Created attachment 13820 [details] test file to reproduce the behaviour (bzip2 compressed text)
I'm quite sure this is a gtk+ or pango bug since I get the same crash (with the same trace in bluefish). In the following I will use the file provided by Johannes Note that I cannot reproduce the crash in testtext since the file contains non valid utf8 text. I also noted that if I load the file in gvim, copy it and paste it in gedit, bluefish and/or test-glimmer-widget I get a crash (quite immediately). I don't get this crash in gtk-demo or testtext, but CPU goes to 100% for a very long period and you cannot see the reault since every time you expose the window the CPU restarts to go to 100%. The traces I get are: 1. Loading the file ======================
+ Trace 33181
======================
fribidi_analyse_string tries to alloca a buffer with the length of the string, which is obviously a bad idea when the length is 609280...
Newer versions of fribidi use malloc here, so this bug will go away when Pango moves to a newer fribidi, see bug 68435
Decided to just go ahead and fix it in our copy of mini-fribidi, since it was trivial. Tue May 27 18:37:44 2003 Owen Taylor <otaylor@redhat.com> * pango/mini-fribidi/fribidi.c (fribidi_analyse_string): Limit the size of the buffers we alloca(). (#104238)