Re: regression in multi-threaded git-pack-index

From: Thomas Rast <trast@student.ethz.ch>
Date: Mar 19, 2013, 15:45 UTC
Message-ID: <87620n4clo.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <87hak74cse.fsf@pctrast.inf.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 18 quoted lines

>   (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