Crash when making a choice between fixed array and map with int keys #197
Description
I'm trying to validate the following CDDL schema:
Ref = nil / refShort / refFull
blobSize = uint
hashID = uint .lt 23
hashName = text
hashDigest = bytes
refShort = [ blobSize, hashID, hashDigest ]
refFull = { 1: blobSize, 2: hashName, 3: hashDigest }
against the following CBOR test data (sample 1).
Sample 1 (array)
Data in hex
8303025820ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
CBOR structure
[3, 2, h'BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD']
CBOR encoding
83 # array(3)
03 # unsigned(3)
02 # unsigned(2)
58 20 # bytes(32)
BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD
In theory, this data should match the refShort type. However it currently leads to a crash.
Crash details
Version: cddl 0.9.1
Stack trace
[INFO] Root type for validation: Ref
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/validator/cbor.rs:3372:23
stack backtrace:
0: 0x55ee6fd65732 - std::backtrace_rs::backtrace::libunwind::trace::h9135f25bc195152c
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x55ee6fd65732 - std::backtrace_rs::backtrace::trace_unsynchronized::h015ee85be510df51
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x55ee6fd65732 - std::sys_common::backtrace::_print_fmt::h5fad03caa9652a2c
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:66:5
3: 0x55ee6fd65732 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h2b42ca28d244e5c7
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:45:22
4: 0x55ee6fccdaac - core::fmt::write::h401e827d053130ed
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/fmt/mod.rs:1198:17
5: 0x55ee6fd45e20 - std::io::Write::write_fmt::hffec93268f5cde32
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/io/mod.rs:1672:15
6: 0x55ee6fd661a3 - std::sys_common::backtrace::_print::h180c4c706ee1d3fb
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:48:5
7: 0x55ee6fd661a3 - std::sys_common::backtrace::print::hd0c35d18765761c9
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:35:9
8: 0x55ee6fd661a3 - std::panicking::default_hook::{{closure}}::h1f023310983bc730
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:295:22
9: 0x55ee6fd6688d - std::panicking::default_hook::h188fec3334afd5be
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:314:9
10: 0x55ee6fd6688d - std::panicking::rust_panic_with_hook::hf26e9d4f97b40096
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:698:17
11: 0x55ee6fd6646b - std::panicking::begin_panic_handler::{{closure}}::hfab912107608087a
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:586:13
12: 0x55ee6fd66406 - std::sys_common::backtrace::__rust_end_short_backtrace::h434b685ce8d9965b
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:138:18
13: 0x55ee6fd663c2 - rust_begin_unwind
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
14: 0x55ee6fbf1542 - core::panicking::panic_fmt::ha6dc7f2ab2479463
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
15: 0x55ee6fbf163c - core::panicking::panic::hb3ad04c589a0e3c8
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
16: 0x55ee6fc12b1d - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_value::h7840d5f21197cc59
17: 0x55ee6fc81673 - cddl::visitor::walk_group_entry::hb386b0c8c89edab7
18: 0x55ee6fc137fd - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_group::h0bfb35869faade31
19: 0x55ee6fc10967 - cddl::validator::cbor::CBORValidator::validate_array_items::h64868ec22fb7c7e1
20: 0x55ee6fc1b36a - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_type2::hab70cfcda276224c
21: 0x55ee6fc17f6d - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_type::hadd37e9d85d7d2da
22: 0x55ee6fc17dc7 - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_type_rule::hef241b6b83b4d06f
23: 0x55ee6fc1b844 - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_type2::hab70cfcda276224c
24: 0x55ee6fc17f6d - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_type::hadd37e9d85d7d2da
25: 0x55ee6fc17dc7 - <cddl::validator::cbor::CBORValidator as cddl::visitor::Visitor<cddl::validator::cbor::Error<T>>>::visit_type_rule::hef241b6b83b4d06f
26: 0x55ee6fc68345 - cddl::validator::validate_cbor_from_slice::hcc6b86104ef6df0a
27: 0x55ee6fbfb7b3 - cddl::main::h7593ea401ca5b573
28: 0x55ee6fc0cd21 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd733e7fd1b0b4fbe
29: 0x55ee6fbfd1a8 - main
30: 0x7f9fcd9c1d90 - __libc_start_call_main
at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
31: 0x7f9fcd9c1e40 - __libc_start_main_impl
at ./csu/../csu/libc-start.c:392:3
32: 0x55ee6fbf5a8e - _start
33: 0x0 - <unknown>
Sample 2 (map)
If I remove the refFull type choice from the Ref, it correctly passes on the test data above, but obviously fails on the actual cases that should match refFull (below).
Data in hex
a301186402636e657703581e303132333435363738393031323334353637383930313233343536373839
CBOR structure
{1: 100, 2: "new", 3: h'303132333435363738393031323334353637383930313233343536373839'}
CBOR encoding
A3 # map(3)
01 # unsigned(1)
18 64 # unsigned(100)
02 # unsigned(2)
63 # text(3)
6E6577 # "new"
03 # unsigned(3)
58 1E # bytes(30)
303132333435363738393031323334353637383930313233343536373839
So I'm wondering, is my schema incorrect or it's a bug in the validation code?