find_many_with_session crash.

[skydig]

find_many_with_session sometimes crash , when I update one database file repeatedly.
following are trace.

thanks.
'main' panicked at 'index 24 is greater than length 1', github.com-1ecc6299db9ec823\polodb_core-3.5.2\page\data_page_wrapper.rs:82:13
thread 'main' panicked at 'C:\Users\alcatel.cargo\registry\src\github.com-1ecc6299db9ec823\polodb_core-3.5.2\db\db.rs:177:43
stack backtrace:
0: 0x7ff73487a360 - std::backtrace_rs::backtrace::dbghelp::trace::hf349c34c3457c740
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src....\backtrace\src\backtrace/dbghelp.rs:98:5
1: 0x7ff73487a360 - std::backtrace_rs::backtrace::trace_unsynchronized::h2bd29529ecc3ce0e
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src....\backtrace\src\backtrace/mod.rs:66:5
2: 0x7ff73487a360 - std::sys_common::backtrace::_print_fmt::hb3b653f470c22f3c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src\sys_common/backtrace.rs:65:5
3: 0x7ff73487a360 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha1b729084c6ddc62
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src\sys_common/backtrace.rs:44:22
4: 0x7ff7348d9f6b - core::fmt::write::he318666ecc6d0e50
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\core\src\fmt/mod.rs:1213:17
5: 0x7ff73486cf15 - std::io::Write::write_fmt::h16e260ff7842914c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src\io/mod.rs:1682:15
6: 0x7ff73487a0b4 - std::sys_common::backtrace::_print::hfa2b093dead91421
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src\sys_common/backtrace.rs:47:5
7: 0x7ff73487a0b4 - std::sys_common::backtrace::print::ha0089f50e86f9a42
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src\sys_common/backtrace.rs:34:9
8: 0x7ff73487d3ff - std::panicking::default_hook::{{closure}}::h23cb21cc6d06499c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src/panicking.rs:267:22
9: 0x7ff73487d0d3 - std::panicking::default_hook::h73a8e55e598e91dc
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src/panicking.rs:286:9
10: 0x7ff73487dd49 - std::panicking::rust_panic_with_hook::h38620170de56dbc1
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src/panicking.rs:688:13
11: 0x7ff73487dab6 - std::panicking::begin_panic_handler::{{closure}}::h19e96512213681c1
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src/panicking.rs:579:13
12: 0x7ff73487ae8f - std::sys_common::backtrace::__rust_end_short_backtrace::h0803ea066b746adc
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src\sys_common/backtrace.rs:137:18
13: 0x7ff73487d7c0 - rust_begin_unwind
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\std\src/panicking.rs:575:5
14: 0x7ff7348d6755 - core::panicking::panic_fmt::h6c5d7c67ee48b787
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\core\src/panicking.rs:64:14
15: 0x7ff7348d6d36 - core::result::unwrap_failed::hca540035cf99f0f4
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library\core\src/result.rs:1790:5
16: 0x7ff7345b0060 - <polodb_core::session::client_session::ClientSession as core::ops::drop::Drop>::drop::h68c99acfa97aab78
17: 0x7ff73456e6c9 - test_db::upsert_test_item::h79cc79b0b09dedfd

[skydig]

-rw-r--r-- 1 65536 Mar 25 18:40 t.db
-rw-r--r-- 1 1393896 Mar 25 18:40 t.db.journal
journal is large and t.db almost all zero.

[vincentdchan]

Not sure if this is an issue with session management. Would this error occur if you don't use the with_session API?

[vincentdchan]

It would be easier to debug if you can provide the sequence of your operations.

[skydig]

it seems ok after remove all session api call.@vincentdchan

[vincentdchan]

I got it. It could be a problem with session management. Currently, PoloDB has undergone significant changes and has been upgraded to v4. In v4, the underlying data structures have changed. LSM-tree is now used as the data structure in place of Btree in v3. This is a significant breaking change. I would recommend that you try it.

The downside is that in v4 old data is no longer compatible. However, I will ensure that this does not happen again. PoloDB will gradually become stable.

Due to the aforementioned reasons, the issue in this case will no longer be investigated.