Mobibench fails to run with Limbo

[penberg]

When attempting to run Mobibench as per instructions in PERF.md, I get the following:

penberg@turing:~/src/penberg/limbo-eval/Mobibench/shell$ ./mobibench -p benchmark -n 1000 -d 0
-----------------------------------------
[mobibench measurement setup]
-----------------------------------------
DB teset mode enabled.
Operation : 0
Transactions per thread: 1000
# of Tables : 3
# of Databases : 1
# of Threads : 1
setState: 1
rc = 1
exec_sql error :not an errorSQL logic erroraccess permission deniedquery aborteddatabase is lockeddatabase table is lockedout of memoryattempt to write a readonly databaseinterrupteddisk I/O errordatabase disk image is malformedassertion failed: idx < CAPACITYSoftware caused connection abortbad or unsupported format stringunable to select local time typestd/src/io/buffered/bufwriter.rsstd/src/os/unix/net/ancillary.rsstd/src/sys/sync/rwlock/futex.rsInvalid data dir virtual addressMissing PE forwarded export name
setState: 4
setState: 2
Err string : exec_sql error

Looks like our error reporting is broken somehow, masking what the exec_sql error actually is.

[diegoreis42]

I'm debugging right now and it seems that (*_db).err_code is equal to 0 and for some reason the following snippet doesn't return std::ptr::null() when it should.

    let err_msg = if (*_db).err_code != SQLITE_OK {
        if !(*_db).p_err.is_null() {
            (*_db).p_err as *const std::ffi::c_char
        } else {
            std::ptr::null()
        }
    } else {
        std::ptr::null()
    };

This explain the returning of all error messages.

I forced the returning with:

    let err_msg = if (*_db).err_code != SQLITE_OK {
        if !(*_db).p_err.is_null() {
            return (*_db).p_err as *const std::ffi::c_char;
        } else {
            return std::ptr::null();
        }
    } else {
        return std::ptr::null();
    };

[diegoreis42]

All right, the error occurs on the translation of SQL statements into bytecode. Since the Statement initiates with BEGIN; it calls a macro bail_parse_error!("BEGIN not supported yet"), since the error is returned to the called with ?, it ends up returning a generic SQLITE_ERROR. But since there is no actual error (the functionality is not implemented yet) (*_db).err_code is 0.

I think a good way to handle this is implementing some temporary customs SQLITE errors, to indicate which feature has not been implemented yet, and avoid future confusion.