[LLVMdev] Possible bug in DFAPacketizer::ReadTable

[Carlos Sánchez de La Lama]

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>