GNOME Bugzilla – Bug 768650
gitg 3.20 becomes non-responsive when working with binaries
Last modified: 2016-08-17 18:11:08 UTC
I've got gitg-3.20.1-1.fc24.x86_64 (latest Fedora 24), which crashes The symptom: the GUI of gitg stops responding and 'top' shows gitg taking 100% CPU. Preconditions: Install git-2.7.4-1.fc24.x86_64 and gitg-3.20.1-1.fc24.x86_64 on Fedora 24 Steps to reproduce: 1. Open a terminal and create a new git repo: mkdir -p ~/aaa cd ~/aaa git init 2. Start gitg and add the newly created repo to gitg 3. Start a file manager and copy a bunch of pdf files to the new repo 4. Go to gitg's commit view 5. Click on one of the pdfs Expected results: The pdf gets selected, and I can stage it. Actual results: gitg freezes up, consumes 100% CPU and starts eating all system memory as well. Other: If you can't reproduce this issue, I can share the exact pdf files that I used for the above test.
I can't seem to reproduce this. It's possible that this issue has already been fixed on master. Could you try building master and seeing if the problem still persists? Sharing the pdf would help as well, so I can try to reproduce under the same conditions.
I can reproduce it with latest master. (It can also segfault after a few tries.) The pdf I use is this: http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf And here is what I could gather from gdb about the segfault: http://pastebin.com/uMfEQj0V
The crash seems due to the large size and the way we use GtkTextView in a non-native scrollable manner. The solution for this seems non-trivial, so would take some time. In the mean time: 1. To avoid crashing, you can use .gitattributes to mark *.pdf as binary. gitg should pick this up 2. We can implement a stop-gap solution by looking at the file contents, guessing the content type and always marking pdf (and possible some other common known-to-be-not-really-text) as binary
I'd suggest to simply disable the GtkTextView for any large file. (Maybe add a button to load it anyway if someone really has big code files.)
Okay, so I added a '.gitattributes' file with the following content: *.pdf -diff Now I start gitg, go to the 'aaa' repo, double-click '.gitattributes' to stage it, but when I try to commit, it tells me there are no changes to be committed. Going to that folder in the terminal and running 'git status' tells me that the file is in fact not staged. I guess I should open a new bug report for that.
As a workaround: when I create the '.gitattributes' file and commit it using the command line, gitg no longer tries to show a diff to the pdf files, just an empty white area with a zero. (In this scenario, I would suggest to be a little more user friendly and display a message like git's "binary file differs" or something similar.)
Pushed some improvements for detecting PDF as binary and also better display message for viewing binary files in the diff.
Latest git master of gitg (built using jhbuild a few minutes ago) crashes when I try to select the repo used for the previous tests. Here is the results of running it with gdb: https://paste.fedoraproject.org/409594/38404147/ The relevant line is: ** (gitg:23363): CRITICAL **: gitg_diff_view_file_info_construct: assertion 'repository != NULL' failed According to gdb, the problem originates from:
+ Trace 236548
Hmm, this doesn't happen to me. I'd like to understand what is going on exactly that triggers this. This crash happens directly when you open gitg with your project?
Nm, managed to repro. I'm on it.
Fixes crash where repository is not properly set
Should be fixed on master
Thank you Jesse for your efforts. It works wonderfully now.