Carlos Sánchez de La Lama
2012-Dec-11 08:00 UTC
[LLVMdev] Possible bug in DFAPacketizer::ReadTable
Hi Anshu, I got a testbench which fails (and segfaults) consistently with an environment (gcc + os) conveniently preserved in a virtual machine. I will confirm that it is gone there and report. Thanks for the fix :) Carlos 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org>> Carlos, > > I committed a fix in r169783. Thanks for catching this. > > However, I could not reproduce an invalid read or a segfault even with > fadd.ll. Is there a test case you can check in that reproduces this bug? > Even if the segfault occurs intermittently, that's better than no test case > at all. > > Thanks > > -Anshu > > --- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > > > On 12/10/2012 1:01 PM, Carlos Sánchez de La Lama wrote: > > Hi Anshu, > > no, I did not fill a bug report. It is not so easy to make the code fail > noticeably; during Hexagon CodeGen tests it happens silently and tests > pass. I am working on another VLIW backend which uses DFAPacketizer and > compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug > gets hidden again (it still happens, but values after DFAStateEntryTable in > memory are such that ReadTable does not break bad). > > If you find more info will help you track it down just let me know :) > > BR > > Carlos > > > 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > >> Hi Carlos, >> >> Thanks for identifying the bug. I'll confirm and fix. Is there a bug >> report open for this? >> >> -Anshu >> >> --- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> hosted by The Linux Foundation >> >> >> >> On 12/10/2012 4:48 AM, Carlos Sánchez de La Lama wrote: >> >> Hi all, >> >> I have found what I think it is a bug in DFAPacketizer::ReadTable. >> >> When finding NextStateInTable to cache all transitions belonging to a >> state into CachedTable, ReadTable does not check bounds: >> >> unsigned ThisState >> DFAStateEntryTable[state]; >> | >> unsigned NextStateInTable = DFAStateEntryTable[state+1]; >> >> which makes NextStateInTable get a random value when state == <last >> state in table>. Behaviour changes depending on gcc version / platform / >> ..., but in some cases might lead to segmentation faults. >> >> I have checked the problem happens in Hexagon tests (for example >> fadd.ll test) but does not break badly there (though CachedTable will get >> some unneded and random data rows). >> >> Probably making tblgen add an end-of-table marker in >> <Target>DFAStateEntryTable is the easiest solution. >> >> BR >> >> Carlos >> >> >> _______________________________________________ >> LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/ea67124b/attachment.html>
Carlos Sánchez de La Lama
2012-Dec-11 11:47 UTC
[LLVMdev] Possible bug in DFAPacketizer::ReadTable
Hi again, I can confirm r169783 fixes the problem. My testbench segfaulted in r169782 but works after your commit. We can close the issue. Thanks, Carlos 2012/12/11 Carlos Sánchez de La Lama <csanchezdll at gmail.com>> Hi Anshu, > > I got a testbench which fails (and segfaults) consistently with an > environment (gcc + os) conveniently preserved in a virtual machine. I will > confirm that it is gone there and report. > > Thanks for the fix :) > > > Carlos > > > 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > >> Carlos, >> >> I committed a fix in r169783. Thanks for catching this. >> >> However, I could not reproduce an invalid read or a segfault even with >> fadd.ll. Is there a test case you can check in that reproduces this bug? >> Even if the segfault occurs intermittently, that's better than no test case >> at all. >> >> Thanks >> >> -Anshu >> >> --- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by The Linux Foundation >> >> >> On 12/10/2012 1:01 PM, Carlos Sánchez de La Lama wrote: >> >> Hi Anshu, >> >> no, I did not fill a bug report. It is not so easy to make the code >> fail noticeably; during Hexagon CodeGen tests it happens silently and tests >> pass. I am working on another VLIW backend which uses DFAPacketizer and >> compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug >> gets hidden again (it still happens, but values after DFAStateEntryTable in >> memory are such that ReadTable does not break bad). >> >> If you find more info will help you track it down just let me know :) >> >> BR >> >> Carlos >> >> >> 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> >> >>> Hi Carlos, >>> >>> Thanks for identifying the bug. I'll confirm and fix. Is there a bug >>> report open for this? >>> >>> -Anshu >>> >>> --- >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>> hosted by The Linux Foundation >>> >>> >>> >>> On 12/10/2012 4:48 AM, Carlos Sánchez de La Lama wrote: >>> >>> Hi all, >>> >>> I have found what I think it is a bug in DFAPacketizer::ReadTable. >>> >>> When finding NextStateInTable to cache all transitions belonging to a >>> state into CachedTable, ReadTable does not check bounds: >>> >>> unsigned ThisState >>> DFAStateEntryTable[state]; >>> | >>> unsigned NextStateInTable = DFAStateEntryTable[state+1]; >>> >>> which makes NextStateInTable get a random value when state == <last >>> state in table>. Behaviour changes depending on gcc version / platform / >>> ..., but in some cases might lead to segmentation faults. >>> >>> I have checked the problem happens in Hexagon tests (for example >>> fadd.ll test) but does not break badly there (though CachedTable will get >>> some unneded and random data rows). >>> >>> Probably making tblgen add an end-of-table marker in >>> <Target>DFAStateEntryTable is the easiest solution. >>> >>> BR >>> >>> Carlos >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/b1e526f1/attachment.html>
Anshuman Dasgupta
2012-Dec-11 15:26 UTC
[LLVMdev] Possible bug in DFAPacketizer::ReadTable
Great! Can you please check in that test case or better still, a reduced version of that test. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation On 12/11/2012 5:47 AM, Carlos Sánchez de La Lama wrote:> Hi again, > > I can confirm r169783 fixes the problem. My testbench segfaulted in > r169782 but works after your commit. > > We can close the issue. > > Thanks, > > Carlos > > > 2012/12/11 Carlos Sánchez de La Lama <csanchezdll at gmail.com > <mailto:csanchezdll at gmail.com>> > > Hi Anshu, > > I got a testbench which fails (and segfaults) consistently with an > environment (gcc + os) conveniently preserved in a virtual > machine. I will confirm that it is gone there and report. > > Thanks for the fix :) > > > Carlos >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121211/5cb673b8/attachment.html>