You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Suresh Subbiah (JIRA)" <ji...@apache.org> on 2016/06/16 19:08:05 UTC

[jira] [Closed] (TRAFODION-2038) ERROR[2006] Internal error: assertion failure ((Int32)outputDataLen >= 0) during compile

     [ https://issues.apache.org/jira/browse/TRAFODION-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Suresh Subbiah closed TRAFODION-2038.
-------------------------------------

>  ERROR[2006] Internal error: assertion failure ((Int32)outputDataLen >= 0) during compile
> -----------------------------------------------------------------------------------------
>
>                 Key: TRAFODION-2038
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2038
>             Project: Apache Trafodion
>          Issue Type: Bug
>          Components: sql-cmp
>    Affects Versions: 1.3-incubating
>            Reporter: Suresh Subbiah
>            Assignee: Howard Qin
>             Fix For: 2.1-incubating
>
>
> When certain query with a long varchar column in a predicate are compiled we get the following error intermittently
> *** ERROR[2006] Internal error: assertion failure ((Int32)outputDataLen >= 0) in file ../exp/exp_conv.cpp at line 4557.
> Problem occurs when a SQL compiler gets a query that is similar to what it has seen before and can can therefore give a cached plan. The problem occurs when the plan is backpatched to account for differences (i.e. does not show on initial compile, or when query gets an identical text cache hit).
> It can be worked around with any one of these cqds, each one being more specific than previous one.
> cqd query_cache '0';
> cqd hybrid_query_cache 'off' ;
> cqd QUERY_CACHE_USE_CONVDOIT_FOR_BACKPATCH 'off' ;
> Analysis by Sandhya and Arvind is below.
> (0000897)
> ssubbiah	(developer) 
> 2016-06-06 14:14
> This issue needs another round of debugging but from the Qcache point of view. Here is what we found . The assertion failure happens at this point (highlightedin the expressions code exp/exp_conv.cpp.
> if (rc || (targetPrecision && targetPrecision < (Lng32) translatedCharCnt))
>         {
>           Lng32 canIgnoreOverflowChars = FALSE;
>           Lng32 remainingScanStringLen = 0;
>  
>           if (rc == 0)
>             {
>               // We failed because the target has too many characters. Find
>               // the first offending character.
>               input_to_scan = utf8Tgt;
>               input_length = outputDataLen;
>               outputDataLen = lightValidateUTF8Str(utf8Tgt,
>                                                    (Int32)outputDataLen,
>                                                    (Int32)targetPrecision,
>                                                    ignoreTrailingBlanksInSource);
>               assert((Int32)outputDataLen >= 0); //LCOV_EXCL_LINE : rfi
>  
>  
> The following is the stack trace when query cache is on :
>  
> #0 convCharToChar (source=0x7fd270730d50 "reason 25", sourceLen=9, 
>     sourceType=0, sourcePrecision=-1, sourceScale=1, 
>     target=0x7fd269d7231a "reason 25", targetLen=31999, targetType=64, 
>     targetPrecision=-1, targetScale=15, heap=0x0, diagsArea=0x0, 
>     dataConversionErrorFlag=0x7fd286fa9fc8, actualTargetLen=0x7fd286fa9cb8, 
>     blankPadResult=0, ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0)
>     at ../exp/exp_conv.cpp:4524
> 0000001 0x00007fd29657a34f in convDoIt (source=0x7fd270730d50 "reason 25", 
>     sourceLen=9, sourceType=0, sourcePrecision=-1, sourceScale=1, 
>     target=0x7fd269d7231a "reason 25", targetLen=31999, targetType=64, 
>     targetPrecision=-1, targetScale=15, varCharLen=0x7fd269d72318 "\t", 
>     varCharLenSize=2, heap=0x0, diagsArea=0x0, index=CONV_ASCII_F_V, 
>     dataConversionErrorFlag=0x7fd286fa9fc8, flags=0)
>     at ../exp/exp_conv.cpp:9272
> 0000002 0x00007fd29432b74f in CacheData::backpatchParams (this=0x7fd2ffffffff, 
>     listOfConstantParameters=..., 
>     listOfDynamicParameters=<value optimized out>, bindWA=..., 
>     params=@0x7fd286faa0d8, parameterBufferSize=@0x7fd286faa0f8)
>     at ../sqlcomp/QCache.cpp:1454
> 0000003 0x00007fd2941d216f in CmpMain::compileFromCache (this=0x7fd286fad8e0, 
>     sText=0x7fd270714da8 " SELECT SS_CUSTOMER_SK\n ,SUM(ACT_SALES) SUMSALES\n FROM (SELECT SS_ITEM_SK\n ,SS_TICKET_NUMBER\n ,SS_CUSTOMER_SK\n ,CASE WHEN SR_RETURN_QUANTITY IS NOT NULL THEN (SS_QUANTITY-SR_RETURN_QUANTITY)*SS_SALES_"..., 
> ---Type <return> to continue, or q <return> to quit---
>     charset=15, queryExpr=<value optimized out>, bindWA=..., cachewa=..., 
>     plan=0x7fd26c680a68, pLen=0x7fd26c680a60, heap=0x7fd285ad9440, op=3004, 
>     bPatchOK=@0x7fd286faca8c, begTime=...) at ../sqlcomp/CmpMain.cpp:1545
> 0000004 0x00007fd2941d7169 in CmpMain::compile (this=0x7fd286fad8e0, 
>     input_str=0x7fd270714da8 " SELECT SS_CUSTOMER_SK\n ,SUM(ACT_SALES) SUMSALES\n FROM (SELECT SS_ITEM_SK\n ,SS_TICKET_NUMBER\n ,SS_CUSTOMER_SK\n ,CASE WHEN SR_RETURN_QUANTITY IS NOT NULL THEN (SS_QUANTITY-SR_RETURN_QUANTITY)*SS_SALES_"..., charset=15, queryExpr=@0x7fd286fad818, gen_code=0x7fd26c680a68, 
>     gen_code_len=0x7fd26c680a60, heap=0x7fd285ad9440, phase=CmpMain::END, 
>     fragmentDir=0x7fd286fada38, op=3004, useQueryCache=1, 
>     cacheable=0x7fd286fad828, begTime=0x7fd286fad800, shouldLog=0)
>     at ../sqlcomp/CmpMain.cpp:1883
> 0000005 0x00007fd2941d9a4c in CmpMain::sqlcomp (this=0x7fd286fad8e0, 
>     input_str=0x7fd270714da8 " SELECT SS_CUSTOMER_SK\n ,SUM(ACT_SALES) SUMSALES\n FROM (SELECT SS_ITEM_SK\n ,SS_TICKET_NUMBER\n ,SS_CUSTOMER_SK\n ,CASE WHEN SR_RETURN_QUANTITY IS NOT NULL THEN (SS_QUANTITY-SR_RETURN_QUANTITY)*SS_SALES_"..., charset=15, queryExpr=@0x7fd286fad818, gen_code=0x7fd26c680a68, 
>     gen_code_len=0x7fd26c680a60, heap=0x7fd285ad9440, phase=CmpMain::END, 
>     fragmentDir=0x7fd286fada38, op=3004, useQueryCache=1, 
>     cacheable=0x7fd286fad828, begTime
>    
>  
>  
> See how targetPrecision is -1 in this case ? The targetType is coming from a list of parameters stored in the cache and our guess was something isn’t setup right for columns/datatypes in NABoolean CacheData::backpatchParams. Both explain of this query and the prepare of this query fail the same way. 
> A couple of things is that the cource has a space
> targetLen is 31999.
> targetPrecision = -1
> targetType=64
> VC Indicator Len is 2 bytes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)