How to find out the error location?

It's a "vec" error, but it only gives the location of the std file and I can't get the exact location of it in
The chance of this error happening is so small that it is difficult for me to debug it.

How can I find out the location of this error in

thread '<unnamed>' panicked at 'insertion index (is 18) should be <= len (is 17)', library\alloc\src\vec\
stack backtrace:
   0:     0x7ff7e5ec99ff - std::sys_common::backtrace::_print_fmt
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\sys_common\
   1:     0x7ff7e5ec99ff - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\sys_common\
   2:     0x7ff7e5e5c66b - core::fmt::write
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\core\src\fmt\
   3:     0x7ff7e5ebc32a - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\io\
   4:     0x7ff7e5ecbaab - std::sys_common::backtrace::_print
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\sys_common\
   5:     0x7ff7e5ecbaab - std::sys_common::backtrace::print
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\sys_common\
   6:     0x7ff7e5ecb691 - std::panicking::default_hook::closure$1
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\
   7:     0x7ff7e5ecc5b7 - std::panicking::rust_panic_with_hook
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\
   8:     0x7ff7e5ecc075 - std::panicking::begin_panic_handler::closure$0
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\
   9:     0x7ff7e5ecbfbf - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\sys_common\
  10:     0x7ff7e5ecbf94 - std::panicking::begin_panic_handler
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\
  11:     0x7ff7e5ed2875 - core::panicking::panic_fmt
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\core\src\
  12:     0x7ff7e5ed27bb - alloc::vec::impl$1::insert::assert_failed
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\alloc\src\vec\
  13:     0x7ff7e5db7b63 - __ImageBase
  14:     0x7ff7e5ddddd3 - __ImageBase
  15:     0x7ff7e5df56fa - __ImageBase
  16:     0x7ff7e5da6c06 - __ImageBase
  17:     0x7ff7e5db00fe - __ImageBase
  18:     0x7ff7e5ec8a7c - alloc::boxed::impl$45::call_once
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\alloc\src\
  19:     0x7ff7e5ec8a7c - alloc::boxed::impl$45::call_once
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\alloc\src\
  20:     0x7ff7e5ec8a7c - std::sys::windows::thread::impl$0::new::thread_start
                               at /rustc/1898c34e923bad763e723c68dd9f23a09f9eb0fc/library\std\src\sys\windows\
  21:     0x7ffe3b2f7034 - BaseThreadInitThunk
  22:     0x7ffe3c6426a1 - RtlUserThreadStart
1 Like

You can try prefixing the command with RUST_BACKTRACE=full to have more trace lines.

This is already the result obtained by using "RUST_BACKTRACE=full".

You're probably using the insert function incorrectly. Can you post your code in the playground ?

This error happens in projects with tens of thousands of lines of code.
And like I said, the chances of it happening are very low.

Well, grep for insert. And use push instead. Or make a minimal example.

You can also use gdb to catch the panic and step back.

Yes. But I think we still need to know exactly where it happened.
Even though it's a very easy mistake to correct. But only if we know where it happened.

I may not be able to use gdb.
because this project is in working state. And I may encounter this error only once a week.

You should double check what settings the profile you're using (release, debug, or a custom one) for these builds has for

  1. Optimizations
  2. Debug info

Optimizations can cause problems with finding recognizable stack frames for a backtrace, as can debug info not being set to a sufficient level.

There is also the poor man's gdb: put dbg!(); everywhere before and after all suspicious lines. (or even every two lines)

The stacktrace looks as if the error is in the top-most function of some unnamed thread. Maybe this will help to narrow the search?

1 Like

Thanks. So, is there no more direct means of viewing this error location?

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.