Date: Thu, 5 Jun 2008 05:11:37 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Chuck Robey <chuckr@telenix.org> Cc: FreeBSD-Hackers <freebsd-hackers@freebsd.org> Subject: Re: git problems Message-ID: <20080604191137.GC1028@server.vk2pj.dyndns.org> In-Reply-To: <4846B40A.4010309@telenix.org> References: <4845AC84.6040407@telenix.org> <TbQi51CAu4j4cFDkKULTI53ON0k@8ZdGo3QYE5K669Y/W2Z6ZKf2XtY> <4846A77B.9060603@telenix.org> <L4F%2B2AmHcL4Uix8Rch4QiSpqQwc@RzJPyOBFuChtvuf1tf1krA3%2BwkI> <4846B40A.4010309@telenix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Osvg0bgWkLaeQPMj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jun-04 11:26:02 -0400, Chuck Robey <chuckr@telenix.org> 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=3D2, argv=3D0xffffffff) at= git.c:379 >#7 0x0804b7ed in main (argc=3D2, argv=3DCannot access memory at address 0= x12) 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 =3D 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=3D0xffffffff, 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). --=20 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. --Osvg0bgWkLaeQPMj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhG6OkACgkQ/opHv/APuId6AACeKwi96IK66pN81ZZLHocAMI2s mGYAnjvU/q5SFs/7+ah4nhZvQ30EETcR =GPX2 -----END PGP SIGNATURE----- --Osvg0bgWkLaeQPMj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080604191137.GC1028>