llvm dev - Dec 2012 - [LLVMdev] Possible bug in DFAPacketizer::ReadTable

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121210/3f120f7e/attachment.html>

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         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/5530a142/attachment.html>

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>