No, not that I am aware of. 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 >>>>>>> >>>>>>> >>>> >>
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 >>>>>>>> >>>>>>>> >>>>> >>> >
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 >>>>>>>>> >>>>>>>>> >>>>>> >>>> >>