[cfe-dev] Uninitialized Variables Analysis crashing

João Paulo Labegalini de Carvalho via cfe-dev cfe-dev at lists.llvm.org
Mon Sep 24 15:26:09 PDT 2018


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> 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> 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> 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
> joao.carvalho at ic.unicamp.br
> j160924 at dac.unicamp.br
>
> _______________________________________________
> cfe-dev mailing listcfe-dev at lists.llvm.orghttp://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
joao.carvalho at ic.unicamp.br
j160924 at dac.unicamp.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180924/2dc2107d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ast-dump.txt.tgz
Type: application/x-compressed-tar
Size: 26082 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180924/2dc2107d/attachment.bin>


More information about the cfe-dev mailing list