[cfe-dev] Uninitialized Variables Analysis crashing
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Tue Sep 25 10:47:46 PDT 2018
Remote debugging is hard, but here's something i notice: i don't think
you can declare multiple variables of different types in the same
DeclStmt. Eg., you can do `int x = 1, *y = 0;`, but you can't do `int x
= 1, unsigned y = 0;`. Could you try to produce a separate DeclStmt for
every VarDecl and see if it helps?
If it doesn't, can i also have a look at the CFG? Just do CFG.dump().
On 9/24/18 3:26 PM, João Paulo Labegalini de Carvalho wrote:
> Artem,
>
> First of all, thank you for your reply.
>
> Indeed, I am auto-generating AST made of regular nodes. More
> specifically, my SpecStmt node has four sub-nodes. A DeclStmt that I
> use to hang the variables a need, a Expr to compare __spec_mode and
> decide which path to take (SlowPath or FastPath) and two
> CompoundStmts. So SpecStmt looks like an IfStmt with both then and
> else statements.
>
> Bellow is the part of the AST which triggers the sigsegv (Please find
> the AST for the whole FunctionDecl attached):
>
> | | |-*SpecStmt* 0x15c1ca8 <./spec.h:127:32>
> | | | |-DeclStmt 0x15c09e8 <col:32>
> | | | | |-VarDecl 0x15c0368 <col:32> col:32
> *__setjmp_buf* 'jmp_buf':'struct __jmp_buf_tag [1]' auto
> | | | | |-VarDecl 0x15c03c8 <col:32> col:32
> *__setjmp_ret* 'int' auto cinit
> | | | | | `-CallExpr 0x15c0630 <col:32> 'int'
> | | | | | |-ImplicitCastExpr 0x15c0618 <col:32> 'int
> (*)(jmp_buf *)' <FunctionToPointerDecay>
> | | | | | | `-DeclRefExpr 0x15c05e0 <col:32> 'int (jmp_buf
> *)' Function 0x15c04d8 '*setjmp*' 'int (jmp_buf *)'
> | | | | | `-ImplicitCastExpr 0x15c0450 <col:32> 'jmp_buf *'
> <ArrayToPointerDecay>
> | | | | | `-DeclRefExpr 0x15c0428 <col:32>
> 'jmp_buf':'struct __jmp_buf_tag [1]' Var 0x15c0368 '*__setjmp_buf*'
> 'jmp_buf':'struct __jmp_buf_tag [1]'
> | | | | `-VarDecl 0x15c0660 <col:32> col:32
> *__spec_mode* 'unsigned int' auto cinit
> | | | | `-CallExpr 0x15c0990 <col:32> 'unsigned int'
> | | | | |-ImplicitCastExpr 0x15c0978 <col:32> 'unsigned
> int (*)(jmp_buf *, int)' <FunctionToPointerDecay>
> | | | | | `-DeclRefExpr 0x15c0940 <col:32> 'unsigned int
> (jmp_buf *, int)' Function 0x15c07d0 '*__spec_begin*' 'unsigned int
> (jmp_buf *, int)'
> | | | | |-ImplicitCastExpr 0x15c0730 <col:32> 'jmp_buf *'
> <LValueToRValue>
> | | | | | `-UnaryOperator 0x15c06e8 <col:32> 'jmp_buf *'
> prefix '&'
> | | | | | `-DeclRefExpr 0x15c06c0 <col:32>
> 'jmp_buf':'struct __jmp_buf_tag [1]' Var 0x15c0368
> '*__setjmp_buf'* 'jmp_buf':'struct __jmp_buf_tag [1]'
> | | | | `-ImplicitCastExpr 0x15c0748 <col:32> 'int'
> <LValueToRValue>
> | | | | `-DeclRefExpr 0x15c0708 <col:32> 'int' Var
> 0x15c03c8 '*__setjmp_ret*' 'int'
> | | | |-BinaryOperator 0x15c0a60 <col:32> 'bool' lvalue '=='
> | | | | |-ImplicitCastExpr 0x15c0a28 <col:32> 'unsigned int'
> <LValueToRValue>
> | | | | | `-DeclRefExpr 0x15c0a00 <col:32> 'unsigned int'
> lvalue Var 0x15c0660 '*__spec_mode'* 'unsigned int'
> | | | | `-IntegerLiteral 0x15c0a40 <col:32> 'int' 1
> | | | |-CompoundStmt 0x15c1c38 <col:32>
>
>
> Thanks in advance for any help!
>
> Respectfully,
>
> On Mon, Sep 24, 2018 at 4:36 PM Artem Dergachev <noqnoqneo at gmail.com
> <mailto:noqnoqneo at gmail.com>> wrote:
>
> Is the DeclRefExpr for __spec_mode pointing to a valid VarDecl?
> Would this VarDecl be encountered previously during analysis in
> order to populate TransferFunctions::vals()? Dunno if that makes
> sense, i didn't really look at this analysis.
>
> I guess i want to look at your full -ast-dump. It seems that you
> are not only adding a new Stmt kind, but also you're getting into
> business of auto-generating AST made of some regular nodes,
> probably as its children. This is often hard because it's very
> easy to break invariants that the normal AST obeys and there's no
> way to verify those invariants other than seeing how everything
> crashes and debugging.
>
> On 9/24/18 4:43 AM, João Paulo Labegalini de Carvalho via cfe-dev
> wrote:
>> You are right, I should have been more specific. In my case
>> crashing means segmentation fault inside runOnBlock function
>> (lib/Analysis/UninitializedValues.cpp).
>>
>> Please find the stack trace attached.
>>
>> On Mon, Sep 24, 2018 at 4:09 AM Csaba Raduly <rcsaba at gmail.com
>> <mailto:rcsaba at gmail.com>> wrote:
>>
>> Hi João Paulo,
>>
>>
>> On Sun, Sep 23, 2018 at 11:39 PM, João Paulo Labegalini de
>> Carvalho
>> via cfe-dev <cfe-dev at lists.llvm.org
>> <mailto:cfe-dev at lists.llvm.org>> wrote:
>> > Hi,
>> >
>> > I have implemented a new Stmt in clang which given
>> >
>> > __speculate {
>> > // user code
>> > }
>> >
>> > generates LLVM IR equivalent to as if the following code
>> was given:
>> >
>> ...
>> >
>> > However, if UninitializedVariablesAnalysis is enabled,
>> clang crashes at
>> > runOnBlock function (lib/Analysis/UninitializedValues.cpp).
>> If I disable it
>> > via -Wno-uninitialized, the code generated runs flawlessly
>> and works as
>> > expected.
>>
>> "crash" is a meaningless term. Does it generate an access
>> violation,
>> an assertion failure, or something else?
>> What was the error message? Is there a stack trace?
>>
>>
>> Csaba
>>
>> --
>> You can get very substantial performance improvements
>> by not doing the right thing. - Scott Meyers, An Effective
>> C++11/14 Sampler
>> So if you're looking for a completely portable, 100%
>> standards-conformat way
>> to get the wrong information: this is what you want. - Scott
>> Meyers (C++TDaWYK)
>>
>>
>>
>> --
>> João Paulo L. de Carvalho
>> Computer Science | IC-UNICAMP | Campinas , SP - Brazil
>> jaopaulolc at gmail.com <mailto:jaopaulolc at gmail.com>
>> joao.carvalho at ic.unicamp.br <mailto:joao.carvalho at ic.unicamp.br>
>> j160924 at dac.unicamp.br <mailto:j160924 at dac.unicamp.br>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> --
> João Paulo L. de Carvalho
> Computer Science | IC-UNICAMP | Campinas , SP - Brazil
> jaopaulolc at gmail.com <mailto:jaopaulolc at gmail.com>
> joao.carvalho at ic.unicamp.br <mailto:joao.carvalho at ic.unicamp.br>
> j160924 at dac.unicamp.br <mailto:j160924 at dac.unicamp.br>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180925/9f12a31f/attachment.html>
More information about the cfe-dev
mailing list