I also am affected by this bug with a practically identical backtrace to the segmentation fault on opening a repository.

Created attachment 307983 [details]
Backtrace of crash

Is any of your repositories that you are able to reproduce this on available publicly? If not, it would be great if you could install debug symbols for gitg (or compile with debug symbols from source) so that we can obtain a better stack trace.

This happens on private work repo, so I can't share that.

I built gitg-3.16.1 (via AUR on Arch) and disabled stripping the build. I hope this helps.

+ Trace 235313

(gdb) p newindex 
$1 = 0
(gdb) p lane.from.date
Cannot access memory at address 0x28

This might be more relevant.

(gdb) p lane
$1 = (GitgLane *) 0x0

Cool, this helps. But would still need a repro repo to investigate this. Since this issue should only rely on the particular parent structure of your repo, could you maybe try the following to recreate a repo with the same commit hierarchy, but without any sensitive data and attach it to the issue.

IMPORTANT!!!!: doing the following will completely destroy your local copy of the original repo, so please do this on a throwaway COPY ONLY at your own risk!!!



BRANCH=master

# Rewrite history of $BRANCH to remove all content and author/committer information
git filter-branch --index-filter 'git rm --cached -r -q *' --commit-filter 'GIT_AUTHOR_NAME="Author"; GIT_AUTHOR_EMAIL="author@test.org"; GIT_COMMITTER_NAME="Committer"; GIT_COMMITTER_EMAIL="committer@test.org"; git commit-tree "$@" -m "Test commit"' $BRANCH

# Remove the backup
git update-ref -d refs/original/refs/heads/master

# Remove all remotes
for remote in $(git remote)
do
    git remote remove "$remote";
done

# Remove all branches and tags
for ref in $(git for-each-ref refs/heads refs/tags --format='%(refname)')
do
    [ "$ref" != "refs/heads/$BRANCH" ] && git update-ref -d "$ref"
done

# Remove all logs
rm -rf .git/logs

# Remove all hooks
rm -rf .git/hooks/*

# Prune the repository
git gc --force --aggressive --prune=all




If the crash happens when viewing a different branch in gitg, please replace master with that branch. Also, please verify if the crash still happens on the rewritten repo.

To verify that your rewritten repo doesn't contain any commits that were missed:


find .git/objects/pack -name 'pack-*.idx' | while read p ; do     git show-index < $p | cut -f 2 -d ' '; done | xargs git show


This should only show empty rewritten commits without any sensitive data. Please check .git/config for sensitive data manually before attaching the repo here.

I tried the above script and it leaves me with content in my repo in form of diffable items (e.g git diff master^1) and large packfile in .git/objects/ directory. Any way to scrub those?

Not sure what happened without having more info. Did the script perform all the steps successfully? I tried this on a repo of mine (https://github.com/jessevdk/go-flags) and it seemed to work as expected.

Ok, not sure what I did different but re-ran the commands and I *do* have a repro that occurs at gitg shutdown (used to happen at startup).

However, there's a large pack file within .git/objects/ (~1.2 G) and leftover stuff on disk in .git {/refs/heads/,ref/remotes). Any way to clear those out before I send over?

Also, would it be acceptable to send to your email address rather than as attachment to a world viewable ticket (for privacy reasons).

That doesn't sound right, I just ran this on gitg and in the end I don't have any branches other than master, no remotes, and I have a pack file of 100kb. I guess the script isn't working for you as intended, but without more information I don't know what could be going wrong. If the history rewriting worked, then maybe you can try to just do some manual steps to clean up (check if you still have remotes and remove them, check if you still have branches and remove them, run git gc --aggressive --prune=all) and see if that helps. If you manage, sending it by e-mail is fine by me.

I was able to trim the extra pack content (using the BFG tool) and manually removed branches. 

It's still large (~13MB), and this appears to be all metadata AFAICT. I've sent this to your gmail account.

The crash occurs reliably for me by opening gitg in this repo, waiting a couple secs, and exiting the gitg applications.

I managed to locate and fix the issue of crashing on closing, but I'm not sure it also fixes your original issue. Are you able to build gitg from git? If so, could you please try with latest master and see if the problem is fixed?

I tried to build gitg from master, but getting stuck in make of gitg.

I was able to build libgit2-glib and libgit2 to match the version requirements (with some minor pkg-config override) and by running g-ir-scanner command manually.

I'm not familiar with codebase or vala to continue further. If you want to throw over a statically built version, I could give that a try.

Here's a snippet of build failure in gitg. I'm assuming this had something to do with g-ir-scanner output (goject introspection?) stuff.

libgitg/gitg-stage-status-enumerator.vala:240.4-240.35: error: The name `snapshot' does not exist in the context of `Ggit.Config'
			repository.get_config().snapshot().match_foreach(s_ignore_regex, (match, val) => {
			^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libgitg/gitg-stage-status-enumerator.vala:151.14-151.44: error: The name `get_submodule_status' does not exist in the context of `Ggit.Repository'
			d_flags = repository.get_submodule_status(submodule.get_name(),
			          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

This means you don't have the correct version of libgit2-glib. For current master of gitg, you also need current master of libgit2-glib.

Jesse,

I took another look at compiling gitg from master and hit the same issues. I checked out libgit2 and libgit2-glib from git repo (master branch). I got them to compile, but still getting stuck at the valac step for gitg itself. 

I can't seem to point it to my compiled copies. It seems to try to use system libs, even though I used the PKG_CONFIG_PATH to override to my lib build locations.

PKG_CONFIG_PATH=../../libgit2/lib/pkgconfig/:../../libgit2-glib/lib/pkgconfig/:$PKG_CONFIG_PATH  ./configure  --prefix=/home/pedrum/src/gitg.master


/usr/bin/valac --pkg ggit-1.0 --pkg gtk+-3.0 --pkg gio-2.0 --pkg libsoup-2.4 --pkg webkit2gtk-4.0 --pkg gee-0.8 --pkg json-glib-1.0 --pkg libsecret-1 --pkg gio-unix-2.0 --pkg gitg-js-utils --pkg gdesktop-enums-3.0 --target-glib 2.38 -g --vapidir ./vapi --includedir libgitg --basedir . --gir Gitg_in-1.0.gir --vapi libgitg/libgitg-1.0.vapi --library libgitg/libgitg-1.0 --header libgitg/libgitg.h --gresources "./libgitg/resources/resources.xml"  -C libgitg/gitg-assembly-info.vala libgitg/gitg-async.vala libgitg/gitg-authentication-dialog.vala libgitg/gitg-avatar-cache.vala libgitg/gitg-branch-base.vala libgitg/gitg-branch.vala libgitg/gitg-cell-renderer-lanes.vala libgitg/gitg-color.vala libgitg/gitg-commit-list-view.vala libgitg/gitg-commit-model.vala libgitg/gitg-commit.vala libgitg/gitg-credentials-manager.vala libgitg/gitg-date.vala libgitg/gitg-diff-stat.vala libgitg/gitg-diff-view-options.vala libgitg/gitg-diff-view-request-diff.vala libgitg/gitg-diff-view-request-icon.vala libgitg/gitg-diff-view-request-resource.vala libgitg/gitg-diff-view-request.vala libgitg/gitg-diff-view.vala libgitg/gitg-hook.vala libgitg/gitg-init.vala libgitg/gitg-label-renderer.vala libgitg/gitg-lane.vala libgitg/gitg-lanes.vala libgitg/gitg-progress-bin.vala libgitg/gitg-ref-base.vala libgitg/gitg-ref.vala libgitg/gitg-remote.vala libgitg/gitg-remote-notification.vala libgitg/gitg-repository-list-box.vala libgitg/gitg-repository.vala libgitg/gitg-sidebar.vala libgitg/gitg-stage-status-enumerator.vala libgitg/gitg-stage.vala libgitg/gitg-utils.vala libgitg/gitg-when-mapped.vala
mv -f libgitg_libgitg_1_0_la_vala.stamp-t libgitg_libgitg_1_0_la_vala.stamp
make[3]: Leaving directory '/home/pedrum/src/gitg.master/src/gitg.git'

...

  VALAC    libgitg_libgitg_1_0_la_vala.stamp
libgitg/gitg-stage-status-enumerator.vala:240.4-240.35: error: The name `snapshot' does not exist in the context of `Ggit.Config'
			repository.get_config().snapshot().match_foreach(s_ignore_regex, (match, val) => {
			^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libgitg/gitg-stage-status-enumerator.vala:151.14-151.44: error: The name `get_submodule_status' does not exist in the context of `Ggit.Repository'
			d_flags = repository.get_submodule_status(submodule.get_name(),


Here's the paths to the master builds of those two libs... 

PKG_CONFIG_PATH=../../libgit2/lib/pkgconfig/:../../libgit2-glib/lib/pkgconfig/:$PKG_CONFIG_PATH  pkg-config --libs libgit2

-L/home/pedrum/src/gitg.master/libgit2/lib -lgit2 

PKG_CONFIG_PATH=../../libgit2/lib/pkgconfig/:../../libgit2-glib/lib/pkgconfig/:$PKG_CONFIG_PATH  pkg-config --libs libgit2-glib-1.0

-L/home/pedrum/src/gitg.master/libgit2/lib -L/home/pedrum/src/gitg.master/libgit2-glib/lib -lgit2-glib-1.0 -lgit2 -lgio-2.0 -lgirepository-1.0 -lgobject-2.0 -lglib-2.0

I am having exactly the same issue on my Arch linux based system since last few versions for gitg. Right now I am using gitg 3.17.1.

I can't share my repository but I think it happens when you create branches from old revisions do some rebase and merge on another branches and then try to switch to a different branch from gitg ui (just click on a branch in branches list) causing segfault.

I'll try to prepare a sample repository.

I also have branches (not master) in one repository that crashes on gitg_lanes_next.

I made gitg not to crash by changing .git/config 

from

(...)
[gitg]
        mainline = refs/heads/master

to

(...)
[gitg]
        mainline = ""


I can't send a repo now because I don't know how to get rid of sensitive data without deleting refs/heads/master (I used script similair to one in Comment 6).

I could finally reproduce this, thanks everyone for helping to track this down. I pushed a fix on both master and gnome-3-18 and it should be fixed in the next release. Until then, please use the workaround from donny.

Donny's workaround doesn't solve the issue for me. It's still crashing, waiting for the official fix.

BTW, you can test with this repository:

 $ git clone https://github.com/twbs/bootstrap.git
 $ cd bootstrap
 $ gitg

and select `Remotes -> Origin -> v4-dev` branch.

Testing on arch linux, gitg 3.17.1.

I'm no longer seeing this issue with gitg 3.20.0.