[LLVMdev] Possible bug in DFAPacketizer::ReadTable

[Anshuman Dasgupta]

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>