Description of problem: Try to 'git clone http://git.1wt.eu/git/haproxy-1.3.git/' Version-Release number of selected component: git-1.7.11.7-1.fc17 Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 backtrace_rating: 4 cmdline: git-remote-http origin http://git.1wt.eu/git/haproxy-1.3.git/ crash_function: handle_curl_result kernel: 3.6.1-1.fc17.x86_64 truncated backtrace: :Thread no. 1 (10 frames) : #0 handle_curl_result at http.c:751 : #1 http_request at http.c:821 : #2 http_request_reauth at http.c:836 : #3 http_get_strbuf at http.c:844 : #4 http_get_info_packs at http.c:986 : #5 fetch_indices at http-walker.c:385 : #6 fetch_pack at http-walker.c:406 : #7 fetch at http-walker.c:527 : #8 loop at walker.c:176 : #9 walker_fetch at walker.c:287
Created attachment 625829 [details] File: core_backtrace
Created attachment 625830 [details] File: environ
Created attachment 625831 [details] File: limits
Created attachment 625832 [details] File: backtrace
Created attachment 625833 [details] File: cgroup
Created attachment 625834 [details] File: maps
Created attachment 625835 [details] File: dso_list
Created attachment 625836 [details] File: build_ids
Created attachment 625837 [details] File: open_fds
Created attachment 625838 [details] File: var_log_messages
seeing this too. Seems to be a race in | static int http_request(... | run_active_slot(slot); | ret = handle_curl_result(slot); On fast or cached connections, run_active_slot() can download the pack completely, frees 'slot' and starts download of objects immediately by using the allocated 'slot' object. handle_curl_result() expects the original 'slot' and crashes.
Explanation is not correct, but problem is run_active_slot() -> finish_active_slot() -> process_object_response() -> start_object_request() -> start_active_slot() call chain
https://github.com/git/git/commit/88097030725bf68d1801559cfb4785b93a50f5f8 is responsible for the crash (formerly, the 'results' on stack very used, now the 'results' within the slot object which are modified by the call chain above).
I ran the following: $ git clone http://oss.tresys.com/git/refpolicy.git Cloning into 'refpolicy'... It only ran for a second or so with the message above, then crashed. backtrace_rating: 4 Package: git-1.7.11.7-1.fc17 OS Release: Fedora release 17 (Beefy Miracle)
I invoked git pull on a repo that was cloned before the latest git update from a http url. I also tried to clone again, doesn't work either. backtrace_rating: 4 Package: git-1.7.12.1-1.fc18 OS Release: Fedora release 18 (Spherical Cow)
Running the following command caused the problem: git clone http://gnuradio.org/git/gnuradio.git I can replicate the error in a Fedora 17 i686 VM (Virtualbox 4.2.4 r81684) as well as on my native i686 Fedora 17 install. This Fedora Forums post covers the problems I see on my system accurately: git clone http://gnuradio.org/git/gnuradio.git Information from my syslog: Nov 13 09:16:41 blue kernel: [ 5014.537033] git-remote-http[7360]: segfault at 0 ip 0804e783 sp bf9bada0 error 4 in git-remote-http[8045000+9b000] Nov 13 09:16:41 blue abrt[7362]: Saved core dump of pid 7360 (/usr/libexec/git-core/git-remote-http) to /var/spool/abrt/ccpp-2012-11-13-09:16:41-7360 (10207232 bytes) backtrace_rating: 4 Package: git-1.7.11.7-1.fc17 Architecture: i686 OS Release: Fedora release 17 (Beefy Miracle)
The same problem here: git clone http://luajit.org/git/luajit-2.0.git git-1.7.11.7-1.fc17.i686
git-1.7.11.7-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/git-1.7.11.7-2.fc17
Package git-1.7.11.7-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing git-1.7.11.7-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18847/git-1.7.11.7-2.fc17 then log in and leave karma (feedback).
git-1.7.11.7-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.