Date: Wed, 04 Jun 2008 10:48:15 -0400 From: Chuck Robey <chuckr@telenix.org> To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Cc: FreeBSD-Hackers <freebsd-hackers@freebsd.org> Subject: Re: git problems Message-ID: <4846AB2F.7090900@telenix.org> In-Reply-To: <L4F%2B2AmHcL4Uix8Rch4QiSpqQwc@RzJPyOBFuChtvuf1tf1krA3%2BwkI> References: <4845AC84.6040407@telenix.org> <TbQi51CAu4j4cFDkKULTI53ON0k@8ZdGo3QYE5K669Y/W2Z6ZKf2XtY> <4846A77B.9060603@telenix.org> <L4F%2B2AmHcL4Uix8Rch4QiSpqQwc@RzJPyOBFuChtvuf1tf1krA3%2BwkI>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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 > <ports>/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=0xffffffff) 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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4846AB2F.7090900>