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 667732 - Segmentation fault when swithing to "All branches" in a huge repo
Segmentation fault when swithing to "All branches" in a huge repo
Status: RESOLVED FIXED
Product: gitg
Classification: Applications
Component: gitg
git master
Other All
: Normal normal
: ---
Assigned To: gitg-maint
gitg-maint
Depends on:
Blocks:
 
 
Reported: 2012-01-12 04:49 UTC by niboshi000
Modified: 2015-08-08 11:38 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch (8.60 KB, patch)
2012-01-12 04:50 UTC, niboshi000 		none Details | Review

Description niboshi000 2012-01-12 04:49:04 UTC 
I notice a segfault when switching to "All branches" in my LibreOffice working copy.
It appeared that bitwidth of lane indices (was gint8) was not enough.

I attach a patch which extends them to gint16.
Comment 1 niboshi000 2012-01-12 04:50:02 UTC 
Created attachment 205060 [details] [review]
patch
Comment 2 jessevdk@gmail.com 2012-01-12 09:17:18 UTC 
Review of attachment 205060 [details] [review]:

Patch looks good. I'm just wondering if we should maybe update it to gint32 instead. Ideally I guess I would like to see something which does not limit the number of lanes, but that would require more effort. Note that due to the current use of GINT_TO_POINTER we cannot store more bits (although we could on 64 bits archs).  Could you maybe update the assert to a g_return_if_fail?

::: libgitg/gitg-lanes.c
@@ +408,3 @@
 		if (item->next)
 		{
+			assert(0 <= index && index < g_slist_length(lns));

Please do not use assert. Instead, use g_return_if_fail
Comment 3 Ignacio Casal Quinteiro (nacho) 2012-01-12 09:19:13 UTC 
See also that using g_slist_length is a bad idea here it can produce performance problems.
Comment 4 jessevdk@gmail.com 2013-06-20 07:05:16 UTC 
The new gitg uses a uint (i.e. 32 bits) which should be plenty for now.