Thomas Rast <tr...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
