segfault in diff-delta.c on mac os x (commit 8433669)

843366961cf14aad6490fbeb30f7b98f37f8833a may cause segfaults on
Mac OS X. See backtrace below. I only observed the segfault with
-O2 builds.

I was not yet able to understand the reason causing the segfault.
The situation is kind of strange. The for loop in line 302 shouldn't
allow entry == 0 to ever happen. But maybe some more intricate
corruption is taking place.

Unfortunately I'm no longer able to reproduce the exact call stack
because I wasn't aware of the details of when pruning takes place;
and the repository changed in such a way that the segfault no
longer happens.

However, I experienced suspicious behaviour on other repositories
during packing as well. I can probably create similar call stacks
if needed.

For now, I reverted 843366961cf14aad6490fbeb30f7b98f37f8833a for me.

	Steffen


gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build  
5250)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.


Counting objects: 7530
Done counting 56361 objects.
Deltifying 56361 objects...
   69% (38890/56361) done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00048526 in create_delta (index=0x35d5000, trg_buf=0x35a0000,  
trg_size=214109, delta_size=0xbfffe83c, max_size=104893) at diff- 
delta.c:303
303                                     const unsigned char *ref =  
entry->ptr;
(gdb) bt
#0  0x00048526 in create_delta (index=0x35d5000, trg_buf=0x35a0000,  
trg_size=214109, delta_size=0xbfffe83c, max_size=104893) at diff- 
delta.c:303
#1  0x0002beb7 in prepare_pack (window=10, depth=50) at builtin-pack- 
objects.c:1293
#2  0x0002cd6e in cmd_pack_objects (argc=16, argv=0xbfffef78,  
prefix=0x0) at builtin-pack-objects.c:1709
#3  0x000020c9 in handle_internal_command (argc=16, argv=0xbfffef78,  
envp=0x84) at git.c:324
#4  0x00002669 in main (argc=16, argv=0xbfffef78, envp=0xbfffefbc) at  
git.c:393
(gdb) l
298                             struct index_entry *entry;
299                             val ^= U[data[-RABIN_WINDOW]];
300                             val = ((val << 8) | *data) ^ T[val >>  
RABIN_SHIFT];
301                             i = val & index->hash_mask;
302                             for (entry = index->hash[i]; entry;  
entry = entry->next) {
303                                     const unsigned char *ref =  
entry->ptr;
304                                     const unsigned char *src = data;
305                                     unsigned int ref_size =  
ref_top - ref;
306                                     if (entry->val != val)
307                                             continue;
(gdb) p entry
$1 = (struct index_entry *) 0x0

On Jul 21, 2007, at 11:15 AM, Steffen Prohaska wrote:

843366961cf14aad6490fbeb30f7b98f37f8833a may cause segfaults on
Mac OS X. See backtrace below. I only observed the segfault with
-O2 builds.

I have been using git on my OS X box for quite a while, and that  
commit appears to be nearly two months old.  I have yet to see any  
packing errors in any of my repositories.  (This is with -O2, which  
appears to be the default.)

My gcc reports itself as build 5367 instead of 5250.  Perhaps there  
is a compiler error in an older copy of the DevTools?

Also, did this segfault occur with any publicly available repo or is  
it your own work?

~~ Brian

On Jul 22, 2007, at 5:35 AM, Brian Gernhardt wrote:

On Jul 21, 2007, at 11:15 AM, Steffen Prohaska wrote:

quoted

843366961cf14aad6490fbeb30f7b98f37f8833a may cause segfaults on
Mac OS X. See backtrace below. I only observed the segfault with
-O2 builds.

I have been using git on my OS X box for quite a while, and that  
commit appears to be nearly two months old.  I have yet to see any  
packing errors in any of my repositories.  (This is with -O2, which  
appears to be the default.)

My gcc reports itself as build 5367 instead of 5250.  Perhaps there  
is a compiler error in an older copy of the DevTools?

This seems to be the case. I upgraded the compiler and
tried again. The segfault didn't happen again. Note, this
was not exactly the same situation as before because the
git repository used for testing changed a bit since the
first segfault.

I'll do some more repacking over the day and will report
my observations.

Also, did this segfault occur with any publicly available repo or  
is it your own work?

It occurred on repacking a clone of
git://git.kernel.org/pub/scm/git/git.git.


	Steffen

On Jul 22, 2007, at 10:49 AM, Steffen Prohaska wrote:

On Jul 22, 2007, at 5:35 AM, Brian Gernhardt wrote:

quoted

On Jul 21, 2007, at 11:15 AM, Steffen Prohaska wrote:

quoted

843366961cf14aad6490fbeb30f7b98f37f8833a may cause segfaults on
Mac OS X. See backtrace below. I only observed the segfault with
-O2 builds.

I have been using git on my OS X box for quite a while, and that  
commit appears to be nearly two months old.  I have yet to see any  
packing errors in any of my repositories.  (This is with -O2,  
which appears to be the default.)

My gcc reports itself as build 5367 instead of 5250.  Perhaps  
there is a compiler error in an older copy of the DevTools?

This seems to be the case. I upgraded the compiler and
tried again. The segfault didn't happen again. Note, this
was not exactly the same situation as before because the
git repository used for testing changed a bit since the
first segfault.

I'll do some more repacking over the day and will report
my observations.

I did a lot more testing and am pretty convinced now that
the problem is not present with the newer compiler. Using
build 5367 of gcc seems to creating a working git executable
while build 5250 creates a broken one.

	Steffen