bug: attempt to multiply with overflow in cast string to date

[andygrove]

Describe the bug

Query works in Spark, fails in Comet. I discovered this bug using Comet Fuzz.

SELECT year(c8) FROM test0

Query failed in Comet: Job aborted due to stage failure: Task 14 in stage 639.0 failed 1 times, most recent failure: Lost task 14.0 in stage 639.0 (TID 5218) (192.168.86.33 executor driver): org.apache.comet.CometNativeException: attempt to multiply with overflow

Steps to reproduce

No response

Expected behavior

No response

Additional context

No response

[eejbyfeldt]

I will look into this one.

[andygrove]

@eejbyfeldt the bug is actually with casting from string to date with invalid inputs (I suspect the issue is strings with many digitis). I am working on fileing a new issue with more detail.

[andygrove]

I think -4607172990231812908 is a good example of an input string that can cause this

[andygrove]

Stack trace:

        at core::panicking::panic(/rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:144)
        at comet::execution::datafusion::expressions::cast::date_parser(/Users/andy/git/apache/datafusion-comet/core/src/execution/datafusion/expressions/cast.rs:1609)
        at comet::execution::datafusion::expressions::cast::Cast::cast_string_to_date(/Users/andy/git/apache/datafusion-comet/core/src/execution/datafusion/expressions/cast.rs:730)

This is the failing line:

            current_segment_value = current_segment_value * 10 + parsed_value;

[eejbyfeldt]

@andygrove Then there is more than one issue. I also recreated a similar crash using the date 290000-01-01 inside a timestamp. Spark will correctly return the year given this date, but comet crashes.

Stack trace:

        at comet::parquet::read::values::<impl comet::parquet::read::PlainDecoding for comet::parquet::data_type::Int96TimestampMicrosType>::decode(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/read/values.rs:800)
        at <comet::parquet::read::values::PlainDecoder<T> as comet::parquet::read::values::Decoder>::read_batch(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/read/values.rs:853)
        at <comet::parquet::read::values::PlainDecoder<T> as comet::parquet::read::values::Decoder>::read(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/read/values.rs:844)
        at comet::parquet::read::levels::LevelDecoder::read_batch(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/read/levels.rs:135)
        at comet::parquet::read::column::TypedColumnReader<T>::read_batch(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/read/column.rs:546)
        at comet::parquet::read::column::ColumnReader::read_batch(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/read/column.rs:444)
        at comet::parquet::Java_org_apache_comet_parquet_Native_readBatch::{{closure}}(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/parquet/mod.rs:508)
        at comet::errors::curry::{{closure}}(/home/eejbyfeldt/dev/apache/datafusion-comet/core/src/errors.rs:442)
        at std::panicking::try::do_call(/rustc/ec08a0337f3556212525dbf1d3b41e19bdf27621/library/std/src/panicking.rs:526)

Even if the overflow is fixed at that location full support might not be easy as that date is out of range for what is supported by chrono::DateTime: https://docs.rs/chrono/latest/chrono/naive/struct.NaiveDate.html so the existing code using that will be unable to return the date. If one allows the overflow at the first location (or runs in release mode) it instead crashes here:

datafusion-comet/core/src/execution/datafusion/expressions/utils.rs

Line 178 in 24781fb

let datetime = as_datetime::<TimestampMicrosecondType>(value).unwrap();

since that code assumes that all timestamps will be possible to represent in the chrono type.