Re: git problems
Dmitry, good day.
Wed, Jun 04, 2008 at 11:21:59PM +0400, Chagin Dmitry wrote:
> this problem with git is fixed in version 1.5.5.1,
Yeah, commit 7b7f39eae6ab0bbcc68d3c42a5b23595880e528f
> our port requires updating.
Care to test? The diff from 1.5.5 is below. Ed, Eric, anyone, any
comments? I had tested packaging list -- it seems to be unchanged
since 1.5.5, both for the cases of GUI and GUI-less git. And no
new functionality was brought in, judging by ChangeLog contents
and quick glance over commits.
-
diff -urN ./Makefile ../git/Makefile
--- ./Makefile 2008-06-04 23:52:50.0 +0400
+++ ../git/Makefile 2008-06-04 23:53:38.0 +0400
@@ -6,7 +6,7 @@
#
PORTNAME= git
-PORTVERSION= 1.5.5
+PORTVERSION= 1.5.5.3
CATEGORIES=devel
MASTER_SITES= http://www.kernel.org/pub/software/scm/git/
DISTFILES= ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} \
diff -urN ./distinfo ../git/distinfo
--- ./distinfo 2008-06-04 23:52:50.0 +0400
+++ ../git/distinfo 2008-06-04 23:58:08.0 +0400
@@ -1,6 +1,6 @@
-MD5 (git-1.5.5.tar.bz2) = 09f15f0b0e330986d930746abf6962f4
-SHA256 (git-1.5.5.tar.bz2) =
27483890c598450d7d1b4583e40dd8ec6c8def08c7cec94b20eb7336bb83e65e
-SIZE (git-1.5.5.tar.bz2) = 1673736
-MD5 (git-manpages-1.5.5.tar.bz2) = 62a82276856add1d2b310d1e0b5ad5db
-SHA256 (git-manpages-1.5.5.tar.bz2) =
cc7f16b72a228cafd6bcc41ea09fdc67f4c5d50a0bf4521b80d8ea75127bb802
-SIZE (git-manpages-1.5.5.tar.bz2) = 162609
+SIZE (git-1.5.5.tar.bz2) = 1677113
+MD5 (git-1.5.5.3.tar.bz2) = 022ce5772b900243ef5d289deb7a3667
+SHA256 (git-1.5.5.3.tar.bz2) =
c0a5220e7c80dc791e2077ec238298c2ec30af4d8d0ed6d2fbd7ca808266dfc0
+MD5 (git-manpages-1.5.5.3.tar.bz2) = 374a62ddf37343a5130f3318eab1ce2b
+SHA256 (git-manpages-1.5.5.3.tar.bz2) =
770543b0ca871f72829f810d51f9e4d8b27659cbf4e73534fd09dfb5833f99de
+SIZE (git-manpages-1.5.5.tar.bz2) = 163895
-
Perhaps this topic should now be moved out of -hackers.
--
Eygene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
* Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-Jun-04 11:26:02 -0400, Chuck Robey <[EMAIL PROTECTED]> wrote: > >#3 0x08066467 in unlock_pack () at builtin-fetch.c:56 > >#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 > >#5 0x2843b1aa in exit () from /lib/libc.so.7 > >#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at > >git.c:379 > >#7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12) > >at git.c:414 > > __cxa_finalise() is part of the atexit() processing - the source comments > imply it handles shared object destructors. > > >379 exit(run_command(p, argc, argv)); > >380 } > > > >First I want to comment on that weird line 379, because while it > >might work, it sure seems to me to be a very strange and wasteful way > >to do a fork. > > There's no fork involved. It's just shorthand for: > return_code = run_command(p, argc, argv); > exit(return_code); > By the time exit() is invoked, run_command() has completed. > > > Second, the second argument to handle_internal_command seems to > >have been a argv=0x, which is very obviously a bad string > >pointer > > Note that argv in main is also corrupt. I suspect gdb is confused by > the level of optimisation being done by gcc. > > In a later posting, you indicate that there's a double-free bug. > Possibly unlock_pack() is being registered as a destructor (or > similar) _and_ is being explicitly called. Without studying the > code, the solution is probably to either skip the explicit cleanup > (leaving just the destructor processing) and/or flag freed data (ie > NULL pointers after freeing them). I just solved this on my systems by removing the call to free(). I know, it's awful, but it was good enough for me to live with on short term. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgpMvsLv69Vm5.pgp Description: PGP signature
Re: git problems
On Wed, 4 Jun 2008, Eygene Ryabinkin wrote: hello! has just subscribed this problem with git is fixed in version 1.5.5.1, our port requires updating. -- Have fun! chd ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
Chuck,
Wed, Jun 04, 2008 at 11:26:02AM -0400, Chuck Robey wrote:
[...]
> Looking at the top stack frame (main), that frame and the next are deeply
> involved in inspecting argv 0 thru 2, and since it's full of garbage, that's
> what breaks things. That's NOT malloc, that seems to be either a problem in
> process creation or (I think more likely) a problem in the creation of a
> process's environment, the crt0 stuff. I'm getting out of my depth, here.
Sorry, I had thought about stack smashing, but it isn't it, so I
somewhat guided people to the wrong way (if they were listening to me ;))
The real problem was the doubled call to the transport_unlock_pack()
in the builtin-fetch.c. And the stack frame with __cxa_finalize
was perfectly correct -- as I learned half an hour ago, it is the
function that calls all handlers, registered with atexit().
So, the problem was the following: static function unlock_pack()
in the builtin-fetch.c is the cleanup routine for the static variable
'transport'. And it calls transport_unlock_pack() if the 'transport'
variable isn't NULL. But do_fetch() calls free(transport), so
atexit's unlock_pack() tries to use already freed memory.
The below patch works for me, although I should think about it
once more to see if it handles all cases. Please, try the patch.
--- builtin-fetch.c.orig2008-06-04 22:49:05.0 +0400
+++ builtin-fetch.c 2008-06-04 23:07:51.0 +0400
@@ -598,7 +598,7 @@
int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct remote *remote;
- int i;
+ int i, retval;
static const char **refs = NULL;
int ref_nr = 0;
@@ -654,6 +654,14 @@
signal(SIGINT, unlock_pack_on_signal);
atexit(unlock_pack);
- return do_fetch(transport,
+ retval = do_fetch(transport,
parse_fetch_refspec(ref_nr, refs), ref_nr);
+ /*
+* Set transport to NULL, because its contents are already
+* freed in do_fetch(), so we mustn't deinitialize it in
+* unlock_pack().
+*/
+ transport = NULL;
+
+ return retval;
}
--
Eygene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
On 2008-Jun-04 11:26:02 -0400, Chuck Robey <[EMAIL PROTECTED]> wrote: >#3 0x08066467 in unlock_pack () at builtin-fetch.c:56 >#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 >#5 0x2843b1aa in exit () from /lib/libc.so.7 >#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at >git.c:379 >#7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12) at >git.c:414 __cxa_finalise() is part of the atexit() processing - the source comments imply it handles shared object destructors. >379 exit(run_command(p, argc, argv)); >380 } > >First I want to comment on that weird line 379, because while it >might work, it sure seems to me to be a very strange and wasteful way >to do a fork. There's no fork involved. It's just shorthand for: return_code = run_command(p, argc, argv); exit(return_code); By the time exit() is invoked, run_command() has completed. > Second, the second argument to handle_internal_command seems to >have been a argv=0x, which is very obviously a bad string >pointer Note that argv in main is also corrupt. I suspect gdb is confused by the level of optimisation being done by gcc. In a later posting, you indicate that there's a double-free bug. Possibly unlock_pack() is being registered as a destructor (or similar) _and_ is being explicitly called. Without studying the code, the solution is probably to either skip the explicit cleanup (leaving just the destructor processing) and/or flag freed data (ie NULL pointers after freeing them). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpAvGrQFOumj.pgp Description: PGP signature
Re: git problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
> Chuck,
>
> Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote:
>>> Any possibility of using ElectricFence (devel/ElectricFence)
>>> for chasing memory-related troubles?
>> Now that I have gdb working with me again, I am checking the git-fetch image
>> to
>> see where it got lost. If I must bring a tool such as ElectricFence I, I
>> guess
>> I must, just I'm a bit irritated that the git build has one of those make
>> "improvements" (NOT) that instead of telling you the buid line, just gives
>> you
>> "CC sourcename.c" which for anyone who knows code is just irritating, not any
>> sort of help at all.
>
> No problems, just issue 'make V=1' instead of just 'make' in the
> /devel/git -- it will give you all flags and will eliminate
> the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized
> binary with debug symbols that can be directly traced by gdb with
> all symbols and right (unoptimized, as in the sources) code paths.
>
> For the ElectricFence -- it dumps core just after startup, I don't
> know why. So it is not very much usable now, at least for me.
>
> Thank you.
I think I have it narrowed down to either a problemm in process creation (I
don't believe this one) or, more likely, a problem in managing the crt0 stuff in
managing a process's startup bars. Take a look below and tell me if you agree.
Here's the stack dump:
#0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7
#1 0x28437067 in free () from /lib/libc.so.7
#2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at
transport.c:811
#3 0x08066467 in unlock_pack () at builtin-fetch.c:56
#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7
#5 0x2843b1aa in exit () from /lib/libc.so.7
#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at git.c:379
#7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12
) at git.c:414
and here's the lines from git.c, the loop where handle_internal_command gets
called:
/* Turn "git cmd --help" into "git help cmd" */
370 if (argc > 1 && !strcmp(argv[1], "--help")) {
371 argv[1] = argv[0];
372 argv[0] = cmd = "help";
373 }
374
375 for (i = 0; i < ARRAY_SIZE(commands); i++) {
376 struct cmd_struct *p = commands+i;
377 if (strcmp(p->cmd, cmd))
378 continue;
379 exit(run_command(p, argc, argv));
380 }
First I want to comment on that weird line 379, because while it might work, it
sure seems to me to be a very strange and wasteful way to do a fork. I bet
that's some sort of portability hack. Second, the second argument to
handle_internal_command seems to have been a argv=0x, which is very
obviously a bad string pointer
Looking at the top stack frame (main), that frame and the next are deeply
involved in inspecting argv 0 thru 2, and since it's full of garbage, that's
what breaks things. That's NOT malloc, that seems to be either a problem in
process creation or (I think more likely) a problem in the creation of a
process's environment, the crt0 stuff. I'm getting out of my depth, here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIRrQKz62J6PPcoOkRAnwFAJ9XXb0cy/Rowt+X2uLx1uaYWJdHdACglAe6
dThwRYHJ9f95Qyua/syFsV4=
=yFZR
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, > > Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: >>> Any possibility of using ElectricFence (devel/ElectricFence) >>> for chasing memory-related troubles? >> Now that I have gdb working with me again, I am checking the git-fetch image >> to >> see where it got lost. If I must bring a tool such as ElectricFence I, I >> guess >> I must, just I'm a bit irritated that the git build has one of those make >> "improvements" (NOT) that instead of telling you the buid line, just gives >> you >> "CC sourcename.c" which for anyone who knows code is just irritating, not any >> sort of help at all. > > No problems, just issue 'make V=1' instead of just 'make' in the > /devel/git -- it will give you all flags and will eliminate > the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized > binary with debug symbols that can be directly traced by gdb with > all symbols and right (unoptimized, as in the sources) code paths. > > For the ElectricFence -- it dumps core just after startup, I don't > know why. So it is not very much usable now, at least for me Well, maybe this will be of help (sure does make me want to look more closely at malloc, doesn't it?) #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 (gdb) bt #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 #1 0x28437067 in free () from /lib/libc.so.7 #2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at transport.c:811 #3 0x08066467 in unlock_pack () at builtin-fetch.c:56 #4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 #5 0x2843b1aa in exit () from /lib/libc.so.7 #6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at git.c:379 #7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12 ) at git.c:414 (gdb) Oh, I didn't say this was from a git-fetch.core and a freshly rebuilt image in ports, did I? It is, though. I'm not done here, yet, but maybe your better knowledge of our malloc may help us a bit? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqsvz62J6PPcoOkRAsPfAJ4wlm9W5Z1wCvQsVgwkjBor7BMZ5ACgkTW+ F4ahNZpzhJuD2Uru1vsoMQo= =EXb0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: git problems
Chuck, Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: > > Any possibility of using ElectricFence (devel/ElectricFence) > > for chasing memory-related troubles? > > Now that I have gdb working with me again, I am checking the git-fetch image > to > see where it got lost. If I must bring a tool such as ElectricFence I, I > guess > I must, just I'm a bit irritated that the git build has one of those make > "improvements" (NOT) that instead of telling you the buid line, just gives you > "CC sourcename.c" which for anyone who knows code is just irritating, not any > sort of help at all. No problems, just issue 'make V=1' instead of just 'make' in the /devel/git -- it will give you all flags and will eliminate the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized binary with debug symbols that can be directly traced by gdb with all symbols and right (unoptimized, as in the sources) code paths. For the ElectricFence -- it dumps core just after startup, I don't know why. So it is not very much usable now, at least for me. Thank you. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
> Chuck,
>
> Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
nearby, but it seems to be crash inside free().
>>> Application memory errors in HEAD but not in a RELENG_ branch are
>>> frequently a symptom of an application bug unmasked by malloc(3)
>>> debugging enabled in the development branch but not production
>>> branches. It might not hurt to ramp up debugging on your 6.x install to
>>> see if it starts crashing there was well -- see malloc(3) for details,
>>> you'll want to create an appropriate malloc.conf.
>> I didn't see the email where Ed Schouten commented about seeing my problems
>> of
>> seeing no good stack frames, but Robert, I run only -current here, not
>> RELENG_6,
>> so I can't do the testing you speak of.
>
> There is no need: I had tried this on -STABLE with environment
> variable MALLOC_OPTIONS set to 'J' -- it dumps core. The problem
> seems to be in the git-fetch:
> -
> $ MALLOC_OPTIONS=JA git-fetch --update-head-ok
> Segmentation fault: 11 (core dumped)
> -
> This happens inside git repository of xserver and 100% reproducible
> for my both -CURRENT and -STABLE.
>
>> I would want to see if maybe our gcc on
>> - -current might have been made with a default of emitting no stack frames,
>> which
>> I would guess might have this effect.
>
> The stack seems to be smashed at the second call to
> 'transport_unlock_pack': the argument called 'transport' seems to
> carry the pointer to the area, filled by malloc() with byte 0x5a:
> -
> $ MALLOC_OPTIONS=JA gdb git-fetch
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...
> (gdb) run --update-head-ok
> Starting program: /usr/local/bin/git-fetch --update-head-ok
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x4841de8b in free () from /lib/libc.so.7
> (gdb) bt
> #0 0x4841de8b in free () from /lib/libc.so.7
> #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
> at transport.c:811
> #2 0x08066927 in unlock_pack () at builtin-fetch.c:56
> #3 0x48468fe3 in __cxa_finalize () from /lib/libc.so.7
> #4 0x4842199a in exit () from /lib/libc.so.7
> #5 0x0804b15b in handle_internal_command (argc=2, argv=0x)
> at git.c:379
> #6 0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad
> address.
> ) at git.c:414
> (gdb) fr 1
> #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
> at transport.c:811
> 811 free(transport->pack_lockfile);
> (gdb) print *transport
> $1 = {remote = 0x5a5a5a5a,
> url = 0x5a5a5a5a ,
> data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a,
> get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a,
> disconnect = 0x5a5a5a5a,
> pack_lockfile = 0x5a5a5a5a ,
> verbose = -2}
> (gdb)
> -
> I don't believe that __cxa_finalize should call unlock_pack, so
> stack seems to be smashed somewhere before.
>
>> I guess I could test this, and if it's so, recompile all my libraries to undo
>> that, because I abhor doing things that utterly block any troubleshooting at
>> a
>> minimal savings elsewhere.
>
> You don't need to recompile anything to enable malloc debugging.
> The easiest way is to set MALLOC_OPTIONS to the needed malloc
> flags.
Good, that's what I'd figured on my own. I may be slow as mollasses, but I'm
more than a little stubborn, I will track this down (if no one else beats me to
it). I really need my git to work here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIRqgGz62J6PPcoOkRAs0nAJ0YK0+z9uoUn4Ja97ZG/UECj1OLGgCfffBj
NLCk9xbUINso5d+5QohpefQ=
=slbH
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, good day. > > Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote: >> I am having problems with the git out of ports git-fetch keeps on >> dumping >> core when I try update of xorg (the initial checkout works ok). I'm running >> FreeBSD-current ... does anyone have any idea why this might be? > > What version of Git you're using and what protocol is used for > updating, native git or http? > > Any possibility of using ElectricFence (devel/ElectricFence) > for chasing memory-related troubles? Now that I have gdb working with me again, I am checking the git-fetch image to see where it got lost. If I must bring a tool such as ElectricFence I, I guess I must, just I'm a bit irritated that the git build has one of those make "improvements" (NOT) that instead of telling you the buid line, just gives you "CC sourcename.c" which for anyone who knows code is just irritating, not any sort of help at all. Anyhow, I can do my own testing for a bit now. I can say that I have tried other git archives, and it's the git-fetch that seems to be doing it, not the archive. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqd7z62J6PPcoOkRAg/9AJ9WwjsefME8DKmgIsxgtcAvH5tkIwCgiGrg 72CV1T72i5F4D22LiTY8JOI= =edbu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Watson wrote: > On Tue, 3 Jun 2008, Ed Schouten wrote: > >> * Chuck Robey <[EMAIL PROTECTED]> wrote: >>> I am having problems with the git out of ports git-fetch keeps >>> on dumping core when I try update of xorg (the initial checkout works >>> ok). I'm running FreeBSD-current ... does anyone have any idea why >>> this might be? >>> >>> When I try to do a gdb -c corefile on the resulting core image, all i >>> get is a couple of thousand empty stack frames. Any idea why that >>> might be, also? >> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >> nearby, but it seems to be crash inside free(). > > Application memory errors in HEAD but not in a RELENG_ branch are > frequently a symptom of an application bug unmasked by malloc(3) > debugging enabled in the development branch but not production > branches. It might not hurt to ramp up debugging on your 6.x install to > see if it starts crashing there was well -- see malloc(3) for details, > you'll want to create an appropriate malloc.conf. This is really replying to my own question, because I found what I was missing. I have'nt done any troubleshooting for a long while now (health, down for some years) and the last time I did it, if you had a core file in the same directory as the binary and the sources, gdb would know where to find the symbols on it's own, but it looks like that's changed. Once I explicitly gave the symbols, th8ings began to work ok, so you can stop worrying about my missing stack frames. Now that I have that, I have also the ability to find out where git-fetch died, and I will pretty quickly, that ought to help some. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqVvz62J6PPcoOkRAoKcAJ9c5WFhKf0NkOCgfNFO53jEWpsPUwCdErw4 RY8Ry6WQpgwOKVAPoe+mOUs= =M+hX -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
Chuck,
Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
> >> nearby, but it seems to be crash inside free().
> >
> > Application memory errors in HEAD but not in a RELENG_ branch are
> > frequently a symptom of an application bug unmasked by malloc(3)
> > debugging enabled in the development branch but not production
> > branches. It might not hurt to ramp up debugging on your 6.x install to
> > see if it starts crashing there was well -- see malloc(3) for details,
> > you'll want to create an appropriate malloc.conf.
>
> I didn't see the email where Ed Schouten commented about seeing my problems of
> seeing no good stack frames, but Robert, I run only -current here, not
> RELENG_6,
> so I can't do the testing you speak of.
There is no need: I had tried this on -STABLE with environment
variable MALLOC_OPTIONS set to 'J' -- it dumps core. The problem
seems to be in the git-fetch:
-
$ MALLOC_OPTIONS=JA git-fetch --update-head-ok
Segmentation fault: 11 (core dumped)
-
This happens inside git repository of xserver and 100% reproducible
for my both -CURRENT and -STABLE.
> I would want to see if maybe our gcc on
> - -current might have been made with a default of emitting no stack frames,
> which
> I would guess might have this effect.
The stack seems to be smashed at the second call to
'transport_unlock_pack': the argument called 'transport' seems to
carry the pointer to the area, filled by malloc() with byte 0x5a:
-
$ MALLOC_OPTIONS=JA gdb git-fetch
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) run --update-head-ok
Starting program: /usr/local/bin/git-fetch --update-head-ok
Program received signal SIGSEGV, Segmentation fault.
0x4841de8b in free () from /lib/libc.so.7
(gdb) bt
#0 0x4841de8b in free () from /lib/libc.so.7
#1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
at transport.c:811
#2 0x08066927 in unlock_pack () at builtin-fetch.c:56
#3 0x48468fe3 in __cxa_finalize () from /lib/libc.so.7
#4 0x4842199a in exit () from /lib/libc.so.7
#5 0x0804b15b in handle_internal_command (argc=2, argv=0x)
at git.c:379
#6 0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad
address.
) at git.c:414
(gdb) fr 1
#1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
at transport.c:811
811 free(transport->pack_lockfile);
(gdb) print *transport
$1 = {remote = 0x5a5a5a5a,
url = 0x5a5a5a5a ,
data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a,
get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a,
disconnect = 0x5a5a5a5a,
pack_lockfile = 0x5a5a5a5a ,
verbose = -2}
(gdb)
-
I don't believe that __cxa_finalize should call unlock_pack, so
stack seems to be smashed somewhere before.
> I guess I could test this, and if it's so, recompile all my libraries to undo
> that, because I abhor doing things that utterly block any troubleshooting at a
> minimal savings elsewhere.
You don't need to recompile anything to enable malloc debugging.
The easiest way is to set MALLOC_OPTIONS to the needed malloc
flags.
--
Eygene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Watson wrote: > On Tue, 3 Jun 2008, Ed Schouten wrote: > >> * Chuck Robey <[EMAIL PROTECTED]> wrote: >>> I am having problems with the git out of ports git-fetch keeps >>> on dumping core when I try update of xorg (the initial checkout works >>> ok). I'm running FreeBSD-current ... does anyone have any idea why >>> this might be? >>> >>> When I try to do a gdb -c corefile on the resulting core image, all i >>> get is a couple of thousand empty stack frames. Any idea why that >>> might be, also? >> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >> nearby, but it seems to be crash inside free(). > > Application memory errors in HEAD but not in a RELENG_ branch are > frequently a symptom of an application bug unmasked by malloc(3) > debugging enabled in the development branch but not production > branches. It might not hurt to ramp up debugging on your 6.x install to > see if it starts crashing there was well -- see malloc(3) for details, > you'll want to create an appropriate malloc.conf. I didn't see the email where Ed Schouten commented about seeing my problems of seeing no good stack frames, but Robert, I run only -current here, not RELENG_6, so I can't do the testing you speak of. I would want to see if maybe our gcc on - -current might have been made with a default of emitting no stack frames, which I would guess might have this effect. I guess I could test this, and if it's so, recompile all my libraries to undo that, because I abhor doing things that utterly block any troubleshooting at a minimal savings elsewhere. > > Robert N M Watson > Computer Laboratory > University of Cambridge > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqLnz62J6PPcoOkRAlhFAJsHrHTMVaFCdPcUha+1yaFOYyMxuACfY+ms jZRd8WCy9PFcwYICmg636y4= =4PYv -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
On Tue, 3 Jun 2008, Ed Schouten wrote: * Chuck Robey <[EMAIL PROTECTED]> wrote: I am having problems with the git out of ports git-fetch keeps on dumping core when I try update of xorg (the initial checkout works ok). I'm running FreeBSD-current ... does anyone have any idea why this might be? When I try to do a gdb -c corefile on the resulting core image, all i get is a couple of thousand empty stack frames. Any idea why that might be, also? I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, but it seems to be crash inside free(). Application memory errors in HEAD but not in a RELENG_ branch are frequently a symptom of an application bug unmasked by malloc(3) debugging enabled in the development branch but not production branches. It might not hurt to ramp up debugging on your 6.x install to see if it starts crashing there was well -- see malloc(3) for details, you'll want to create an appropriate malloc.conf. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
Chuck, good day. Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote: > I am having problems with the git out of ports git-fetch keeps on dumping > core when I try update of xorg (the initial checkout works ok). I'm running > FreeBSD-current ... does anyone have any idea why this might be? What version of Git you're using and what protocol is used for updating, native git or http? Any possibility of using ElectricFence (devel/ElectricFence) for chasing memory-related troubles? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ed Schouten wrote: > * Chuck Robey <[EMAIL PROTECTED]> wrote: >> I am having problems with the git out of ports git-fetch keeps on >> dumping >> core when I try update of xorg (the initial checkout works ok). I'm running >> FreeBSD-current ... does anyone have any idea why this might be? >> >> When I try to do a gdb -c corefile on the resulting core image, all i get is >> a >> couple of thousand empty stack frames. Any idea why that might be, also? > > I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, > but it seems to be crash inside free(). > My problem is, I can't even get a backtrace on core files, I get thousands of empty stack frames only. The only way I can debug is to do static images and debug the image, not a core file. I don't run anything but current so I can't do any other testing. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRbfAz62J6PPcoOkRAuPAAJ4k6en0g/YlAAUM22Qqj/Kwjx81TwCfR1bx cgq0ip67DuwPJWbfhM61kkA= =H1pB -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
* Chuck Robey <[EMAIL PROTECTED]> wrote: > I am having problems with the git out of ports git-fetch keeps on dumping > core when I try update of xorg (the initial checkout works ok). I'm running > FreeBSD-current ... does anyone have any idea why this might be? > > When I try to do a gdb -c corefile on the resulting core image, all i get is a > couple of thousand empty stack frames. Any idea why that might be, also? I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, but it seems to be crash inside free(). -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgppBLu65lYEg.pgp Description: PGP signature
git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am having problems with the git out of ports git-fetch keeps on dumping core when I try update of xorg (the initial checkout works ok). I'm running FreeBSD-current ... does anyone have any idea why this might be? When I try to do a gdb -c corefile on the resulting core image, all i get is a couple of thousand empty stack frames. Any idea why that might be, also? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRayEz62J6PPcoOkRAnjLAKCIhWPRyB/Ng17/RiUgkej+9qmp6gCcC2uM 2zxaevhQyF4C3vbsJtURSPQ= =4hoW -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
