I don’t know yet, but I will let you know as soon as I can. On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote:> On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> No, not that I am aware of. > > So, if my commits did indeed trigger the failures it could be > something like binary size change that caused different code alignment > or some such > and which triggered a latent memory bug somewhere else. > > It's already late evening for you now. Will you have a chance to > reapply changes today? > > --kcc > >> >> On Nov 14, 2013, at 10:15 PM, Kostya Serebryany <kcc at google.com> wrote: >> >>> On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>>> The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. >>> >>> Is AddressSanitizer involved in any of the stages of the LTO build? >>> >>>> >>>> On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> wrote: >>>> >>>>> What are the symptoms? >>>>> >>>>> On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>>>>> I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer. >>>>>> >>>>>> I don’t have any other useful information at this point, and I share your puzzlement about how your changes could possibly break the compiler. My only hypothesis is some sort of memory corruption. >>>>>> >>>>>> I will keep you posted. >>>>>> >>>>>> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote: >>>>>> >>>>>>> Also, when are you planing to "reapply the changes or help debug"? >>>>>>> >>>>>>> On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote: >>>>>>>> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>>>>>>>> Hi Kostya, >>>>>>>>> >>>>>>>>> Thanks for the heads-up on this. I haven’t had a chance to look into the >>>>>>>>> details yet, but it looks like these patches may be breaking our >>>>>>>>> bootstrapped LTO build. Our buildbots have been failing all day, and we’re >>>>>>>>> still trying to figure out the problem. I’m going to speculatively revert >>>>>>>>> those changes, since they were the only patches on the buildbot blame list. >>>>>>>>> I will either reapply the changes or help debug the problem. >>>>>>>> >>>>>>>> How could this possibly affect your LTO build? >>>>>>>> The option is off by default. >>>>>>>> Do you have any details, logs, etc? >>>>>>>> >>>>>>>>> >>>>>>>>> —Bob >>>>>>>>> >>>>>>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>>>>>>>> >>>>>>>>> Bob, Justin, >>>>>>>>> >>>>>>>>> I've just committed a poor man's coverage implementation that works with >>>>>>>>> asan. >>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>>>>>>>> It provides only function-level boolean coverage (i.e. no counters, just >>>>>>>>> "visited or not"), >>>>>>>>> but is very fast and very simple (no extra sections to the binary file, etc) >>>>>>>>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>>>>>>>> overhead >>>>>>>>> is negligible at both run-time and shutdown-time. >>>>>>>>> >>>>>>>>> We'll be evaluating this implementation and collecting usage stats. >>>>>>>>> Maybe we want to implement something simple like this in the Clang coverage. >>>>>>>>> >>>>>>>>> --kcc >>>>>>>>> >>>>>>>>> >>>>>> >>>> >>
FYI I've seen what looked like a memory corruption in (private) Clang bootstrap process long before Kostya's changes were submitted. I hope I'll have the chance to investigate it soon. On Fri, Nov 15, 2013 at 10:20 AM, Bob Wilson <bob.wilson at apple.com> wrote:> I don’t know yet, but I will let you know as soon as I can. > > On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> > wrote: > >> No, not that I am aware of. > > > > So, if my commits did indeed trigger the failures it could be > > something like binary size change that caused different code alignment > > or some such > > and which triggered a latent memory bug somewhere else. > > > > It's already late evening for you now. Will you have a chance to > > reapply changes today? > > > > --kcc > > > >> > >> On Nov 14, 2013, at 10:15 PM, Kostya Serebryany <kcc at google.com> wrote: > >> > >>> On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> > wrote: > >>>> The bit code file produced by the stage 1 compiler for one of the > files in the clang driver is corrupt and causes the linker for stage 2 to > crash. > >>> > >>> Is AddressSanitizer involved in any of the stages of the LTO build? > >>> > >>>> > >>>> On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> > wrote: > >>>> > >>>>> What are the symptoms? > >>>>> > >>>>> On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> > wrote: > >>>>>> I’m waiting to see if this fixes the buildbots. Unfortunately, > because they were failing all day, there are a bunch of other regressions > that have come up, and I’m still working through them. It takes quite a > while to run a bootstrapped LTO clang build, so it will take a while longer. > >>>>>> > >>>>>> I don’t have any other useful information at this point, and I > share your puzzlement about how your changes could possibly break the > compiler. My only hypothesis is some sort of memory corruption. > >>>>>> > >>>>>> I will keep you posted. > >>>>>> > >>>>>> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> > wrote: > >>>>>> > >>>>>>> Also, when are you planing to "reapply the changes or help debug"? > >>>>>>> > >>>>>>> On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> > wrote: > >>>>>>>> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> > wrote: > >>>>>>>>> Hi Kostya, > >>>>>>>>> > >>>>>>>>> Thanks for the heads-up on this. I haven’t had a chance to look > into the > >>>>>>>>> details yet, but it looks like these patches may be breaking our > >>>>>>>>> bootstrapped LTO build. Our buildbots have been failing all > day, and we’re > >>>>>>>>> still trying to figure out the problem. I’m going to > speculatively revert > >>>>>>>>> those changes, since they were the only patches on the buildbot > blame list. > >>>>>>>>> I will either reapply the changes or help debug the problem. > >>>>>>>> > >>>>>>>> How could this possibly affect your LTO build? > >>>>>>>> The option is off by default. > >>>>>>>> Do you have any details, logs, etc? > >>>>>>>> > >>>>>>>>> > >>>>>>>>> —Bob > >>>>>>>>> > >>>>>>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> > wrote: > >>>>>>>>> > >>>>>>>>> Bob, Justin, > >>>>>>>>> > >>>>>>>>> I've just committed a poor man's coverage implementation that > works with > >>>>>>>>> asan. > >>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev > >>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev > >>>>>>>>> It provides only function-level boolean coverage (i.e. no > counters, just > >>>>>>>>> "visited or not"), > >>>>>>>>> but is very fast and very simple (no extra sections to the > binary file, etc) > >>>>>>>>> I've tried it for Chrome's content_shell (huge and heavy binary) > and the > >>>>>>>>> overhead > >>>>>>>>> is negligible at both run-time and shutdown-time. > >>>>>>>>> > >>>>>>>>> We'll be evaluating this implementation and collecting usage > stats. > >>>>>>>>> Maybe we want to implement something simple like this in the > Clang coverage. > >>>>>>>>> > >>>>>>>>> --kcc > >>>>>>>>> > >>>>>>>>> > >>>>>> > >>>> > >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131115/58ca335c/attachment.html>
Yes. I'm seeing this as well and it predates Kostya's change. Shows up as memory corruption or double free on Linux. On Nov 14, 2013 10:46 PM, "Alexey Samsonov" <samsonov at google.com> wrote:> FYI I've seen what looked like a memory corruption in (private) Clang > bootstrap process long before Kostya's changes were submitted. I hope I'll > have the chance to investigate it soon. > > > On Fri, Nov 15, 2013 at 10:20 AM, Bob Wilson <bob.wilson at apple.com> wrote: > >> I don’t know yet, but I will let you know as soon as I can. >> >> On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote: >> >> > On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> >> wrote: >> >> No, not that I am aware of. >> > >> > So, if my commits did indeed trigger the failures it could be >> > something like binary size change that caused different code alignment >> > or some such >> > and which triggered a latent memory bug somewhere else. >> > >> > It's already late evening for you now. Will you have a chance to >> > reapply changes today? >> > >> > --kcc >> > >> >> >> >> On Nov 14, 2013, at 10:15 PM, Kostya Serebryany <kcc at google.com> >> wrote: >> >> >> >>> On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> >> wrote: >> >>>> The bit code file produced by the stage 1 compiler for one of the >> files in the clang driver is corrupt and causes the linker for stage 2 to >> crash. >> >>> >> >>> Is AddressSanitizer involved in any of the stages of the LTO build? >> >>> >> >>>> >> >>>> On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> >> wrote: >> >>>> >> >>>>> What are the symptoms? >> >>>>> >> >>>>> On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> >> wrote: >> >>>>>> I’m waiting to see if this fixes the buildbots. Unfortunately, >> because they were failing all day, there are a bunch of other regressions >> that have come up, and I’m still working through them. It takes quite a >> while to run a bootstrapped LTO clang build, so it will take a while longer. >> >>>>>> >> >>>>>> I don’t have any other useful information at this point, and I >> share your puzzlement about how your changes could possibly break the >> compiler. My only hypothesis is some sort of memory corruption. >> >>>>>> >> >>>>>> I will keep you posted. >> >>>>>> >> >>>>>> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> >> wrote: >> >>>>>> >> >>>>>>> Also, when are you planing to "reapply the changes or help debug"? >> >>>>>>> >> >>>>>>> On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany < >> kcc at google.com> wrote: >> >>>>>>>> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson < >> bob.wilson at apple.com> wrote: >> >>>>>>>>> Hi Kostya, >> >>>>>>>>> >> >>>>>>>>> Thanks for the heads-up on this. I haven’t had a chance to >> look into the >> >>>>>>>>> details yet, but it looks like these patches may be breaking our >> >>>>>>>>> bootstrapped LTO build. Our buildbots have been failing all >> day, and we’re >> >>>>>>>>> still trying to figure out the problem. I’m going to >> speculatively revert >> >>>>>>>>> those changes, since they were the only patches on the buildbot >> blame list. >> >>>>>>>>> I will either reapply the changes or help debug the problem. >> >>>>>>>> >> >>>>>>>> How could this possibly affect your LTO build? >> >>>>>>>> The option is off by default. >> >>>>>>>> Do you have any details, logs, etc? >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> —Bob >> >>>>>>>>> >> >>>>>>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> >> wrote: >> >>>>>>>>> >> >>>>>>>>> Bob, Justin, >> >>>>>>>>> >> >>>>>>>>> I've just committed a poor man's coverage implementation that >> works with >> >>>>>>>>> asan. >> >>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >> >>>>>>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >> >>>>>>>>> It provides only function-level boolean coverage (i.e. no >> counters, just >> >>>>>>>>> "visited or not"), >> >>>>>>>>> but is very fast and very simple (no extra sections to the >> binary file, etc) >> >>>>>>>>> I've tried it for Chrome's content_shell (huge and heavy >> binary) and the >> >>>>>>>>> overhead >> >>>>>>>>> is negligible at both run-time and shutdown-time. >> >>>>>>>>> >> >>>>>>>>> We'll be evaluating this implementation and collecting usage >> stats. >> >>>>>>>>> Maybe we want to implement something simple like this in the >> Clang coverage. >> >>>>>>>>> >> >>>>>>>>> --kcc >> >>>>>>>>> >> >>>>>>>>> >> >>>>>> >> >>>> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > -- > Alexey Samsonov, MSK > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131114/e8fa2370/attachment.html>