From: Thomas Rast <trast@student.ethz.ch>
To: Thomas Rast <trast@student.ethz.ch>
Cc: "Stefan Zager" <szager@google.com>,
git@vger.kernel.org, "Jeff King" <peff@peff.net>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>
Subject: Re: regression in multi-threaded git-pack-index
Date: Tue, 19 Mar 2013 16:45:55 +0100 [thread overview]
Message-ID: <87620n4clo.fsf@pctrast.inf.ethz.ch> (raw)
In-Reply-To: <87hak74cse.fsf@pctrast.inf.ethz.ch> (Thomas Rast's message of "Tue, 19 Mar 2013 16:41:53 +0100")
Thomas Rast <trast@student.ethz.ch> writes:
> (gdb) r index-pack --keep --stdin -v --pack_header=2,50757 <borked
> Starting program: /Users/trast/.local/bin/git index-pack --keep
> --stdin -v --pack_header=2,50757 <borked
> Reading symbols for shared libraries +++........................ done
> Receiving objects: 100% (50757/50757), 24.52 MiB | 13.06 MiB/s, done.
> Resolving deltas: 25% (10568/42272)
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x000000014484dfe8
> [Switching to process 96573 thread 0x10f]
> 0x000000010017ee20 in use_pack (p=0x100500f30, w_cursor=0x14484e1a0,
> offset=69638148, left=0x0) at sha1_file.c:866
> 866 if (!win || !in_window(win, offset)) {
>
> This seems to be a SIGBUS triggered by stack overflow, largely based on
> the observation that
>
> (gdb) p &p
> $6 = (struct packed_git **) 0x144748058
Actually, scratch that; the stack depth is the same no matter what
ulimits I put (up to 64MB). Roughly speaking
(gdb) bt 10
#0 0x000000010017ee20 in use_pack (p=0x100500f30, w_cursor=0x14484e1a0, offset=69638148, left=0x0) at sha1_file.c:866
#1 0x000000010018180c in get_delta_base (p=0x100500f30, w_curs=0x14484e1a0, curpos=0x14484e138, type=OBJ_OFS_DELTA, delta_obj_offset=69638146) at sha1_file.c:1609
#2 0x00000001001819e6 in packed_delta_info (p=0x100500f30, w_curs=0x14484e1a0, curpos=69638148, type=OBJ_OFS_DELTA, obj_offset=69638146, sizep=0x0) at sha1_file.c:1655
#3 0x0000000100181c97 in packed_object_info (p=0x100500f30, obj_offset=69638146, sizep=0x0, rtype=0x0) at sha1_file.c:1727
#4 0x0000000100181a25 in packed_delta_info (p=0x100500f30, w_curs=0x14484e2a0, curpos=69638193, type=OBJ_OFS_DELTA, obj_offset=69638190, sizep=0x0) at sha1_file.c:1658
#5 0x0000000100181c97 in packed_object_info (p=0x100500f30, obj_offset=69638190, sizep=0x0, rtype=0x0) at sha1_file.c:1727
#6 0x0000000100181a25 in packed_delta_info (p=0x100500f30, w_curs=0x14484e3a0, curpos=69638240, type=OBJ_OFS_DELTA, obj_offset=69638237, sizep=0x0) at sha1_file.c:1658
#7 0x0000000100181c97 in packed_object_info (p=0x100500f30, obj_offset=69638237, sizep=0x0, rtype=0x0) at sha1_file.c:1727
#8 0x0000000100181a25 in packed_delta_info (p=0x100500f30, w_curs=0x14484e4a0, curpos=69638285, type=OBJ_OFS_DELTA, obj_offset=69638282, sizep=0x0) at sha1_file.c:1658
#9 0x0000000100181c97 in packed_object_info (p=0x100500f30, obj_offset=69638282, sizep=0x0, rtype=0x0) at sha1_file.c:1727
(More stack frames follow...)
(gdb) bt -10
#4088 0x00000001001835f9 in sha1_object_info_extended (sha1=0x1011b0900 "D=L\022eO����}�r\fW\036F�Q\\Q;t�8", oi=0x1448cdc50) at sha1_file.c:2264
#4089 0x00000001001836eb in sha1_object_info (sha1=0x1011b0900 "D=L\022eO����}�r\fW\036F�Q\\Q;t�8", sizep=0x1448cdd28) at sha1_file.c:2286
#4090 0x0000000100053c44 in sha1_object (data=0x146002400, obj_entry=0x0, size=1992, type=OBJ_TREE, sha1=0x1011b0900 "D=L\022eO����}�r\fW\036F�Q\\Q;t�8") at index-pack.c:722
#4091 0x000000010005457f in resolve_delta (delta_obj=0x1011b0900, base=0x144e00000, result=0x144e00040) at index-pack.c:866
#4092 0x00000001000548b6 in find_unresolved_deltas_1 (base=0x144e00000, prev_base=0x0) at index-pack.c:914
#4093 0x0000000100054947 in find_unresolved_deltas (base=0x144e00000) at index-pack.c:930
#4094 0x0000000100054a79 in resolve_base (obj=0x1011b08c0) at index-pack.c:961
#4095 0x0000000100054ba5 in threaded_second_pass (data=0x100537dd0) at index-pack.c:984
#4096 0x00007fff8ec8b8bf in _pthread_start ()
#4097 0x00007fff8ec8eb75 in thread_start ()
That leaves me stumped as to the cause of that SIGBUS, however.
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2013-03-19 15:46 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 22:42 regression in multi-threaded git-pack-index Stefan Zager
2013-03-16 11:41 ` Jeff King
2013-03-16 12:38 ` Duy Nguyen
2013-03-19 8:17 ` Thomas Rast
2013-03-19 9:30 ` Jeff King
2013-03-19 9:59 ` Jeff King
2013-03-19 10:08 ` Jeff King
2013-03-19 10:24 ` Jeff King
2013-03-19 10:29 ` Thomas Rast
2013-03-19 10:33 ` Jeff King
2013-03-19 10:45 ` Thomas Rast
2013-03-19 10:47 ` Jeff King
2013-03-19 10:58 ` [PATCH] index-pack: always zero-initialize object_entry list Jeff King
2013-03-19 15:33 ` Thomas Rast
2013-03-19 15:43 ` Jeff King
2013-03-19 15:52 ` Jeff King
2013-03-19 16:17 ` [PATCH v2] " Jeff King
2013-03-19 16:27 ` Thomas Rast
2013-03-19 17:13 ` Junio C Hamano
2013-03-20 19:12 ` Eric Sunshine
2013-03-20 19:13 ` Jeff King
2013-03-20 19:14 ` Eric Sunshine
2013-03-19 12:35 ` regression in multi-threaded git-pack-index Duy Nguyen
2013-03-19 13:01 ` [PATCH] index-pack: protect deepest_delta in multithread code Nguyễn Thái Ngọc Duy
2013-03-19 13:25 ` Jeff King
2013-03-19 13:50 ` Thomas Rast
2013-03-19 14:07 ` Duy Nguyen
2013-03-19 14:16 ` [PATCH v2] index-pack: guard nr_resolved_deltas reads by lock Thomas Rast
2013-03-19 15:53 ` Junio C Hamano
2013-03-19 15:41 ` regression in multi-threaded git-pack-index Thomas Rast
2013-03-19 15:45 ` Thomas Rast [this message]
2013-03-19 16:11 ` Thomas Rast
2013-03-19 17:58 ` Junio C Hamano
2013-03-19 22:08 ` [PATCH] sha1_file: remove recursion in packed_object_info Thomas Rast
2013-03-20 16:47 ` Junio C Hamano
2013-03-25 9:27 ` thomas
2013-03-25 18:07 ` [PATCH v2 0/3] Recursion-free unpack_entry and packed_object_info Thomas Rast
2013-03-25 18:07 ` [PATCH v2 1/3] sha1_file: remove recursion in packed_object_info Thomas Rast
2013-03-25 18:07 ` [PATCH v2 2/3] Refactor parts of in_delta_base_cache/cache_or_unpack_entry Thomas Rast
2013-03-25 23:15 ` Junio C Hamano
2013-03-26 11:09 ` thomas
2013-03-25 18:07 ` [PATCH v2 3/3] sha1_file: remove recursion in unpack_entry Thomas Rast
2013-03-25 23:19 ` Junio C Hamano
2013-03-26 3:37 ` [PATCH v2 0/3] Recursion-free unpack_entry and packed_object_info Nicolas Pitre
2013-03-25 18:17 ` [PATCH] sha1_file: remove recursion in packed_object_info Junio C Hamano
2013-03-27 20:03 ` [PATCH v3 0/3] Recursion-free unpack_entry and packed_object_info Thomas Rast
2013-03-27 20:03 ` [PATCH v3 1/3] sha1_file: remove recursion in packed_object_info Thomas Rast
2013-03-27 20:03 ` [PATCH v3 2/3] Refactor parts of in_delta_base_cache/cache_or_unpack_entry Thomas Rast
2013-03-27 20:03 ` [PATCH v3 3/3] sha1_file: remove recursion in unpack_entry Thomas Rast
2013-03-27 20:29 ` Junio C Hamano
2013-03-20 1:17 ` regression in multi-threaded git-pack-index Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87620n4clo.fsf@pctrast.inf.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=szager@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).