{"thread":{"id":"4535","subject":"parsecvs and unnamed branches","startedAt":"2006-06-16T21:44:43Z","lastAt":"2006-06-17T17:13:16Z","messageCount":14,"participants":["Jon Smirl","Keith Packard","Pavel Roskin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21915","messageId":"9e4733910606161444i2f996096sbd1f9b3f3ff3a32d@mail.gmail.com","threadId":"4535","inReplyTo":null,"subject":"parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-16T21:44:43Z","receivedAt":"2006-06-16T21:44:43Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"I'm getting thousands of messages about unnamed branches and even\n'unnamed branch from master-UNNAMED-BRANCH'.\n\nHow do you get unnamed branches into CVS, are these check-in errors or\nare people actually working on unnamed branches? Or is parsecvs not\nfinding all of the branch info?\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21918","messageId":"1150496362.6983.34.camel@neko.keithp.com","threadId":"4535","inReplyTo":"9e4733910606161444i2f996096sbd1f9b3f3ff3a32d@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-16T22:19:22Z","receivedAt":"2006-06-16T22:19:22Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:\n> I'm getting thousands of messages about unnamed branches and even\n> 'unnamed branch from master-UNNAMED-BRANCH'.\n> \n> How do you get unnamed branches into CVS, are these check-in errors or\n> are people actually working on unnamed branches? Or is parsecvs not\n> finding all of the branch info?\n\nbranch names rely on a special 'branch tag' in the \"symbols\" section of\nthe CVS file, but actual branches are flagged directly in the revision\nlist. I don't know how it happens, but ,v files often end up with\nbranches in the revision tree which haven't an associated tag. Go\nfigure.\n\nFor example, in the top level mozilla/Makefile.in,v file, you'll see a\nbranch from version 1.36 with an initial commit 1.36.2.1. Using the\nwacky CVS branch revision numbering scheme, there should be an\nassociated tag for version 1.36.0.2 (yes, the last two digits are\nflipped). But, none is present in the file.\n\nThe reverse situation also occurs, with tags for branches that have no\nrevisions in the file. This case makes sense -- until you make a change\nin a file along a branch, there will be no other record in the file of\nwhere the branch came from.\n\nI'd love to figure out a better mechanism for merging these nameless\nbranches into the resulting repository, but I don't know how to\ncorrelate unnamed branches in one file with unnamed branches in other\nfiles.\n\nThe current scheme of making up a fixed name and hoping that there\naren't multiple unmamed branches from the same root is probably fraught\nwith peril.\n\n-- \nkeith.packard@intel.com\n"},{"id":"21919","messageId":"9e4733910606161528n668a96afgefca16644f8038b6@mail.gmail.com","threadId":"4535","inReplyTo":"1150496362.6983.34.camel@neko.keithp.com","subject":"Re: parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-16T22:28:08Z","receivedAt":"2006-06-16T22:28:08Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/16/06, Keith Packard <keithp@keithp.com> wrote:\n> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:\n> > I'm getting thousands of messages about unnamed branches and even\n> > 'unnamed branch from master-UNNAMED-BRANCH'.\n> >\n> > How do you get unnamed branches into CVS, are these check-in errors or\n> > are people actually working on unnamed branches? Or is parsecvs not\n> > finding all of the branch info?\n>\n> branch names rely on a special 'branch tag' in the \"symbols\" section of\n> the CVS file, but actual branches are flagged directly in the revision\n> list. I don't know how it happens, but ,v files often end up with\n> branches in the revision tree which haven't an associated tag. Go\n> figure.\n>\n> For example, in the top level mozilla/Makefile.in,v file, you'll see a\n> branch from version 1.36 with an initial commit 1.36.2.1. Using the\n> wacky CVS branch revision numbering scheme, there should be an\n> associated tag for version 1.36.0.2 (yes, the last two digits are\n> flipped). But, none is present in the file.\n\nI was reading the CVS manual and it talks about magic branch number as\nbeing the ones with zero in them. Doesn't go into a lot of detail.\nApparently they are autogenerated internally.\n\nhttp://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#Magic_branch_numbers\n\n\n>\n> The reverse situation also occurs, with tags for branches that have no\n> revisions in the file. This case makes sense -- until you make a change\n> in a file along a branch, there will be no other record in the file of\n> where the branch came from.\n>\n> I'd love to figure out a better mechanism for merging these nameless\n> branches into the resulting repository, but I don't know how to\n> correlate unnamed branches in one file with unnamed branches in other\n> files.\n>\n> The current scheme of making up a fixed name and hoping that there\n> aren't multiple unmamed branches from the same root is probably fraught\n> with peril.\n>\n> --\n> keith.packard@intel.com\n>\n>\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1.4.3 (GNU/Linux)\n>\n> iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC\n> Kl7lEHIJgi5Tk24quc9FZyM=\n> =FA7H\n> -----END PGP SIGNATURE-----\n>\n>\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21921","messageId":"9e4733910606161539t2485e3b3xa9f2852a4d2fc18f@mail.gmail.com","threadId":"4535","inReplyTo":"1150496362.6983.34.camel@neko.keithp.com","subject":"Re: parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-16T22:39:29Z","receivedAt":"2006-06-16T22:39:29Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/16/06, Keith Packard <keithp@keithp.com> wrote:\n> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:\n> > I'm getting thousands of messages about unnamed branches and even\n> > 'unnamed branch from master-UNNAMED-BRANCH'.\n> >\n> > How do you get unnamed branches into CVS, are these check-in errors or\n> > are people actually working on unnamed branches? Or is parsecvs not\n> > finding all of the branch info?\n>\n> branch names rely on a special 'branch tag' in the \"symbols\" section of\n> the CVS file, but actual branches are flagged directly in the revision\n> list. I don't know how it happens, but ,v files often end up with\n> branches in the revision tree which haven't an associated tag. Go\n> figure.\n>\n> For example, in the top level mozilla/Makefile.in,v file, you'll see a\n> branch from version 1.36 with an initial commit 1.36.2.1. Using the\n> wacky CVS branch revision numbering scheme, there should be an\n> associated tag for version 1.36.0.2 (yes, the last two digits are\n> flipped). But, none is present in the file.\n\nThere is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does\nseems to correspond to anything. Could that be the missing tag?\n\n>\n> The reverse situation also occurs, with tags for branches that have no\n> revisions in the file. This case makes sense -- until you make a change\n> in a file along a branch, there will be no other record in the file of\n> where the branch came from.\n>\n> I'd love to figure out a better mechanism for merging these nameless\n> branches into the resulting repository, but I don't know how to\n> correlate unnamed branches in one file with unnamed branches in other\n> files.\n>\n> The current scheme of making up a fixed name and hoping that there\n> aren't multiple unmamed branches from the same root is probably fraught\n> with peril.\n>\n> --\n> keith.packard@intel.com\n>\n>\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1.4.3 (GNU/Linux)\n>\n> iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC\n> Kl7lEHIJgi5Tk24quc9FZyM=\n> =FA7H\n> -----END PGP SIGNATURE-----\n>\n>\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21923","messageId":"1150498303.6983.39.camel@neko.keithp.com","threadId":"4535","inReplyTo":"9e4733910606161539t2485e3b3xa9f2852a4d2fc18f@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-16T22:51:43Z","receivedAt":"2006-06-16T22:51:43Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Fri, 2006-06-16 at 18:39 -0400, Jon Smirl wrote:\n\n> There is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does\n> seems to correspond to anything. Could that be the missing tag?\n\nThere's no particular reason to believe it should be; remember that\nevery file gets a 'magic branch' tag whenever you create a branch in the\nrepository, but only files with commits along that branch ever see the\nrevision tree information related to it, so you can expect to see many\nbranch tags without associated branch revisions in any particular ,v\nfile. Looking at the commits along 1.3.2, they don't seem particularily\nrelated to the SeaMonkey_M8 branch.  \n\n-- \nkeith.packard@intel.com\n"},{"id":"21933","messageId":"9e4733910606162002x508ec6ccjbc36e4220ca44fd6@mail.gmail.com","threadId":"4535","inReplyTo":"1150496362.6983.34.camel@neko.keithp.com","subject":"Re: parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-17T03:02:05Z","receivedAt":"2006-06-17T03:02:05Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"My parsecvs job died after 5 hours of CPU time. Does this tell you anything?\n\nPack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created\n\nError: branch cycle\n*** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***\n*** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***\n======= Backtrace: =========\n/lib/libc.so.6[0x45a502c6]\n/lib/libc.so.6[0x45a5235a]\n/lib/libc.so.6(calloc+0x8d)[0x45a539a1]\n/lib/ld-linux.so.2[0x459db1ba]\n/lib/ld-linux.so.2[0x459d6f8a]\n/lib/ld-linux.so.2[0x459d91e1]\n/lib/ld-linux.so.2[0x459e2204]\n/lib/ld-linux.so.2[0x459de7b9]\n/lib/ld-linux.so.2[0x459e1d0a]\n/lib/libc.so.6[0x45ae9c3e]\n/lib/ld-linux.so.2[0x459de7b9]\n/lib/libc.so.6(__libc_dlopen_mode+0x55)[0x45ae9dc9]\n/lib/libc.so.6[0x45ac90f6]\n/lib/libc.so.6(backtrace+0x109)[0x45ac9295]\n/lib/libc.so.6[0x45a4aa61]\n/lib/libc.so.6(__libc_free+0x179)[0x45a554f0]\nparsecvs[0x804dec8]\nparsecvs[0x804df1e]\nparsecvs[0x804ccce]\n/lib/libc.so.6(__libc_start_main+0xdc)[0x45a03724]\nparsecvs[0x8049cc1]\n======= Memory map: ========\n08048000-08065000 r-xp 00000000 09:01 4052384\n/home/jonsmirl/workspace/parsecvs/parsecvs\n08065000-08067000 rw-p 0001c000 09:01 4052384\n/home/jonsmirl/workspace/parsecvs/parsecvs\n08067000-459c9000 rw-p 08067000 00:00 0          [heap]\n459d1000-459ea000 r-xp 00000000 03:06 4243239    /lib/ld-2.4.so\n459ea000-459eb000 r--p 00018000 03:06 4243239    /lib/ld-2.4.so\n459eb000-459ec000 rw-p 00019000 03:06 4243239    /lib/ld-2.4.so\n459ee000-45b1b000 r-xp 00000000 03:06 4243241    /lib/libc-2.4.so\n45b1b000-45b1d000 r--p 0012d000 03:06 4243241    /lib/libc-2.4.so\n45b1d000-45b1e000 rw-p 0012f000 03:06 4243241    /lib/libc-2.4.so\n45b1e000-45b21000 rw-p 45b1e000 00:00 0\n45b23000-45b25000 r-xp 00000000 03:06 4243258    /lib/libdl-2.4.so\n45b25000-45b26000 r--p 00001000 03:06 4243258    /lib/libdl-2.4.so\n45b26000-45b27000 rw-p 00002000 03:06 4243258    /lib/libdl-2.4.so\n45c6e000-45c80000 r-xp 00000000 03:06 1782100    /usr/lib/libz.so.1.2.3\n45c80000-45c81000 rw-p 00011000 03:06 1782100    /usr/lib/libz.so.1.2.3\n46497000-46499000 r-xp 00000000 03:06 4244426    /lib/libcom_err.so.2.1\n46499000-4649a000 rw-p 00001000 03:06 4244426    /lib/libcom_err.so.2.1\n4649c000-464ab000 r-xp 00000000 03:06 4244425    /lib/libresolv-2.4.so\n464ab000-464ac000 r--p 0000e000 03:06 4244425    /lib/libresolv-2.4.so\n464ac000-464ad000 rw-p 0000f000 03:06 4244425    /lib/libresolv-2.4.so\n464ad000-464af000 rw-p 464ad000 00:00 0\n464bb000-465da000 r-xp 00000000 03:06 4244427    /lib/libcrypto.so.0.9.8a\n465da000-465ed000 rw-p 0011e000 03:06 4244427    /lib/libcrypto.so.0.9.8a\n465ed000-465f0000 rw-p 465ed000 00:00 0\n465f2000-465f5000 r-xp 00000000 03:06 1785207    /usr/lib/libkrb5support.so.0.0\n465f5000-465f6000 rw-p 00002000 03:06 1785207    /usr/lib/libkrb5support.so.0.0\n465f8000-4666b000 r-xp 00000000 03:06 1788263    /usr/lib/libkrb5.so.3.2\n4666b000-4666d000 rw-p 00073000 03:06 1788263    /usr/lib/libkrb5.so.3.2\n4666f000-46687000 r-xp 00000000 03:06 1788264    /usr/lib/libgssapi_krb5.so.2.2\n46687000-46688000 rw-p 00017000 03:06 1788264    /usr/lib/libgssapi_krb5.so.2.2\n4668a000-466ae000 r-xp 00000000 03:06 1788262    /usr/lib/libk5crypto.so.3.0\n466ae000-466af000 rw-p 00024000 03:06 1788262    /usr/lib/libk5crypto.so.3.0\n467e0000-46821000 r-xp 00000000 03:06 4244428    /lib/libssl.so.0.9.8a\n46821000-46825000 rw-p 00040000 03:06 4244428    /lib/libssl.so.0.9.8a\n84400000-84421000 rw-p 84400000 00:00 0\n84421000-84500000 ---p 84421000 00:00 0\n84518000-84523000 r-xp 00000000 03:06 4244801\n/lib/libgcc_s-4.1.1-20060525.so.1\n84523000-84524000 rw-p 0000a000 03:06 4244801\n/lib/libgcc_s-4.1.1-20060525.so.1\n84538000-85438000 rw-p 84538000 00:00 0\n854bc000-856bc000 rw-p 854bc000 00:00 0\n8577f000-86b7f000 rw-p 8577f000 00:00 0\n86bc1000-86dc1000 rw-p 86bc1000 00:00 0\n86e65000-88465000 rw-p 86e65000 00:00 0\n884e8000-893e8000 rw-p 884e8000 00:00 0\n893e9000-896e9000 rw-p 893e9000 00:00 0\n896ea000-89bea000 rw-p 896ea000 00:00 0\n89c2c000-89f2c000 rw-p 89c2c000 00:00 0\n89f4d000-8a14d000 rw-p 89f4d000 00:00 0\n8a16e000-8a76e000 rw-p 8a16e000 00:00 0\n8a76f000-8af6f000 rw-p 8a76f000 00:00 0\n8b056000-8b156000 rw-p 8b056000 00:00 0\n8b177000-8b477000 rw-p 8b177000 00:00 0\n8b478000-8b978000 rw-p 8b478000 00:00 0\n8b979000-8ba79000 rw-p 8b979000 00:00 0\n8ba9a000-8bc9a000 rw-p 8ba9a000 00:00 0\n8bd1e000-8c11e000 rw-p 8bd1e000 00:00 0\n8c11f000-8c41f000 rw-p 8c11f000 00:00 0\n8c420000-8c520000 rw-p 8c420000 00:00 0\n8c582000-8c682000 rw-p 8c582000 00:00 0\n8c683000-8d383000 rw-p 8c683000 00:00 0\n8d426000-8d5260Aborted\n[jonsmirl@jonsmirl parsecvs]$\n\n\n\n\n\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21934","messageId":"1150513943.29738.15.camel@dv","threadId":"4535","inReplyTo":"9e4733910606162002x508ec6ccjbc36e4220ca44fd6@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-17T03:12:23Z","receivedAt":"2006-06-17T03:12:23Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hi, Jon!\n\nOn Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:\n> My parsecvs job died after 5 hours of CPU time. Does this tell you anything?\n> \n> Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created\n> \n> Error: branch cycle\n> *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***\n> *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***\n\nObviously, memory corruption.  Valgrind is likely to help, but it may\ntake 50 hours rather than 5.  It may still be worth it.  Make sure to\nuse the latest version of Valgrind and compile parsecvs without\noptimization with full debug information.  If you can get debug info for\nlibc, install it (on Fedora: \"yum install glibc-debuginfo\").\n\n> /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]\n> parsecvs[0x804dec8]\n\nYou see, even some libc symbols can be found, but parsecvs is opaque.\nThat's why debug information is useful.  Make sure to keep the sources\naround for debugging.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21935","messageId":"9e4733910606162031o69df27fdje50c88949ed990b5@mail.gmail.com","threadId":"4535","inReplyTo":"1150513943.29738.15.camel@dv","subject":"Re: parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-17T03:31:38Z","receivedAt":"2006-06-17T03:31:38Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/16/06, Pavel Roskin <proski@gnu.org> wrote:\n> Hi, Jon!\n>\n> On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:\n> > My parsecvs job died after 5 hours of CPU time. Does this tell you anything?\n> >\n> > Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created\n> >\n> > Error: branch cycle\n> > *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***\n> > *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***\n>\n> Obviously, memory corruption.  Valgrind is likely to help, but it may\n> take 50 hours rather than 5.  It may still be worth it.  Make sure to\n> use the latest version of Valgrind and compile parsecvs without\n> optimization with full debug information.  If you can get debug info for\n> libc, install it (on Fedora: \"yum install glibc-debuginfo\").\n>\n> > /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]\n> > parsecvs[0x804dec8]\n>\n> You see, even some libc symbols can be found, but parsecvs is opaque.\n> That's why debug information is useful.  Make sure to keep the sources\n> around for debugging.\n\nParsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?\n\nThe 'Error: branch cycle' message was critical, the app was in the\nprocess of doing exit clean up with the link list error was found. If\nthe list is linked in a circle it is likely that the routine freeing\nit corrupted memory. So the real error is why did I get 'Error: branch\ncycle'.\n\n> --\n> Regards,\n> Pavel Roskin\n>\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21936","messageId":"1150517336.9144.8.camel@dv","threadId":"4535","inReplyTo":"9e4733910606162031o69df27fdje50c88949ed990b5@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-17T04:08:56Z","receivedAt":"2006-06-17T04:08:56Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:\n\n> Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?\n\nSorry, I was too quick to put blame on you.  Maybe glibc can only list\nits own symbols.\n\nI could reproduce the problem trivially with a single file, and here's\nwhat Valgrind says:\n\n==11154== Invalid free() / delete / delete[]\n==11154==    at 0x4905423: free (vg_replace_malloc.c:233)\n==11154==    by 0x40C136: git_pack_directory (git.c:620)\n==11154==    by 0x40C1B4: git_rev_list_pack (git.c:639)\n==11154==    by 0x4067DA: main (parsecvs.c:785)\n\n\ngit_pack_directory() tries to free() the result of\ngit_system_to_string(), which is in turn a result of atom().  My\nunderstanding is that atoms should not be freed.  They are not freed in\nother cases.\n\nPatch:\n\ndiff --git a/README b/README\ndiff --git a/git.c b/git.c\nindex 33b29c7..7312568 100644\n--- a/git.c\n+++ b/git.c\n@@ -617,7 +617,6 @@ git_pack_directory (void)\n \t}\n \tfree (objects_dir);\n \tpack_dir = git_format_command (\"%s/objects/pack\", git_dir);\n-        free (git_dir);\n \tif (!pack_dir)\n \t    return NULL;\n \tif (access (pack_dir, F_OK) == -1 &&\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21937","messageId":"9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com","threadId":"4535","inReplyTo":"1150517336.9144.8.camel@dv","subject":"Re: parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-17T04:15:57Z","receivedAt":"2006-06-17T04:15:57Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/17/06, Pavel Roskin <proski@gnu.org> wrote:\n> On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:\n>\n> > Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?\n>\n> Sorry, I was too quick to put blame on you.  Maybe glibc can only list\n> its own symbols.\n>\n> I could reproduce the problem trivially with a single file, and here's\n> what Valgrind says:\n>\n> ==11154== Invalid free() / delete / delete[]\n> ==11154==    at 0x4905423: free (vg_replace_malloc.c:233)\n> ==11154==    by 0x40C136: git_pack_directory (git.c:620)\n> ==11154==    by 0x40C1B4: git_rev_list_pack (git.c:639)\n> ==11154==    by 0x4067DA: main (parsecvs.c:785)\n>\n>\n> git_pack_directory() tries to free() the result of\n> git_system_to_string(), which is in turn a result of atom().  My\n> understanding is that atoms should not be freed.  They are not freed in\n> other cases.\n>\n> Patch:\n>\n> diff --git a/README b/README\n> diff --git a/git.c b/git.c\n> index 33b29c7..7312568 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -617,7 +617,6 @@ git_pack_directory (void)\n>         }\n>         free (objects_dir);\n>         pack_dir = git_format_command (\"%s/objects/pack\", git_dir);\n> -        free (git_dir);\n>         if (!pack_dir)\n>             return NULL;\n>         if (access (pack_dir, F_OK) == -1 &&\n\nI had already caught that one, the fix was a few mails back.\ngit_dir is an atom and shouldn't be freed with free.\n\nAfter five hours I hit this:\nfprintf (stderr, \"Error: branch cycle\\n\");\n\nstatic rev_ref *\nrev_ref_tsort (rev_ref *refs, rev_list *head)\n{\n    rev_ref *done = NULL;\n    rev_ref **done_tail = &done;\n    rev_ref *r, **prev;\n\n//    fprintf (stderr, \"Tsort refs:\\n\");\n    while (refs) {\n        for (prev = &refs; (r = *prev); prev = &(*prev)->next) {\n            if (rev_ref_is_ready (r->name, head, done)) {\n                break;\n            }\n        }\n        if (!r) {\n            fprintf (stderr, \"Error: branch cycle\\n\");\n>> hit this test\n            return NULL;\n        }\n        *prev = r->next;\n        *done_tail = r;\n//      fprintf (stderr, \"\\t%s\\n\", r->name);\n        r->next = NULL;\n        done_tail = &r->next;\n    }\n    return done;\n}\n\nwhich returned null up to here\n\n    if (rev_mode == ExecuteGit && pack_objcount && autopack)\n        git_rev_list_pack (pack_start, strip);\n    load_status_next ();\n    rl = rev_list_merge (head);\n>> null to here\n    if (rl) {\n        switch (rev_mode) {\n        case ExecuteGraph:\n            dump_rev_graph (rl, NULL);\n            break;\n        case ExecuteSplits:\n            dump_splits (rl);\n            break;\n        case ExecuteGit:\n            git_rev_list_commit (rl, strip);\n            break;\n        }\n    }\n    if (rl)\n        rev_list_free (rl, 0);\n    while (head) {\n        rl = head;\n        head = head->next;\n        rev_list_free (rl, 1);\n>> tries to free the list, but the list is a loop.\n>> after it wraps it will mangle memory\n\n    }\n    discard_atoms ();\n    rev_free_dirs ();\n    rev_commit_cleanup ();\n    git_free_author_map ();\n    return err;\n\n>>But the real problem is why does it think the branches are in a loop?\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21938","messageId":"1150518950.9144.17.camel@dv","threadId":"4535","inReplyTo":"9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-17T04:35:50Z","receivedAt":"2006-06-17T04:35:50Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:\n> I had already caught that one, the fix was a few mails back.\n> git_dir is an atom and shouldn't be freed with free.\n\nI see it now.  My patch was wrong - there is another free(git_dir) in\nthe same function.  Keith, please remove both.\n\n> After five hours I hit this:\n> fprintf (stderr, \"Error: branch cycle\\n\");\n\nThis is more like a logical error.  Maybe you actually have circling\nbranches due to causality violations or something :-)\n\nSure, Valgrind would be still useful to make sure it's not something\nmundane.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21940","messageId":"1150522246.6983.52.camel@neko.keithp.com","threadId":"4535","inReplyTo":"9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-17T05:30:46Z","receivedAt":"2006-06-17T05:30:46Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:\n\n> >>But the real problem is why does it think the branches are in a loop?\n\nI haven't figured it out yet either; mine didn't detect the loop though,\nit just ended up spinning in the tsort code, unable to compute a valid\norder to execute branches in. Something funky must be up with the\nmozilla branches.\n\nWhat this code does is find an order that will 'work' when computing\nbranch contents. The requirement is that the 'parent' branch be computed\nbefore any 'child' branches. \n\nIt does this with a nice quadratic algorithm, building a list of 'ready'\nbranches who have no 'unready' dependencies in any of the incoming file\nobjects. If there are conflicts where one incoming file shows branch 'B'\nas the parent of branch 'A' while another shows branch 'A' as the parent\nof branch 'B', the sorting cannot succeed.\n\nIdeally, I'd figure out a way to eliminate the parent/child relationship\nand just treat the branches as peers with a common ancestor. I haven't\nfigure out how to manage that yet; attempting to find the precise\ndivergence point where the child forks from the parent remains\ncomplicated, it seems like trying to do that without a strong\nparent/child relationship would be even more error prone.\n\nBetter error messsages here would clearly help discover which branches\nwere in conflict, and show the files causing problems.\n\n-- \nkeith.packard@intel.com\n"},{"id":"21942","messageId":"9e4733910606162251i65021336m4388d4da715befc9@mail.gmail.com","threadId":"4535","inReplyTo":"1150522246.6983.52.camel@neko.keithp.com","subject":"Re: parsecvs and unnamed branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-06-17T05:51:59Z","receivedAt":"2006-06-17T05:51:59Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 6/17/06, Keith Packard <keithp@keithp.com> wrote:\n> On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:\n>\n> > >>But the real problem is why does it think the branches are in a loop?\n>\n> I haven't figured it out yet either; mine didn't detect the loop though,\n> it just ended up spinning in the tsort code, unable to compute a valid\n> order to execute branches in. Something funky must be up with the\n> mozilla branches.\n\nHave you checked parsecvs on the 38 test repositories in the cvs2svn source?\n\n\n> What this code does is find an order that will 'work' when computing\n> branch contents. The requirement is that the 'parent' branch be computed\n> before any 'child' branches.\n>\n> It does this with a nice quadratic algorithm, building a list of 'ready'\n> branches who have no 'unready' dependencies in any of the incoming file\n> objects. If there are conflicts where one incoming file shows branch 'B'\n> as the parent of branch 'A' while another shows branch 'A' as the parent\n> of branch 'B', the sorting cannot succeed.\n>\n> Ideally, I'd figure out a way to eliminate the parent/child relationship\n> and just treat the branches as peers with a common ancestor. I haven't\n> figure out how to manage that yet; attempting to find the precise\n> divergence point where the child forks from the parent remains\n> complicated, it seems like trying to do that without a strong\n> parent/child relationship would be even more error prone.\n>\n> Better error messsages here would clearly help discover which branches\n> were in conflict, and show the files causing problems.\n>\n> --\n> keith.packard@intel.com\n>\n>\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1.4.3 (GNU/Linux)\n>\n> iD8DBQBEk5OGQp8BWwlsTdMRAuyZAKC3URBHR/SWgG7azMqKe3efGNxNZwCdFAVA\n> GEIKF8z/MtdbBnKRMDneSH8=\n> =ShEA\n> -----END PGP SIGNATURE-----\n>\n>\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"21961","messageId":"1150564396.6983.73.camel@neko.keithp.com","threadId":"4535","inReplyTo":"9e4733910606162251i65021336m4388d4da715befc9@mail.gmail.com","subject":"Re: parsecvs and unnamed branches","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-06-17T17:13:16Z","receivedAt":"2006-06-17T17:13:16Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Sat, 2006-06-17 at 01:51 -0400, Jon Smirl wrote:\n\n> Have you checked parsecvs on the 38 test repositories in the cvs2svn source?\n\nThose all run to completion without significant error (there are a\ncouple of tests with invalid symbol names that currently elicit errors).\n\nI haven't validated that the imports are correct though; spot checks\nseem to indicate that the problems encountered during the cvs2svn\ndevelopment aren't the same as the problems we're finding.\n\n-- \nkeith.packard@intel.com\n"}]}