Carlos Sánchez de La Lama
2012-Dec-10 19:01 UTC
[LLVMdev] Possible bug in DFAPacketizer::ReadTable
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/20121210/4b8f0f49/attachment.html>
Anshuman Dasgupta
2012-Dec-10 22:50 UTC
[LLVMdev] Possible bug in DFAPacketizer::ReadTable
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 > <mailto: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 list >> LLVMdev at cs.uiuc.edu <mailto: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/20121210/fbd0f641/attachment.html>
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>