Bug 1099919

Summary: [abrt] git: find_unresolved_deltas_1(): git killed by SIGABRT
Product: [Fedora] Fedora Reporter: Erik Duisters <e.duisters1>
Component: gitAssignee: Petr Stodulka <pstodulk>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: chkr, chrisw, jbowes, martin.vgagern, ooprala, pstodulk, tmz, vonsch
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/3066b49c4fb443fcd3ee241589c6775c5d73cdf0
Whiteboard: abrt_hash:266d1ab006180865dc6643ca373b2de56a815416
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-21 15:38:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Erik Duisters 2014-05-21 13:54:22 UTC
Description of problem:
I was executing the following:

git clone https://code.google.com/p/mapsforge/ mapsforge.git

Version-Release number of selected component:
git-1.9.0-1.fc20

Additional info:
reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        git index-pack --stdin -v --fix-thin '--keep=fetch-pack 7123 on fubar01.total4.nl' --check-self-contained-and-connected --pack_header=2,11534
crash_function: find_unresolved_deltas_1
executable:     /usr/libexec/git-core/git
kernel:         3.14.4-200.fc20.i686+PAE
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (4 frames)
 #5 find_unresolved_deltas_1 at builtin/index-pack.c:906
 #6 find_unresolved_deltas at builtin/index-pack.c:936
 #7 resolve_base at builtin/index-pack.c:967
 #8 threaded_second_pass at builtin/index-pack.c:990

Comment 1 Erik Duisters 2014-05-21 13:54:28 UTC
Created attachment 897993 [details]
File: backtrace

Comment 2 Erik Duisters 2014-05-21 13:54:30 UTC
Created attachment 897994 [details]
File: cgroup

Comment 3 Erik Duisters 2014-05-21 13:54:32 UTC
Created attachment 897995 [details]
File: core_backtrace

Comment 4 Erik Duisters 2014-05-21 13:54:34 UTC
Created attachment 897996 [details]
File: dso_list

Comment 5 Erik Duisters 2014-05-21 13:54:36 UTC
Created attachment 897997 [details]
File: environ

Comment 6 Erik Duisters 2014-05-21 13:54:38 UTC
Created attachment 897998 [details]
File: limits

Comment 7 Erik Duisters 2014-05-21 13:54:40 UTC
Created attachment 897999 [details]
File: maps

Comment 8 Erik Duisters 2014-05-21 13:54:42 UTC
Created attachment 898000 [details]
File: open_fds

Comment 9 Erik Duisters 2014-05-21 13:54:44 UTC
Created attachment 898001 [details]
File: proc_pid_status

Comment 10 Erik Duisters 2014-05-21 13:54:46 UTC
Created attachment 898002 [details]
File: var_log_messages

Comment 11 Ondrej Oprala 2014-06-19 14:27:10 UTC
Still an issue in rawhide

Comment 12 Christian Krause 2014-08-19 00:12:31 UTC
Just stumbled over the same issue. Still present in git-1.9.3-1.fc20.x86_64.

Comment 14 Petr Stodulka 2014-12-21 17:03:29 UTC
This is not exactly bug of git. Problem is in repo itself or more precisely it seems that bug is on sending side, code.google.com - see last link of Martin [1]).

May it could be closed as UPSTREAM, because code was modified in upstream due this bug - now it's not aborted on assert(), but it's finished regularly with error message. But repo still can't be cloned and this behaviour is expected.

[1] http://thread.gmane.org/gmane.comp.version-control.git/255606

Comment 15 Petr Stodulka 2014-12-21 17:07:16 UTC
Mentioned contribution from Shawn Pearce:
"""
Thanks. This is a bug in the code.google.com implementation that is
running on Bigtable. I forwarded the report to the team that manages
that service so they can investigate further.
"""