GNOME Bugzilla – Bug 783844
Opening large non-text file can cause memory leak
Last modified: 2020-11-24 10:00:09 UTC
Opening a large file (I've been testing with non-text files, such as raw binary blobs and movies) and then quitting gedit before it fully loads (since it hangs when trying to work with very large files) can cause an infinite loop with 100% CPU usage and steadily greater and greater memory consumption.
From https://wiki.gnome.org/Apps/Gedit/ReportingBugs -------------------------------------- These bugs crop up fairly often on Bugzilla, and we're trying our best to solve them, but please don't report it if your issue sounds familiar: Very long lines (e.g. a wrapped line that takes the whole screen) are not well supported by gedit, there can be performance problems, freezes or crashes (bug 127731, see also the FAQ). -------------------------------------- I think large binary file does have very long lines. But, why do you want to open binary file with gedit?
(In reply to John from comment #1) > From https://wiki.gnome.org/Apps/Gedit/ReportingBugs > > -------------------------------------- > These bugs crop up fairly often on Bugzilla, and we're trying our best to > solve them, but please don't report it if your issue sounds familiar: > > Very long lines (e.g. a wrapped line that takes the whole screen) are > not well supported by gedit, there can be performance problems, freezes or > crashes (bug 127731, see also the FAQ). > > -------------------------------------- > > I think large binary file does have very long lines. > > But, why do you want to open binary file with gedit? It was accidental. Of course gedit is kinda useless when you open a movie, but this behavior continues after gedit crashes or is closed.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.