GNOME Bugzilla – Bug 676526
Opening binary file freezes gedit
Last modified: 2020-11-24 09:57:26 UTC
Created attachment 214621 [details] gedit after opening a binary file If I try to open a binary file in gedit, there used to be some notification "This appears to be a binary file. Do you really want to open it?". But in GNOME 3.4, the gedit window freezes instead. It is a gray window with nothing in it, not even the control widgets. The application has to be killed, nothing else works. Screenshot attached. Reproducer: 1. $ dd if=/dev/urandom of=binary_file bs=1M count=1 2. gedit binary_file gedit-3.4.1-2.fc17.x86_64, Fedora 17
Actually it doesn't freeze completely it takes a looong time to get it to open. We need a better heuristic to detect them. This is in my todo list for a while but I was lazy to make it :)
*** Bug 652607 has been marked as a duplicate of this bug. ***
Has this bug made its way any higher on the todo list? =)
Feeling like helping? :)
Possibly. Got some pointer as to where in the code the problem is? And why this worked in 2.x? =)
Created attachment 243941 [details] [review] binary detection patch The encoding detection is a bit funky since it tries to cope with broken utf-8 as well. So it is difficult to tell what to do here. The method I chose was to look for nulls in the utf-8 (which seems to be used as a fallback). If too many nulls are seen, then it won't be accepted even as broken utf-8.
Comments? This is still a major nuisance.
See also bug #721632, bug #699839 and bug #727777. The file loading and saving is in the process of being moved to GtkSourceView, when it is done (and gedit ported), then the implementation can be improved.
I'm now running gedit 3.14. Is that new enough to complain about GtkSourceView instead? :)
Detecting that a file is a binary file can be a bit tricky. But if bug #727777 is fixed (which would also be really useful), it'll detect binary files as well, since binary files generally don't contain a lot of \n or \r.
Sounds like bug 727777 would still load and display the file. The problem is that loading takes a _really_ long time. That's what need to be fixed. Not how the file is displayed once loaded. And yes, detecting it can be tricky. But \0:s are generally not present in text files, besides the larger unicode encodings. It should be possible to write a heuristic for this. Any corner cases could be handled by an info bar that can resume the loading.
Yes, counting the number of \0 should probably give good results. But normally the file loading is asynchronous, so it's strange that it freezes gedit. It should at least be possible to close the file while it is loading.
It wedges itself completely. At least for me. Not something you can reproduce?
I can reproduce the gedit freeze. I said it's strange because the code was supposed to load the file asynchronously. But I guess some parts of the code run synchronously in the main thread, which for a normal file is fine but not for a binary file.
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.