Branch host-op-1.6 regression

[LiuJiazheng]

I am testing host-op with my handcraft repo: https://github.com/LiuJiazheng/rust-host-keccak256
and an example https://github.com/LiuJiazheng/zkWasm-rust

Both symptom are same:
dry run can pass but single-proof failed on imtable with bt:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: 91', crates/specs/src/imtable.rs:88:22
stack backtrace:
   0: rust_begin_unwind
             at /rustc/ff8c8dfbe66701531e3e5e335c28c544d0fbc945/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/ff8c8dfbe66701531e3e5e335c28c544d0fbc945/library/core/src/panicking.rs:65:14
   2: core::result::unwrap_failed
             at /rustc/ff8c8dfbe66701531e3e5e335c28c544d0fbc945/library/core/src/result.rs:1791:5
   3: specs::imtable::InitMemoryTable::try_find
   4: specs::mtable::MTable::new
   5: <delphinus_zkwasm::runtime::CompiledImage<wasmi::module::NotStartedModuleRef,wasmi::tracer::Tracer> as delphinus_zkwasm::runtime::wasmi_interpreter::Execution<wasmi_core::value::Value>>::run
   6: delphinus_zkwasm::loader::ZkWasmLoader<E,T,EnvBuilder>::run
   7: delphinus_zkwasm::loader::ZkWasmLoader<E,T,EnvBuilder>::circuit_with_witness
   8: delphinus_cli::exec::exec_create_proof
   9: delphinus_cli::main

My script

#!/bin/bash
  
set -e
set -x

rm -rf output
mkdir output

#wasm image
FILE=$1
default=/home/frank/Projects/zkWasm-rust/pkg/output.wasm
FILE=${default}

#k
SPACE=${2:-18}

# Have `cuda` build
ZKWASM=~/Projects/zkWasm/target/release/delphinus-cli

export RUST_LOG=info
export RUST_BACKTRACE=1

${ZKWASM} --function zkmain -k ${SPACE} --param ./params --output ./output --host host --wasm ${FILE} setup

${ZKWASM} --function zkmain -k ${SPACE} --param ./params --output ./output --host host --wasm ${FILE} dry-run

${ZKWASM} --function zkmain -k ${SPACE} --param ./params --output ./output --host host --wasm ${FILE} single-prove

[LiuJiazheng]

The reason:

impl InitMemoryTable {
    pub fn new(entries: Vec<InitMemoryTableEntry>, k: u32) -> Self {
        let mut imtable = Self {
            entries: entries
                .into_iter()
                .map(|entry| InitMemoryTableEntry {
                    ltype: entry.ltype,
                    is_mutable: entry.is_mutable,
                    start_offset: entry.start_offset,
                    end_offset: if entry.end_offset == u32::MAX {
                        (1u32 << (k - 1)) - 1
                    } else {
                        entry.end_offset
                    },
                    vtype: entry.vtype,
                    value: entry.value,
                })
                .collect(),
            sorted_global_init_entries: vec![],
            sorted_heap_init_entries: vec![],
        };

The logic of assignment end_offset is depending on k to set up the "MAX" number in the sense of space k.
However when k is small (say 18), the start_offset might be greater than end_offset, thus later when Memory::new trying to find imtable entry, the binary search cannot be performed corrected and hit unwrap

Propose: instead of silently allowing it and triggers an assertion in other place, it could be better directly asserting in imtable::new.

Evidence:
Offset: 131194
InitMomoryEntry
InitMemoryTableEntry { ltype: Heap, is_mutable: true, start_offset: 131194, end_offset: 131071, vtype: I64, value: 0 }
Always be the last one.

[xgaozoyoe]

Will try to perform some pre-check in the dry-run.