$ RUST_BACKTRACE=full scryerlgt
thread 'main' panicked at 'index out of bounds: the len is 4403647 but the index is 4404631', src/machine/machine_state_impl.rs:1830:33
stack backtrace:
0: 0x10afd61aa - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd57d5f395e142f2f
1: 0x10b0057fb - core::fmt::write::h62f25c3166239022
2: 0x10afc71aa - std::io::Write::write_fmt::h6b320bfaefb5ccfe
3: 0x10afcc675 - std::panicking::default_hook::{{closure}}::hcde769587fa1eba6
4: 0x10afcc34d - std::panicking::default_hook::h80880e43d2e08d0c
5: 0x10afccc7a - std::panicking::rust_panic_with_hook::hd17d2d97b717740f
6: 0x10afd6b5e - std::panicking::begin_panic_handler::{{closure}}::h0963fa0c208996ec
7: 0x10afd6307 - std::sys_common::backtrace::__rust_end_short_backtrace::hecb44d618e954dd2
8: 0x10afcc763 - _rust_begin_unwind
9: 0x10b019d3f - core::panicking::panic_fmt::hf3797581d3393863
10: 0x10b019d06 - core::panicking::panic_bounds_check::h4c207279c321710b
11: 0x10ab3dd77 - <usize as core::slice::index::SliceIndex<[T]>>::index::hb94052bc52567a71
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/core/src/slice/index.rs:184:10
12: 0x10ab3dd77 - core::slice::index::<impl core::ops::index::Index<I> for [T]>::index::h7bcce19299e70edf
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/core/src/slice/index.rs:15:9
13: 0x10ab3dd77 - <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index::h62427fac5f7e76be
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/alloc/src/vec/mod.rs:2528:9
14: 0x10ab3dd77 - scryer_prolog::machine::machine_state_impl::<impl scryer_prolog::machine::machine_state::MachineState>::increment_s_ptr::ha9fe99c785b90633
at /Users/pmoura/scryer-prolog/src/machine/machine_state_impl.rs:1830:33
15: 0x10abef564 - scryer_prolog::machine::dispatch::<impl scryer_prolog::machine::Machine>::dispatch_loop::hd3b09472678969e1
16: 0x10abef564 - scryer_prolog::machine::Machine::run_module_predicate::h115c853584adea51
at /Users/pmoura/scryer-prolog/src/machine/mod.rs:188:24
17: 0x10ac21567 - scryer_prolog::machine::Machine::run_top_level::h92d56436ece7d272
at /Users/pmoura/scryer-prolog/src/machine/mod.rs:282:9
18: 0x10ab0e34f - scryer_prolog::main::h820e5736c2cb3524
at /Users/pmoura/scryer-prolog/src/bin/scryer-prolog.rs:10:5
19: 0x10ab0d006 - core::ops::function::FnOnce::call_once::h47c1d21e68a2d524
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/core/src/ops/function.rs:227:5
20: 0x10ab0d006 - std::sys_common::backtrace::__rust_begin_short_backtrace::h513fcaa007a9c680
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/std/src/sys_common/backtrace.rs:123:18
21: 0x10ab0c24c - std::rt::lang_start::{{closure}}::hd48c130187db70f1
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/std/src/rt.rs:145:18
22: 0x10afbfec5 - std::rt::lang_start_internal::h0008b9a91a2ef2e8
23: 0x10ab0e439 - <unknown>
at /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.58.0-src/library/core/src/result.rs:1295:23
✘-101 ~
Yes, I ment Debug as in
std::fmt::Debugwith correspondingstd::fmt::Displaynot as in debug vs. release build.On Linux I get 1.000000…
I’m surprised by the difference between platforms. Rust is usually quite good about harmonizing these things.
Problem issue in c89324710708671586b70c7bcb9c005832d11060. Thanks! Notably, I’m able to run Logtalk’s standards compliance suite again.
Thanks for the latest fixes. With e4ea5476238e8669032b5ba5e0177048db2de4be, I now get:
No idea how to debug it this time.
Next bug, using 2b09cb44fed021a82440cd6f5076df4c1601c1fb:
And then after rustupping:
Interesting. I’m also on macOS (12.1) and I get (with 37e34c5209e48624d5e272c5b1dcf2bea7fdc1d3):
Could it be a locale issue?
Just compiled the latest git version (37e34c5209e48624d5e272c5b1dcf2bea7fdc1d3) of the
rebis-devbranch. The puzzling exception is still there:It can be reproduced in a more simpler way:
Instrumenting the Scryer adapter file, the
number.lgtfile is read fine up to included theend_of_fileterm. Further debugging shows thatwrite_canonical/2is writing a clause that the parser cannot read back:Made some progress but now the logtalk os module load is failing.
Logtalk starts fine now. Thanks for the bug fixes. But trying to run some simple tests trigger a read error followed by a crash:
I will try to isolate the read error. But meanwhile I hope the crash stack trace would be useful.