{"thread":{"id":"1753","subject":"git-bisect failure","startedAt":"2005-09-09T08:10:34Z","lastAt":"2005-09-10T22:13:34Z","messageCount":9,"participants":["Andrew Morton","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8229","messageId":"20050909011034.12f2bf64.akpm@osdl.org","threadId":"1753","inReplyTo":null,"subject":"git-bisect failure","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2005-09-09T08:10:34Z","receivedAt":"2005-09-09T08:10:34Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"\nUsing git-core-0.99.6 I tried to locate a bug using git's bisection\nsearching.\n\nIt gave the wrong answer. It ended up claiming the bug was in\n\n\ntree ea7b1763aa0e0d36b52fa245449c79338fe735b3\nparent e9f86e351fda5b3c40192fc3990453613f160779\nauthor Zachary Amsden Sun, 04 Sep 2005 05:56:47 -0700\ncommitter Linus Torvalds Mon, 05 Sep 2005 14:06:13 -0700\n\n[PATCH] x86: introduce a write acessor for updating the current LDT\n\n\n\nWhereas the bug was really in\n\n\ntree 090c471fdb44d8fe88c52e95be0e8e43e31fcd5a\nparent d7271b14b2e9e5905aba0fbf5c4dc4f8980c0cb2\nauthor Zwane Mwaikambo Sun, 04 Sep 2005 05:56:51 -0700\ncommitter Linus Torvalds Mon, 05 Sep 2005 14:06:13 -0700\n\n[PATCH] i386 boottime for_each_cpu broken\n\n\nWhich is off-by-two, iirc.\n\n\nExact sequence:\n\nbix:/usr/src/git26> git bisect start\nbix:/usr/src/git26> git bisect good 02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b\nbix:/usr/src/git26> git bisect bad 4e1491847ef5ca1c5a661601d5f96dcb7d90d2f0\nBisecting: 901 revisions left to test after this\nbix:/usr/src/git26> git bisect good\nBisecting: 451 revisions left to test after this\nbix:/usr/src/git26> git bisect bad \nBisecting: 219 revisions left to test after this\nbix:/usr/src/git26> git bisect bad\nBisecting: 110 revisions left to test after this\nbix:/usr/src/git26> git bisect bad\nBisecting: 55 revisions left to test after this\nbix:/usr/src/git26> git bisect bad\nBisecting: 28 revisions left to test after this\nbix:/usr/src/git26> git bisect good\nBisecting: 14 revisions left to test after this\nbix:/usr/src/git26> git bisect good\nBisecting: 7 revisions left to test after this\nbix:/usr/src/git26> git bisect good\nBisecting: 3 revisions left to test after this\nbix:/usr/src/git26> git bisect bad \nBisecting: 2 revisions left to test after this\nbix:/usr/src/git26> git bisect good\nf2f30ebca6c0c95e987cb9a1fd1495770a75432e is first bad commit\ndiff-tree f2f30ebca6c0c95e987cb9a1fd1495770a75432e (from e9f86e351fda5b3c40192fc3990453613f160779)\nAuthor: Zachary Amsden \nDate: Sat Sep 3 15:56:47 2005 -0700\n\n [PATCH] x86: introduce a write acessor for updating the current LDT\n \n\n\nI don't think I screwed anything up.\n"},{"id":"8230","messageId":"7vwtlqli0u.fsf@assigned-by-dhcp.cox.net","threadId":"1753","inReplyTo":"20050909011034.12f2bf64.akpm@osdl.org","subject":"Re: git-bisect failure","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-09T09:14:41Z","receivedAt":"2005-09-09T09:14:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks for the note. If somebody else does not get around to it\nbefore me, I'll take a look later today after work.\n"},{"id":"8247","messageId":"7virx9ir3a.fsf@assigned-by-dhcp.cox.net","threadId":"1753","inReplyTo":"20050909011034.12f2bf64.akpm@osdl.org","subject":"Re: git-bisect failure","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-10T02:39:21Z","receivedAt":"2005-09-10T02:39:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"bix:/usr/src/git26> git bisect bad\nBisecting: 55 revisions left to test after this\n\nAt this point, you marked 4c139862b8831261d57de02716b92f82e5fb463b\n\"[PATCH] xtensa: delete accidental file\" is already bad. And the last\nknown good commit is b749bfcd1be72f8cb8310e1cac12825bda029432 \"[PATCH]\nppc64: update xmon helptext\". The commit between these is just a\nstraight sequence (no branches), so running \"git bisect visualize\"\ngives me a nice single strand of pearls.\n\nbix:/usr/src/git26> git bisect bad\nBisecting: 28 revisions left to test after this\n\nWith this, you marked \"[PATCH] i386 boottime for_each_cpu broken\" is\nbad. \"Reread references\" in the running gitk shows me that the range\nbetween bad and good halved.\n\nbix:/usr/src/git26> git bisect good\nBisecting: 14 revisions left to test after this\n\nMarked \"[PATCH] mips: remove timex.h for vr41xx\" good.\n\nbix:/usr/src/git26> git bisect good\nBisecting: 7 revisions left to test after this\n\nMarked \"[PATCH] i386: cleanup serialize msr\" good.\n\nbix:/usr/src/git26> git bisect good\nBisecting: 3 revisions left to test after this\n\nMarked \"[PATCH] x86: privilege cleanup\" good.\n\nbix:/usr/src/git26> git bisect bad \nBisecting: 2 revisions left to test after this\n\nMarked \"[PATCH] x86: introduce a write acessor for updating the\ncurrent LDT\" bad.\n\nJust after you marked \"[PATCH] x86: privilege cleanup\" as good, the\nlist of suspects looked like this (time flows bottom to top):\n\nbad [PATCH] i386 boottime for_each_cpu broken\n [PATCH] i386: encapsulate copying of pgd entries\n [PATCH] x86 NMI: better support for debuggers\n??? [PATCH] x86: introduce a write acessor for updating the current LDT\n [PATCH] x86: remove redundant TSS clearing\n [PATCH] x86: make IOPL explicit\ngood [PATCH] x86: privilege cleanup\n\nand you said the middle one is already bad here. We are tracking\nregression, so \"privilege cleanup\" was good and in the course of\nsomewhere from there to \"i386 boottime for_each_cpu broken\" which is\nbad, a breakage happened. You marked the \"updating the current LDT\"\none as bad, which to me looks like it was already broken at that point.\n\nAfter that, you say:\nbix:/usr/src/git26> git bisect good\n\nto mark \"[PATCH] x86: remove redundant TSS clearing\" as good,\nwhich means \"redundant TSS\" was good and \"current LDT\" was bad,\nand they are back to back, so it looks like the bug was\nintroduced by the \"LDT\", which is what you got. So it _might_\nbe possible that you said \"current LDT\" was bad when it was\nactually good. That is one possible explanation.\n\nAnother possibility is that the symptom you were tracking was\nnot a single regression that was introduced with a single patch.\nCould it be possible that \"the current LDT\" did not pass your\ntest but from different bug, which was fixed by either \"x86 NMI\"\nor \"encapsulate copying pgd\"? Sorry I am not a kernel developer\nso I cannot judge if the above is plausible or not.\n\nIn any case, there is one caveat about bisection bug search. It\nassumes that you are tracking a single regression that was\nintroduced, and there is no funny interaction of bugs hiding\neach other -- this may not hold true in the real life. IOW,\nsomething like this could be possible:\n\nBAD [PATCH] i386 boottime for_each_cpu broken\ngood [PATCH] i386: encapsulate copying of pgd entries\nbad [PATCH] x86 NMI: better support for debuggers\nBAD [PATCH] x86: introduce a write acessor for updating the current LDT\ngood [PATCH] x86: remove redundant TSS clearing\ngood [PATCH] x86: make IOPL explicit\nGOOD [PATCH] x86: privilege cleanup\n\nI marked the ones bisect told you to test in Capital letters, and a\ngood/bad which was never tested in lowercase. If the bug pattern is\nnot \"up to here everything is good but after that things start to\nbreak\", then bisect, by its nature of skipping the check to narrow the\nrange down fast, would miss the real transition from good to bad.\n"},{"id":"8248","messageId":"20050910022638.20832803.akpm@osdl.org","threadId":"1753","inReplyTo":"7virx9ir3a.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-bisect failure","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2005-09-10T09:26:38Z","receivedAt":"2005-09-10T09:26:38Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Junio C Hamano wrote:\n>\n> So it _might_\n> be possible that you said \"current LDT\" was bad when it was\n> actually good. That is one possible explanation.\n\nI agree. Mea culpa. Sorry.\n"},{"id":"8255","messageId":"Pine.LNX.4.58.0509101202070.30958@g5.osdl.org","threadId":"1753","inReplyTo":"20050910022638.20832803.akpm@osdl.org","subject":"Re: git-bisect failure","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-10T19:07:47Z","receivedAt":"2005-09-10T19:07:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Sep 2005, Andrew Morton wrote:\n>\n> Junio C Hamano wrote:\n> >\n> > So it _might_\n> > be possible that you said \"current LDT\" was bad when it was\n> > actually good. That is one possible explanation.\n> \n> I agree. Mea culpa. Sorry.\n\nWell, this was actually something I hit when testign bisection too: it \n_is_ very unforgiving of mistakes.\n\nThat _may_ be something fundamental (hey, the point of bisection is that\nyou can get a lot of work done thanks to the log2(n) behaviour, but it\nalso means that a mistake ends up being easily multiplied). But on the \nother hand, maybe there could be nicer interfaces.\n\nIn particular, I suspect that we should save off the sequence of good/bad \nmarkers, so that it can be more easily re-created. Right now we only track \nthe last \"bad\" marker, and we don't keep track of the order of the ones \nmarked good. That's technically _sufficient_ for the job, but maybe we \nshould have more of an audit trail.\n\nWith an audit trail, people could re-do the bisection if something goes \nwrong. Right now, if you by mistake mark something bad, and you \nimmediately realize that it was a mistake, you can't undo it - because the \nold bad state was overwritten.\n\nSo the bisection algorithm may have done the right thing from a technical \nstandpoint, but I suspect it could be made to be a bit more forgiving, or \nat least when somebody realizes that bisection didn't work right, we could \nhave the trail of good/bad markings to try to debug what happened...\n\n\t\tLinus\n"},{"id":"8256","messageId":"20050910141343.578649c7.akpm@osdl.org","threadId":"1753","inReplyTo":"Pine.LNX.4.58.0509101202070.30958@g5.osdl.org","subject":"Re: git-bisect failure","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2005-09-10T21:13:43Z","receivedAt":"2005-09-10T21:13:43Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Linus Torvalds wrote:\n>\n> On Sat, 10 Sep 2005, Andrew Morton wrote:\n> >\n> > Junio C Hamano wrote:\n> > >\n> > > So it _might_\n> > > be possible that you said \"current LDT\" was bad when it was\n> > > actually good. That is one possible explanation.\n> > \n> > I agree. Mea culpa. Sorry.\n> \n> Well, this was actually something I hit when testign bisection too: it \n> _is_ very unforgiving of mistakes.\n\nYes. That was my third attempt. You basically _have_ to write down the\ngood/bad sequence as you go. One slip and you've blown an hour's work.\n\n> So the bisection algorithm may have done the right thing from a technical \n> standpoint, but I suspect it could be made to be a bit more forgiving, or \n> at least when somebody realizes that bisection didn't work right, we could \n> have the trail of good/bad markings to try to debug what happened...\n\nYup. Simply keeping a little log file would suffice.\n"},{"id":"8257","messageId":"Pine.LNX.4.58.0509101428490.30958@g5.osdl.org","threadId":"1753","inReplyTo":"20050910141343.578649c7.akpm@osdl.org","subject":"Re: git-bisect failure","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-10T21:32:08Z","receivedAt":"2005-09-10T21:32:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Sep 2005, Andrew Morton wrote:\n> \n> Yup. Simply keeping a little log file would suffice.\n\nThis is a _very_ cheesy and untested patch.\n\nOh, btw, it also fixes \"git bisect reset\" - we used to remove the file \n\"refs/reads/bisect\", not \"refs/heads/bisect\". \n\nCheesy, cheesy, cheesy,\n\n\t\tLinus \"not proud\" Torvalds\n\n---\nSubject: Keep bisect event log\n\nThis keeps an event log in refs/bisect/log, which tracks what bisections \nhave been done. We could eventually have a \"git bisect replay\" or \nsomethign similar that actually uses it - for now we just have a command \nto show the log: \"git bisect log\".\n\nSigned-off-by: Linus Torvalds \n---\ndiff --git a/git-bisect.sh b/git-bisect.sh\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -8,7 +8,8 @@ git bisect bad []\t\tmark a kno\n git bisect good [...]\tmark ... known-good revisions.\n git bisect next\t\t\tfind next bisection to test and check it out.\n git bisect reset []\tfinish bisection search and go back to branch.\n-git bisect visualize show bisect status in gitk.'\n+git bisect visualize show bisect status in gitk.\n+git bisect log show bisect log.'\n exit 1\n }\n \n@@ -67,6 +68,7 @@ bisect_bad() {\n \t\tusage ;;\n \tesac || exit\n \techo \"$rev\" > \"$GIT_DIR/refs/bisect/bad\"\n+\techo \"bad $rev\" >> \"$GIT_DIR/refs/bisect/log\"\n \tbisect_auto_next\n }\n \n@@ -81,6 +83,7 @@ bisect_good() {\n \tdo\n \t\trev=$(git-rev-parse --verify \"$rev\") || exit\n \t\techo \"$rev\" >\"$GIT_DIR/refs/bisect/good-$rev\"\n+\t\techo \"good $rev\" >> \"$GIT_DIR/refs/bisect/log\"\n \tdone\n \tbisect_auto_next\n }\n@@ -149,7 +152,11 @@ bisect_reset() {\n \tesac\n \tgit checkout \"$branch\" &&\n \trm -fr \"$GIT_DIR/refs/bisect\"\n-\trm -f \"$GIT_DIR/refs/reads/bisect\"\n+\trm -f \"$GIT_DIR/refs/heads/bisect\"\n+}\n+\n+bisect_log() {\n+\tcat \"$GIT_DIR/refs/bisect/log\"\n }\n \n case \"$#\" in\n@@ -172,6 +179,8 @@ case \"$#\" in\n \tbisect_visualize \"$@\" ;;\n reset)\n bisect_reset \"$@\" ;;\n+ log)\n+ bisect_log \"$@\" ;;\n *)\n usage ;;\n esac\n"},{"id":"8258","messageId":"7vfyscfvoj.fsf@assigned-by-dhcp.cox.net","threadId":"1753","inReplyTo":"20050910141343.578649c7.akpm@osdl.org","subject":"Re: git-bisect failure","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-10T21:40:44Z","receivedAt":"2005-09-10T21:40:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n>> So the bisection algorithm may have done the right thing from a technical \n>> standpoint, but I suspect it could be made to be a bit more forgiving, or \n>> at least when somebody realizes that bisection didn't work right, we could \n>> have the trail of good/bad markings to try to debug what happened...\n>\n> Yup. Simply keeping a little log file would suffice.\n\nWill do. Thanks.\n"},{"id":"8259","messageId":"7vu0gsefld.fsf@assigned-by-dhcp.cox.net","threadId":"1753","inReplyTo":"7vfyscfvoj.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-bisect failure","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-10T22:13:34Z","receivedAt":"2005-09-10T22:13:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The one I am going to put in the \"master\" branch later today\nwill give you the attached transcript.\n\nHighlights:\n\n * After bisecting and checking out a revision to try out, it\n tells you which revision you are about to test.\n\n * It keeps a log in $GIT_DIR/BISECT_LOG as you suggested. This\n is a shell script so you can remove everything after you want\n to redo in an editor, save the result in a different file,\n and run it -- do not edit the file in place and run it\n because the re-run will overwrite the log file ;-).\n\n * Even better, 'git bisect' has a new command 'replay'. After\n editing the log file from the previous run and saving it in a\n different file, run 'git bisect replay $that_file'. This\n avoids checking things out repeatedly, only to overwrite with\n the next revision to be tested.\n\n: siamese; git-bisect reset \n: siamese; git-bisect good 02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b\nYou need to start by \"git bisect start\"\nDo you want me to do it for you [Y/n]? y\n: siamese; git-bisect bad 4e1491847ef5ca1c5a661601d5f96dcb7d90d2f0\nBisecting: 901 revisions left to test after this\n[b749bfcd1be72f8cb8310e1cac12825bda029432] ppc64: update xmon helptext\n: siamese; git-bisect good b749bfcd1be72f8cb8310e1cac12825bda029432\nBisecting: 451 revisions left to test after this\n[439c430e3d448b16112de3f3d92bef6ee2639d89] arm26: one -g is enough for everyone\n: siamese; git-bisect bad 439c430e3d448b16112de3f3d92bef6ee2639d89\nBisecting: 219 revisions left to test after this\n[fae91e72b79ba9a21f0ce7551a1fd7e8984c85a6] I2C: Drop I2C_DEVNAME and i2c_clientname\n: siamese; git-bisect bad fae91e72b79ba9a21f0ce7551a1fd7e8984c85a6\nBisecting: 110 revisions left to test after this\n[4c139862b8831261d57de02716b92f82e5fb463b] xtensa: delete accidental file\n: siamese; git-bisect bad 4c139862b8831261d57de02716b92f82e5fb463b\nBisecting: 55 revisions left to test after this\n[4ad8d38342430f8b52f7a8458dce90caf8c8ca64] i386 boottime for_each_cpu broken\n: siamese; git-bisect bad 4ad8d38342430f8b52f7a8458dce90caf8c8ca64\nBisecting: 28 revisions left to test after this\n[6fe7f2578fb4903af79abeb29bb9b9ab5eace1b5] mips: remove timex.h for vr41xx\n: siamese; git-bisect good 245067d1674d451855692fcd4647daf9fd47f82d\nBisecting: 7 revisions left to test after this\n[0998e4228aca046fbd747c3fed909791d52e88eb] x86: privilege cleanup\n: siamese; git-bisect good 0998e4228aca046fbd747c3fed909791d52e88eb\nBisecting: 3 revisions left to test after this\n[f2f30ebca6c0c95e987cb9a1fd1495770a75432e] x86: introduce a write acessor for updating the current LDT\n: siamese; git-bisect bad f2f30ebca6c0c95e987cb9a1fd1495770a75432e\nBisecting: 2 revisions left to test after this\n[e9f86e351fda5b3c40192fc3990453613f160779] x86: remove redundant TSS clearing\n: siamese; cat .git/BISECT_LOG \ngit-bisect start\n# good: [02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b] Linux v2.6.13\ngit-bisect good 02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b\n# bad: [4e1491847ef5ca1c5a661601d5f96dcb7d90d2f0] Fix up ARM serial driver compile failure\ngit-bisect bad 4e1491847ef5ca1c5a661601d5f96dcb7d90d2f0\n# good: [b749bfcd1be72f8cb8310e1cac12825bda029432] ppc64: update xmon helptext\ngit-bisect good b749bfcd1be72f8cb8310e1cac12825bda029432\n# bad: [439c430e3d448b16112de3f3d92bef6ee2639d89] arm26: one -g is enough for everyone\ngit-bisect bad 439c430e3d448b16112de3f3d92bef6ee2639d89\n# bad: [fae91e72b79ba9a21f0ce7551a1fd7e8984c85a6] I2C: Drop I2C_DEVNAME and i2c_clientname\ngit-bisect bad fae91e72b79ba9a21f0ce7551a1fd7e8984c85a6\n# bad: [4c139862b8831261d57de02716b92f82e5fb463b] xtensa: delete accidental file\ngit-bisect bad 4c139862b8831261d57de02716b92f82e5fb463b\n# bad: [4ad8d38342430f8b52f7a8458dce90caf8c8ca64] i386 boottime for_each_cpu broken\ngit-bisect bad 4ad8d38342430f8b52f7a8458dce90caf8c8ca64\n# good: [245067d1674d451855692fcd4647daf9fd47f82d] i386: cleanup serialize msr\ngit-bisect good 245067d1674d451855692fcd4647daf9fd47f82d\n# good: [0998e4228aca046fbd747c3fed909791d52e88eb] x86: privilege cleanup\ngit-bisect good 0998e4228aca046fbd747c3fed909791d52e88eb\n# bad: [f2f30ebca6c0c95e987cb9a1fd1495770a75432e] x86: introduce a write acessor for updating the current LDT\ngit-bisect bad f2f30ebca6c0c95e987cb9a1fd1495770a75432e\n: siamese; sed -e '$d' .git/BISECT_LOG >./++bisect-replay ;# botched the last one\n: siamese; git-bisect reset\n: siamese; sh ./++bisect-replay ;# we could replay with shell\nBisecting: 901 revisions left to test after this\n[b749bfcd1be72f8cb8310e1cac12825bda029432] ppc64: update xmon helptext\nBisecting: 451 revisions left to test after this\n[439c430e3d448b16112de3f3d92bef6ee2639d89] arm26: one -g is enough for everyone\nBisecting: 219 revisions left to test after this\n[fae91e72b79ba9a21f0ce7551a1fd7e8984c85a6] I2C: Drop I2C_DEVNAME and i2c_clientname\nBisecting: 110 revisions left to test after this\n[4c139862b8831261d57de02716b92f82e5fb463b] xtensa: delete accidental file\nBisecting: 55 revisions left to test after this\n[4ad8d38342430f8b52f7a8458dce90caf8c8ca64] i386 boottime for_each_cpu broken\nBisecting: 28 revisions left to test after this\n[6fe7f2578fb4903af79abeb29bb9b9ab5eace1b5] mips: remove timex.h for vr41xx\nBisecting: 7 revisions left to test after this\n[0998e4228aca046fbd747c3fed909791d52e88eb] x86: privilege cleanup\nBisecting: 3 revisions left to test after this\n[f2f30ebca6c0c95e987cb9a1fd1495770a75432e] x86: introduce a write acessor for updating the current LDT\n: siamese; git-bisect reset\n: siamese; git-bisect replay ./++bisect-replay ;# but replay command is faster.\nBisecting: 3 revisions left to test after this\n[f2f30ebca6c0c95e987cb9a1fd1495770a75432e] x86: introduce a write acessor for updating the current LDT\n: siamese; exit\n"}]}