[
https://issues.apache.org/jira/browse/IMPALA-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106954#comment-17106954
]
Akos Kovacs commented on IMPALA-7833:
-------------------------------------
I have checked all the string functions with the following result:
* lpad / rpad / space could crash impalad in case the output string was longer
than the uint limit of 4gig -> added overflow check and test cases
* I could also crash impalad with concatws / concat, but in this case I needed
a non-constant argument to avoid JVM OOM. Test case and overflow check added.
* replace, base64encode, base64decode and regex_escape handled large strings
correctly
> Audit and fix other string builtins for long string handling
> ------------------------------------------------------------
>
> Key: IMPALA-7833
> URL: https://issues.apache.org/jira/browse/IMPALA-7833
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 2.11.0, Impala 3.0, Impala 3.1.0
> Reporter: Tim Armstrong
> Assignee: Akos Kovacs
> Priority: Major
> Labels: crash, ramp-up
>
> Following on from IMPALA-7822, there are some other string builtins that seem
> to follow the same pattern of having a string size overflow an int passed
> into the StringVal constructor. I think in some cases we get lucky and it
> works out, but others it seems possible to crash given the right input
> values.
> Here are some examples of cases where we can hit such bugs:
> {noformat}
> select lpad('foo', 17179869184 , ' ');
> select rpad('foo', 17179869184 , ' ');
> select space(17179869184 );
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
