Looks good to me. Please go ahead.

2012/4/9 Xiaojing Zhang <xiaojing70...@gmail.com>

>
> Hi,
>
>    Could a gatekeeper please help review the fix for bug954(
> http://bugs.open64.net/show_bug.cgi?id=954)?
>
>
> Bug954 is a segmentation fault in wgen. This error only happens in m32,
> not in m64.
>
> This case is a constructor of a derived class calling the constructor of
> its superclass to create object, and when expanding this call expression,
> the function WGEN_Expand_Expr may append the generated call wn to whirl
> tree and then return a null wn. And this segmentation happens when set
> rtype to such a null-wn.
>
> 1.  The cutdown test case:
>
> class CaretBoxLine;
>
> class CaretBoxIterator {
>
>   public:
>
>     CaretBoxLine *cbl;
>
>     CaretBoxLine *operator *() const { return cbl; }
>
> };
>
> class CaretBoxLine {
>
>   public:
>
>     CaretBoxIterator end()  {  }
>
> };
>
> class EditableCaretBoxIterator : public CaretBoxIterator {
>
>   public:
>
>     EditableCaretBoxIterator(CaretBoxIterator &lit, bool fromEnd) :
> CaretBoxIterator(fromEnd ? (*lit)->end() : (*lit)->end()){}
>
> };
>
> void foo(CaretBoxIterator &it)
>
> {
>
>   EditableCaretBoxIterator fbit(it,1);
>
>
> With debug compiler:
>
> openCC -m32  -O0 -c test.cpp
>
> Signal: Segmentation fault in Writing WHIRL file phase.
>
> Error: Signal Segmentation fault in phase Writing WHIRL file – processing
> aborted
>
> *** Internal stack backtrace:
>
>
> /fc/proj/ctires/open64/o64guru/OPEN64_X86_OPT/Thu/bits/lib/gcc-lib/x86_64-open64-linux/5.0/wgen42()[0x8141286]
>
>
> /fc/proj/ctires/open64/o64guru/OPEN64_X86_OPT/Thu/bits/lib/gcc-lib/x86_64-open64-linux/5.0/wgen42()[0x81422fb]
>
> openCC INTERNAL ERROR:
> /fc/proj/ctires/open64/o64guru/OPEN64_X86_OPT/Thu/bits/lib/gcc-lib/x86_64-open64-linux/5.0/wgen42
> died due to signal 4
>
>
> 2. Gspin tree dump
>
>
> GS_TARGET_EXPR
>
>         GS_COMPONENT_REF
>
>         GS_COND_EXPR
>
>                  <operand 0>
>
>                  GS_TARGET_EXPR
>
>                           GS_COMPONENT_REF
>
>                           GS_CALL_EXPR
>
>                                    GS_ADDR_EXPR
>
>                                    GS_TREE_LIST
>
>                  GS_TARGET_EXP
>
>                           GS_COMPONENT_REF
>
>                           GS_CALL_EXPR
>
>                                    GS_ADDR_EXPR
>
>                                    GS_TREE_LIST
>
>  gspin tree of a simpler case(remove the condition expression “fromEnd ?”
> in line13) is below:
>
> GS_TARGET_EXPR
>
>          GS_COMPONENT_REF
>
>          GS_CALL_EXPR
>
>                   GS_ADDR_EXPR
>
>                   GS_TREE_LIST
>
>                            GS_ADDR_EXPR
>
>                            GS_TREE_LIST
>
>
> 3. Analysis
>
> In this case,the return WN of WGEN_Expand_Expr is a NULL-WN, so it got a
> segmentation fault when we set rtype for the null wn.
>
> >>In Wgen_expr.cxx:6511 ( t is a GS_CALL_EXPR, which is a call of
> constructor “CaretBoxIterator” )
>
>                 WN *target_wn = WGEN_Address_Of(opnd0);
>
>                 WN *result_wn = WGEN_Expand_Expr (t, TRUE /* for
> return_in_mem*/,
>
>   =>                                              0, 0, 0, 0, FALSE,
> FALSE, target_wn);
>
>                 wn = result_wn;
>
>                 WN_set_rtype(wn, MTYPE_V);
>
>                 break;
>
> But for this case, if we remove the condition expression “fromEnd ?” in
> line13, the issues could not reproduce. In this simpler case, the  RETURN
> *result_wn is also NULL, and the two cases have the same GS_CALL_EXPR, and
> then it is expanded to the same call_wn, and return a null-wn in function
> WGEN_Expand_Expr when expand this expression.
>
> >>In Wgen_expr.cxx:6541
>
>                 WN *target_wn = WN_Lda (Pointer_Mtype, 0, st, 0);
>
>                 WN *result_wn = WGEN_Expand_Expr (t, TRUE, 0, 0, 0, 0,
> FALSE,
>
>   =>                                             FALSE, target_wn);
>
>                 if (result_wn) {
>
>                   if (WN_operator(result_wn) == OPR_ILOAD ||
>
>                       WN_operator(result_wn) == OPR_LDID) {
>
>                     WGEN_Stmt_Append(WN_Stid (mtype, ST_ofst(st), st, ty,
>
>                                     result_wn), Get_Srcpos());
>
>                   } else if (WN_operator(result_wn) == OPR_CSELECT) {
>
>                     WN *wn = WN_CreateEval(result_wn);
>
>                     WGEN_Stmt_Append(wn, Get_Srcpos());
>
>                   }
>
>                 }
>
>
> 4. Patch
>
> Index: osprey/wgen/wgen_expr.cxx
>
> ===================================================================
>
> --- osprey/wgen/wgen_expr.cxx   (revision 3895)
>
> +++ osprey/wgen/wgen_expr.cxx   (working copy)
>
> @@ -6508,8 +6508,10 @@
>
>                WN *target_wn = WGEN_Address_Of(opnd0);
>
>                WN *result_wn = WGEN_Expand_Expr (t, TRUE /* for
> return_in_mem*/,
>
>                                                  0, 0, 0, 0, FALSE, FALSE,
> target_wn);
>
> +              if (result_wn != NULL) {
>
>                wn = result_wn;
>
>                WN_set_rtype(wn, MTYPE_V);
>
> +              }
>
>                break;
>
>              }
>
>            }
>
>
> 5.  Explanation
>
> In m32, the gs_aggregate_value_p(GS_RECORD_TYPE) is  true, so the TY of
> CaretBoxIterator is set to return_in_mem, and in wgen_expr.cxx, the
> function WGEN_Expand_Expr will go to append the call_wn and then return a
> null wn, but in m64, the gs_aggregate_value_p(GS_RECORD_TYPE) is not true,
> the function WGEN_Expand_Expr will do some extra process, and then get a wn
> later, so m64 didn’t have this segmentation fault.
>
>
> ------
>
> Regards
> Zhang Xiao-Jing
>
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>


-- 
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to