invalid slice index

[cholcombe973]

I'm getting an odd invalid slice index error that I can't explain and the backtrace points to the Structures iterator in lib.rs

thread 'tokio-runtime-worker' panicked at 'slice index starts at 390 but ends at 386', src/libcore/slice/mod.rs:2731:5
stack backtrace:
...snip...
14:           0xe08b5b - <core::ops::range::Range<usize> as core::slice::SliceIndex<[T]>>::index::h946193d2355fb32a
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/slice/mod.rs:2887
  15:           0xe090e8 - core::slice::<impl core::ops::index::Index<I> for [T]>::index::h6a675459d581329f
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/slice/mod.rs:2707
  16:           0xdeed05 - <dmidecode::Structures as core::iter::traits::iterator::Iterator>::next::h8a7a0a3541b91d65
                               at /root/.cargo/git/checkouts/dmidecode-9d9a4c3ef3ed9aca/d30e17f/src/lib.rs:383

Oddly.. this only seems to happen at the moment with the v2 entry point. The other strange thing about this is if I slow my program down a little with more println's it works.

[jcreekmore]

My guess is that the buffer slice stored in the Structures iterator is not large enough to contain the entire smbios_len and that you are actually getting a short-read somewhere when you are grabbing the SMBIOS area for parsing. Since you are in tokio, I could see where, if you are doing a read, adding those printlns could slow stuff down enough that maybe enough data was actually available for the buffer. Might be worth ensuring in the structures method that the smbios_len is >= the len of the buffer.

[cholcombe973]

I'm not sure that's it. I checked the length of the buffer i'm passing in to the entrypoint.structures() call and it's the same size as the smbios_len. Do you have any good example code of reading /dev/mem, parsing that and walking through the structures?

[jcreekmore]

To be honest, I am no longer at the company I was at when I original wrote this crate, so I do not have good example code other than what I put into the tests. But, to the best of my recollection, I just read the file that the Linux kernel provided for the SMBIOS tables instead of trying to read it from /dev/mem. I was integrating this crate into a rust daemon and I didn't want to call out to the dmidecode utility and do a bunch of string parsing, but Linux telling me what the tables themselves should be was good enough. Additionally, when I was originally working on this, I didn't have access to anything that was v3 or higher; I only have v2 tables to parse (I still only have access to v2 tables with my current position).

Looking a little more closely at the code, I am not sure what is going on unless there is an off-by-one at line 359 (maybe should be a >= instead of a >). What the error message seems to be saying to me is that self.idx is the same as what it believes the strings_idx is (since size_of::<HeaderPacked> should be 4). I don't have any explanation why putting printlns in your code would cause that behavior to be any different.