{"thread":{"id":"16004","subject":"Re: linux-next: stackprotector tree build failure","startedAt":"2008-10-22T07:29:23Z","lastAt":"2008-10-22T23:54:54Z","messageCount":6,"participants":["Ingo Molnar","Stephen Rothwell","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93652","messageId":"20081022072923.GC27637@elte.hu","threadId":"16004","inReplyTo":"20081022182149.f89fe88d.sfr@canb.auug.org.au","subject":"Re: linux-next: stackprotector tree build failure","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-10-22T07:29:23Z","receivedAt":"2008-10-22T07:29:23Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Stephen Rothwell wrote:\n\n> Hi Ingo,\n> \n> On Wed, 22 Oct 2008 06:32:27 +0200 Ingo Molnar wrote:\n> >\n> > This seems to have been caused by a git-rerere bug - it mis-matched a \n> > timers tree conflict resolution. I cleared out that resolution (it had \n> > nothing to do with stackprotector), re-did the conflict resolution \n> > (which was about overlapping additions of header files), and pushed out \n> > a new stackprotector tree - the delta below has the expected result.\n> \n> I wondered how you could have possibly got that result - aren't \n> computers wonderful! :-)\n\nheh, yes :)\n\nthis is the second time i met a git-rerere mismatch - the first one was \nhalf a year ago.\n\nUnfortunately i failed at generating a reproducer back then and even now \n- as to resolve this problem i manually removed the preimage and \npostimage, so it's gone now.\n\nI've Cc:-ed Junio and the Git list as a general FYI - but it must be \nfrustrating to get such a bugreport, because i have no reproducer.\n\ngit-rerere sometimes seems to be picking up the wrong resolution. VERY \nrarely.\n\nIt seems random and content dependent. Once it happened to \narch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170 \nsuccessful resolutions i have in my tree right now. And i do many \nconflict resolutions every day - and it happened only once every 6 \nmonths or so.\n\n(the arch/x86/kernel/traps_32.c one happened regularly, that's why i \nthought it's content sha1 dependent, and not some corruption.)\n\nNext time it happens i'll be on the watchout and will save the complete \ntree.\n\n\tIngo\n"},{"id":"93659","messageId":"20081022192725.5f5de711.sfr@canb.auug.org.au","threadId":"16004","inReplyTo":"20081022072923.GC27637@elte.hu","subject":"Re: linux-next: stackprotector tree build failure","fromName":"Stephen Rothwell","fromEmail":"sfr@canb.auug.org.au","sentAt":"2008-10-22T08:27:25Z","receivedAt":"2008-10-22T08:27:25Z","isPatch":false,"sender":{"key":"sfr@canb.auug.org.au","avatar":null},"body":"On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar wrote:\n>\n> I've Cc:-ed Junio and the Git list as a general FYI - but it must be \n> frustrating to get such a bugreport, because i have no reproducer.\n> \n> git-rerere sometimes seems to be picking up the wrong resolution. VERY \n> rarely.\n> \n> It seems random and content dependent. Once it happened to \n> arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170 \n> successful resolutions i have in my tree right now. And i do many \n> conflict resolutions every day - and it happened only once every 6 \n> months or so.\n> \n> (the arch/x86/kernel/traps_32.c one happened regularly, that's why i \n> thought it's content sha1 dependent, and not some corruption.)\n> \n> Next time it happens i'll be on the watchout and will save the complete \n> tree.\n\nI think rerere matches preimages on the SHA1 of the conflict (or its\nreverse), so sufficiently similar pieces of code will match. I would\nexpect things like ext2/3/4 to be candidates. Did the traps_32.c one\nmatch one for traps_64.c?\n\nI may be mistaken, but I once followed the code in rerere to try to\nfigure out how to fix a resolution.\n-- \nCheers,\nStephen Rothwell sfr@canb.auug.org.au\nhttp://www.canb.auug.org.au/~sfr/\n"},{"id":"93660","messageId":"20081022193113.20369b63.sfr@canb.auug.org.au","threadId":"16004","inReplyTo":"20081022192725.5f5de711.sfr@canb.auug.org.au","subject":"Re: linux-next: stackprotector tree build failure","fromName":"Stephen Rothwell","fromEmail":"sfr@canb.auug.org.au","sentAt":"2008-10-22T08:31:13Z","receivedAt":"2008-10-22T08:31:13Z","isPatch":false,"sender":{"key":"sfr@canb.auug.org.au","avatar":null},"body":"On Wed, 22 Oct 2008 19:27:25 +1100 Stephen Rothwell wrote:\n>\n> I think rerere matches preimages on the SHA1 of the conflict (or its\n> reverse), so sufficiently similar pieces of code will match. I would\n> expect things like ext2/3/4 to be candidates. Did the traps_32.c one\n> match one for traps_64.c?\n\nOr, of course similar conflicts in different merges in different branches\nof the same tree are really asking for it ...\n\n-- \nCheers,\nStephen Rothwell sfr@canb.auug.org.au\nhttp://www.canb.auug.org.au/~sfr/\n"},{"id":"93661","messageId":"20081022083139.GA4369@elte.hu","threadId":"16004","inReplyTo":"20081022192725.5f5de711.sfr@canb.auug.org.au","subject":"Re: linux-next: stackprotector tree build failure","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-10-22T08:31:39Z","receivedAt":"2008-10-22T08:31:39Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Stephen Rothwell wrote:\n\n> On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar wrote:\n> >\n> > I've Cc:-ed Junio and the Git list as a general FYI - but it must be \n> > frustrating to get such a bugreport, because i have no reproducer.\n> > \n> > git-rerere sometimes seems to be picking up the wrong resolution. VERY \n> > rarely.\n> > \n> > It seems random and content dependent. Once it happened to \n> > arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170 \n> > successful resolutions i have in my tree right now. And i do many \n> > conflict resolutions every day - and it happened only once every 6 \n> > months or so.\n> > \n> > (the arch/x86/kernel/traps_32.c one happened regularly, that's why i \n> > thought it's content sha1 dependent, and not some corruption.)\n> > \n> > Next time it happens i'll be on the watchout and will save the complete \n> > tree.\n> \n> I think rerere matches preimages on the SHA1 of the conflict (or its \n> reverse), so sufficiently similar pieces of code will match. I would \n> expect things like ext2/3/4 to be candidates. Did the traps_32.c one \n> match one for traps_64.c?\n> \n> I may be mistaken, but I once followed the code in rerere to try to \n> figure out how to fix a resolution.\n\nthe traps_32.c one was that git-rerere put in a traps_64.c end result. \nSo i ended up with a 32-bit kernel that tried to build a 64-bit piece of \ncode - fireworks. That condition persisted - i had to fix it up manually \nall the time i integrated that portion of the tree. That too was i think \ncentered around a header file chunk - perhaps the #include section of \ntraps_32.c and traps_64.c was similar enough in that section?\n\n\tIngo\n"},{"id":"93702","messageId":"alpine.DEB.1.00.0810221908100.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16004","inReplyTo":"20081022083139.GA4369@elte.hu","subject":"Re: linux-next: stackprotector tree build failure","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-22T17:41:18Z","receivedAt":"2008-10-22T17:41:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 22 Oct 2008, Ingo Molnar wrote:\n\n> \n> * Stephen Rothwell wrote:\n> \n> > On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar wrote:\n> > >\n> > > I've Cc:-ed Junio and the Git list as a general FYI - but it must be \n> > > frustrating to get such a bugreport, because i have no reproducer.\n> > > \n> > > git-rerere sometimes seems to be picking up the wrong resolution. VERY \n> > > rarely.\n> > > \n> > > It seems random and content dependent. Once it happened to \n> > > arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170 \n> > > successful resolutions i have in my tree right now. And i do many \n> > > conflict resolutions every day - and it happened only once every 6 \n> > > months or so.\n> > > \n> > > (the arch/x86/kernel/traps_32.c one happened regularly, that's why i \n> > > thought it's content sha1 dependent, and not some corruption.)\n> > > \n> > > Next time it happens i'll be on the watchout and will save the complete \n> > > tree.\n> > \n> > I think rerere matches preimages on the SHA1 of the conflict (or its \n> > reverse), so sufficiently similar pieces of code will match. I would \n> > expect things like ext2/3/4 to be candidates. Did the traps_32.c one \n> > match one for traps_64.c?\n> > \n> > I may be mistaken, but I once followed the code in rerere to try to \n> > figure out how to fix a resolution.\n> \n> the traps_32.c one was that git-rerere put in a traps_64.c end result. \n> So i ended up with a 32-bit kernel that tried to build a 64-bit piece of \n> code - fireworks. That condition persisted - i had to fix it up manually \n> all the time i integrated that portion of the tree. That too was i think \n> centered around a header file chunk - perhaps the #include section of \n> traps_32.c and traps_64.c was similar enough in that section?\n\nI think it might be in order to explain how git-rerere works internally:\n\n- in case of a conflicts, the files' conflicts are written into the \n rr-cache _per file_.\n\n First, the human readable stuff after the \"<<<\", \"|||\" and \">>>\" lines \n is removed.\n\n Then, the \"||| ... ===\" part is removed, too (in effect turning the \n diff3-style conflicts into an RCS merge-style conflicts).\n\n The result is recorded as \"preimage\". The conflict is identified by the \n SHA-1 of _just_ the conflicts (including the \"<<<\", \"===\" and \">>>\" \n lines).\n\n After all the conflicted files have been handled, a list is written to \n the file \"MERGE_RR\" containing the SHA-1s of the conflicts together with \n the file names.\n\n- when committing, the files whose conflicts were resolved are recorded \n verbatim in the file \"postimage\".\n\nNow, when rerere is called again and there are conflicted files, again the \nfiles' conflicts are identified by their SHA-1. If a resolution exists, a \n3-way merge is performed with the recorded preimage (the \noriginal file with conflict lines) as base, the postimage (the originally \nresolved file) and the current file with conflict lines.\n\nThe idea being: the diff between the recorded preimage and postimage gives \nthe resolution that you want, and the diff between the recorded preimage \nand the current file with conflict lines gives you the changes that \nhappened to the file in-between.\n\nSo I think that you might hit the unfortunate case where two files \nhappened to have the same conflicts, but you needed to resolve them one \nway for one file, and another way for the other file.\n\nCiao,\nDscho\n"},{"id":"93747","messageId":"20081023105454.880e13e2.sfr@canb.auug.org.au","threadId":"16004","inReplyTo":"alpine.DEB.1.00.0810221908100.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: linux-next: stackprotector tree build failure","fromName":"Stephen Rothwell","fromEmail":"sfr@canb.auug.org.au","sentAt":"2008-10-22T23:54:54Z","receivedAt":"2008-10-22T23:54:54Z","isPatch":false,"sender":{"key":"sfr@canb.auug.org.au","avatar":null},"body":"Hi Johannes,\n\nOn Wed, 22 Oct 2008 19:41:18 +0200 (CEST) Johannes Schindelin wrote:\n>\n> I think it might be in order to explain how git-rerere works internally:\n\nThanks for the explanation.\n\n> So I think that you might hit the unfortunate case where two files \n> happened to have the same conflicts, but you needed to resolve them one \n> way for one file, and another way for the other file.\n\nWhich makes perfect sense, unfortunately.\n\n-- \nCheers,\nStephen Rothwell sfr@canb.auug.org.au\nhttp://www.canb.auug.org.au/~sfr/\n"}]}