After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 464827 - Gedit crash everytime I open this SQL file
Gedit crash everytime I open this SQL file
Status: RESOLVED DUPLICATE of bug 114337
Product: gedit
Classification: Applications
Component: general
2.18.x
Other All
: Normal critical
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2007-08-08 20:56 UTC by adel
Modified: 2007-08-16 13:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
cleandata.sql (58.89 KB, text/plain)
2007-08-08 20:56 UTC, adel
Details
screen shot of cleandata.sql loaded in GEdit (170.77 KB, image/png)
2007-08-16 11:30 UTC, Terence Honles
Details

Description adel 2007-08-08 20:56:01 UTC
Steps to reproduce:
1. open "cleandata.sql" using gedit
2. watching gedit opening file (using a lot CPU)
3. crash


Stack trace:


Other information:
Comment 1 adel 2007-08-08 20:56:44 UTC
Created attachment 93314 [details]
cleandata.sql
Comment 2 Terence Honles 2007-08-16 11:30:23 UTC
Created attachment 93775 [details]
screen shot of cleandata.sql loaded in GEdit

Look at the 3rd & 8th lines of text and you will see characters from the English Alphabet over-layed over eachother (odd bug)
Comment 3 Terence Honles 2007-08-16 11:31:22 UTC
====== Regarding Above Attachment ======

This would have to do with long line support I imagine, I don't know if there is a bug already for this (long line), but I opened it in Kate (for comparison) and it opened fine (But wrapping is different there), and also in GEdit, where I was able to open the file successfully, and able to scroll to the bottom, though it took longer then would be convenient, and then I moved around eventually it slowed to a point I would consider useless

so to test:
1) I disabled all plugins (Restarted)
2) Opened file, worked faster, but still not super fast
3) Disabled syntax highlighting (-> None)

After I disabled syntax highlighting It ran as fast as I would expect any text editor (for scrolling), but then I tried typing and I believe I noticed a difference on the longer lines, but even if I didn't my system did let GEdit use a lot of the CPU when I was typing

(so after all this I still think it might be due to redering long lines (all the coloring for the syntax highlighting)

well I guess I still wasn't finished with testing =P
I disabled the line wrapping and syntax highlighting (so it wouldn't even start on doc.load)

and I got an rather unexpected result for your long lines (see the screen shot)
in words the lines you wrote still got wrapped for some reason (at first I thought it was unicode or something (other lang. in unicode, etc) but when I typed it wasn't showing correctly and when I typed on another line it worked, so when I looked closer they are all characters from the English alphabet, but over-layed over eachover a couple times

so that may have some effect on the problem

well I need to get some rest so thats all the testing I'll do for now
Comment 4 Paolo Borelli 2007-08-16 13:44:01 UTC
Problems with long lines are unfortunately a known and long standing problem of the Gtk Text widget (which gedit uses).
Some of this problems are even design tradeoffs.

*** This bug has been marked as a duplicate of 114337 ***