Hi all,
I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4. When I tried
to run `git-p4 rebase', it failed with a broken pipe to
`git-fast-import'. I gather the following from GDB. I am kind of
stuck. Does anyone have any idea what's going on?
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
701 off_t win_off = win->offset;
(gdb) bt
#0 in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
#1 0x0000a7b0 in use_pack (p=0x500740, w_cursor=0xbfffd328,
offset=3501, left=0xbfffd2c8) at sha1_file.c:728
#2 0x0000aaa0 in unpack_object_header (p=0x64617461, w_curs=0x0,
curpos=0xbfffd330, sizep=0xbffff4ec) at sha1_file.c:1329
#3 0x0000e17c in unpack_entry (p=0x500740, obj_offset=3501,
type=0xbffff4e8, sizep=0xbffff4ec) at sha1_file.c:1591
#4 0x0000dc8c in read_packed_sha1 (sha1=0x64617461 <Address
0x64617461 out of bounds>, type=0xbffff4e8, size=0xbffff4ec) at
sha1_file.c:1811
#5 0x0000dd90 in read_sha1_file (sha1=0xbffff4f0
")S??=?P\r?6[?w?S[\021\004??", type=0xbffff4e8, size=0xbffff4ec) at
sha1_file.c:1877
#6 0x0000e020 in read_object_with_reference (sha1=0x100950b
")S??=?P\r?6[?w?S[\021\004??", required_type_name=0x0,
size=0xbffff578, actual_sha1_return=0x100950b
")S??=?P\r?6[?w?S[\021\004??") at sha1_file.c:1906
#7 0x0000450c in cmd_from_existing (b=0x10094c0) at fast-import.c:1922
#8 0x00004b3c in cmd_from (b=0x10094c0) at fast-import.c:1965
#9 0x000078a0 in cmd_new_commit () at fast-import.c:2044
#10 0x000088f0 in main (argc=213252, argv=0xbffff838) at fast-import.c:2329
(gdb) print win
$1 = (struct pack_window *) 0x5004d0
(gdb) print *win
$2 = {
next = 0x64617461,
base = 0x20333936 <Address 0x20333936 out of bounds>,
offset = 22523564414626158,
len = 1685026675,
last_used = 795894075,
inuse_cnt = 0
}
Regards,
Kevin Leung
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:41
Shun Kei Leung [off-list ref] wrote:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
701 off_t win_off = win->offset;
...
(gdb) print win
$1 = (struct pack_window *) 0x5004d0
(gdb) print *win
$2 = {
next = 0x64617461,
base = 0x20333936 <Address 0x20333936 out of bounds>,
offset = 22523564414626158,
len = 1685026675,
last_used = 795894075,
inuse_cnt = 0
}
Wow. There's no way that struct pack_window is valid anymore.
The base isn't a valid address. The offset cannot possibly be
correct (you don't have that big of a packfile, do you?!
What does `git count-objects -v` give you? I'm specifically
interested in how many packfiles you have. The other thing that
may be interesting to see is the value of pack_open_windows and
peak_pack_open_windows (file scope in sha1_file.c).
Then again, maybe that isn't interesting. This looks like it is
memory corruption (e.g. someone overwriting a free'd segment),
but that sort of memory corruption is very hard to track down.
--
Shawn.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:41
"Shawn O. Pearce" [off-list ref] wrote:
Shun Kei Leung [off-list ref] wrote:
quoted
I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4.
...
quoted
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
...
This looks like it is
memory corruption (e.g. someone overwriting a free'd segment),
but that sort of memory corruption is very hard to track down.
OK, so the version you have (58ba4) is the latest fast-import after
the strbuf.c series went in. The one immediately before that series
was 4bf538 and is probably actually stable.
So I wonder, can you test 4bf538 and then if it is good bisect
between those two commits? There must be a memory corruption
introduced by one of the strbuf changes...
--
Shawn.
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:41
On Sat, Oct 13, 2007 at 03:34:07AM +0000, Shawn O. Pearce wrote:
"Shawn O. Pearce" [off-list ref] wrote:
quoted
Shun Kei Leung [off-list ref] wrote:
quoted
I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4.
....
quoted
quoted
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
....
quoted
This looks like it is
memory corruption (e.g. someone overwriting a free'd segment),
but that sort of memory corruption is very hard to track down.
OK, so the version you have (58ba4) is the latest fast-import after
the strbuf.c series went in. The one immediately before that series
was 4bf538 and is probably actually stable.
So I wonder, can you test 4bf538 and then if it is good bisect
between those two commits? There must be a memory corruption
introduced by one of the strbuf changes...
Gasp, if you get the offending sha1 commit, don't forget to Cc: me.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:41
On sam, oct 13, 2007 at 07:36:40 +0000, Pierre Habouzit wrote:
On Sat, Oct 13, 2007 at 03:34:07AM +0000, Shawn O. Pearce wrote:
quoted
"Shawn O. Pearce" [off-list ref] wrote:
quoted
Shun Kei Leung [off-list ref] wrote:
quoted
I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4.
....
quoted
quoted
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
....
quoted
This looks like it is
memory corruption (e.g. someone overwriting a free'd segment),
but that sort of memory corruption is very hard to track down.
OK, so the version you have (58ba4) is the latest fast-import after
the strbuf.c series went in. The one immediately before that series
was 4bf538 and is probably actually stable.
So I wonder, can you test 4bf538 and then if it is good bisect
between those two commits? There must be a memory corruption
introduced by one of the strbuf changes...
Gasp, if you get the offending sha1 commit, don't forget to Cc: me.
Okay, given that fast-import uses quote_c_style, I believe this is the
same but that the one that was reported already. I've read the full
`git diff 4bf53833dbca666f61b5177977e96d453527db20.. -- fast-import.c`
and nothing alarming shows up.
Please try to apply:
http://git.madism.org/?p=git.git;a=commit;h=7406e83342cd445ac38c1753c5fce75377737e2f
And see if that fixes the issue for you. Else a bisection would be
much appreciated. Thanks.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:41
Hi,
On Fri, 12 Oct 2007, Shawn O. Pearce wrote:
Shun Kei Leung [off-list ref] wrote:
quoted
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
701 off_t win_off = win->offset;
...
quoted
(gdb) print win
$1 = (struct pack_window *) 0x5004d0
(gdb) print *win
$2 = {
next = 0x64617461,
base = 0x20333936 <Address 0x20333936 out of bounds>,
offset = 22523564414626158,
len = 1685026675,
last_used = 795894075,
inuse_cnt = 0
}
Wow. There's no way that struct pack_window is valid anymore.
[...]
This looks like it is memory corruption (e.g. someone overwriting a
free'd segment), but that sort of memory corruption is very hard to
track down.
I found valgrind invaluable to find such errors.
Ciao,
Dscho
Hi,
Sorry for the late reply. I was away from my computer in the weekend.
Hi Pierre,
I didn't try:
http://git.madism.org/?p=git.git;a=commit;h=7406e83342cd445ac38c1753c5fce75377737e2f
because the bad commit turns out to be b449f4c according to `git bisect'.
Hi Shawn,
I include the output of `git count-objects -v' for your information:
count: 104
size: 552
in-pack: 10652
packs: 12
prune-packable: 0
garbage: 0
Regards,
Kevin Leung
I don't get the reason for your "because" but so be it. The commit you
show is not obviously broken to me, especially not in fast-import.c, so
I'll need more input. Could you please run your test in valgrind and
report the output please? Or if the data to reproduce the bug are online
or shareable, it'd be great to share, so that I can reproduce the issue
here.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
I don't get the reason for your "because" but so be it.
Well, my reasoning was that the commit didn't touch the convert.c. But
after re-reading the patch, I think I should apply and test with the
patch again.
...
Or if the data to reproduce the bug are online
or shareable, it'd be great to share, so that I can reproduce the issue
here.
The repository is private, and it is in maintenance mode for the rest
of today. I will get back to you tomorrow with updates.
Thanks & regards,
Kevin Leung
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:41
On Tue, Oct 16, 2007 at 07:13:31AM +0000, Shun Kei Leung wrote:
Hi Pierre,
I have tested with your patch applied, and it still crashed badly.
okay
I compiled the b449f4c version and I got a different backtrace from
GDB. I am still not sure about how the error occurs. I attached the
memory usage from various command line tools.
I believe you should rather test master as any of the strbuf stages is
broken for you, and that there has been some issues with strbuf fixed
lately (not only the patch I asked you to try, but also an issue with
empty strubufs, and you _need_ that patch).
GDB output
===========
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x756c7463
0x90018d0c in szone_realloc ()
(gdb) bt
#0 0x90018d0c in szone_realloc ()
#1 0x90018898 in realloc ()
#2 0x0001f8c8 in strbuf_grow (sb=0x75ef8, extra=0) at git-compat-util.h:223
#3 0x0001fc14 in read_line (sb=0x75ef8, fp=0xa0001b9c, term=10) at strbuf.c:107
#4 0x00002da8 in read_next_command () at fast-import.c:1599
#5 0x0000742c in cmd_new_commit () at fast-import.c:2118
#6 0x00007e80 in main (argc=1, argv=0xbffff828) at fast-import.c:2390
(gdb) frame 3
#3 0x0001fc14 in read_line (sb=0x75ef8, fp=0xa0001b9c, term=10) at strbuf.c:107
107 strbuf_grow(sb, 1);
(gdb) print *sb
$1 = {
alloc = 60,
len = 23,
eof = 0,
buf = 0x5020b0 "D windows/packages/cdc/ces/adm"
}
(gdb) frame 2
#2 0x0001f8c8 in strbuf_grow (sb=0x75ef8, extra=0) at git-compat-util.h:223
223 void *ret = realloc(ptr, size);
(gdb) print (char *) ptr
$2 = 0x5020b0 "D windows/packages/cdc/ces/adm"
(gdb) print (char *)ret
$3 = 0xd <Address 0xd out of bounds>
This does not make sense, ptr should be either valid or NULL.
The output of `leaks'
=================
Process 27075: 88 nodes malloced for 2335 KB
Process 27075: 6 leaks for 624 total leaked bytes.
Leak: 0x005012b0 size=208 string 'EOT'
Leak: 0x00501e60 size=128 string 'EOT'
Leak: 0x00501c80 size=128 string 'EOT'
Leak: 0x00500f10 size=64 string 'EOT'
Leak: 0x00501fa0 size=64 string 'EOT'
Leak: 0x00501f60 size=32
0x00000000 0x02008000 0x00000000 0x01000000 ................
0x02000000 0x0000001a 0x00000000 0x00000000 ................
What I _really_ need is that you run your test into valgrind (the easy
way is to rename git-fast-import into git-fast-import.bin, and make
git-fast-import be a shell-script doing:
exec valgrind --log-file /tmp/git-fast-import git-fast-import "$@"
and please send to me the /tmp/git-fast-import.<pid> from the one that
crashes.
And please do that on the most recent tip of master so that you have a
(at least believe to be) full and sane strbuf series. Thanks.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
What I _really_ need is that you run your test into valgrind (the easy
way is to rename git-fast-import into git-fast-import.bin, and make
git-fast-import be a shell-script doing:
...
valgrind is not yet ported to Mac OS X, sadly enough.
Regards,
Kevin Leung
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:41
On Tue, Oct 16, 2007 at 08:01:18AM +0000, Shun Kei Leung wrote:
quoted
What I _really_ need is that you run your test into valgrind (the easy
way is to rename git-fast-import into git-fast-import.bin, and make
git-fast-import be a shell-script doing:
....
valgrind is not yet ported to Mac OS X, sadly enough.
hmmm I see. hmmm isn't there _any_ chance that you can have access to
a linux box to see if that fails in the same conditions ? I mean I
believe qemu (or virtual pc or …) on your macos would be just fine.
But this realloc() that returns 0xd looks fishy. I would be tempted to
think of a stack corruption, but the frame just before still looks
correct so I'm confused. And valgrind is definitely the tool to use for
stack smashing and other memory related corruptions :/
Using gcc -Wstack-protector may also help.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org