Error while parsing a pdb: failed to parse ID: UnimplementedTypeKind(65535)

[theKidOfArcrania]

We are getting some parsing error when opening some PDB file using ezpdb. Not sure if this is relevant, but the PDB generated here corresponds to a rather large rust binary. Dumping the PDB, it seems like there are a lot of records (around 500k) in the TPI stream.

thread 'main' panicked at 'failed to parse ID: UnimplementedTypeKind(65535)', C:\Users\cloudtest\.cargo\registry\src\...\ezpdb-0.5.0\src\symbol_types.rs:218:48
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/101fa903bb9209d270086da279247625a2869211/library\std\src\panicking.rs:593
   1: core::panicking::panic_fmt
             at /rustc/101fa903bb9209d270086da279247625a2869211/library\core\src\panicking.rs:67
   2: core::result::unwrap_failed
             at /rustc/101fa903bb9209d270086da279247625a2869211/library\core\src\result.rs:1651
   3: enum2$<core::result::Result<enum2$<pdb::tpi::id::IdData>,enum2$<pdb::common::Error> > >::expect
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\core\src\result.rs:1033
   4: ezpdb::symbol_types::impl$3::try_from::closure$1
             at C:\Users\cloudtest\.cargo\registry\src\...\ezpdb-0.5.0\src\symbol_types.rs:218
   5: core::iter::adapters::map::map_fold::closure$0
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\core\src\iter\adapters\map.rs:84
   6: core::iter::traits::iterator::Iterator::fold
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\core\src\iter\traits\iterator.rs:2481
   7: core::iter::adapters::map::impl$2::fold<alloc::string::String,core::slice::iter::Iter<pdb::tpi::Item<pdb::common::IdIndex> >,ezpdb::symbol_types::impl$3::try_from::closure_env$1,tuple$<>,core::iter::traits::iterator::Iterator::for_each::call::closure_env$
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\core\src\iter\adapters\map.rs:125
   8: core::iter::traits::iterator::Iterator::for_each
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\core\src\iter\traits\iterator.rs:856
   9: alloc::vec::Vec<alloc::string::String,alloc::alloc::Global>::extend_trusted
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\alloc\src\vec\mod.rs:2843
  10: alloc::vec::spec_extend::impl$1::spec_extend
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\alloc\src\vec\spec_extend.rs:26
  11: alloc::vec::spec_from_iter_nested::impl$1::from_iter
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\alloc\src\vec\spec_from_iter_nested.rs:62
  12: alloc::vec::spec_from_iter::impl$0::from_iter<alloc::string::String,core::iter::adapters::map::Map<core::slice::iter::Iter<pdb::tpi::Item<pdb::common::IdIndex> >,ezpdb::symbol_types::impl$3::try_from::closure_env$1> >
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\alloc\src\vec\spec_from_iter.rs:33
  13: alloc::vec::impl$15::from_iter
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\alloc\src\vec\mod.rs:2711
  14: core::iter::traits::iterator::Iterator::collect
             at /rustc/101fa903bb9209d270086da279247625a2869211\library\core\src\iter\traits\iterator.rs:1895
  15: ezpdb::symbol_types::impl$3::try_from
             at C:\Users\cloudtest\.cargo\registry\src\...\ezpdb-0.5.0\src\symbol_types.rs:222
  16: ezpdb::handle_symbol
             at C:\Users\cloudtest\.cargo\registry\src\...\ezpdb-0.5.0\src\lib.rs:195
  17: ezpdb::parse_pdb<std::path::PathBuf>
             at C:\Users\cloudtest\.cargo\registry\src\...\ezpdb-0.5.0\src\lib.rs:148

[theKidOfArcrania]

Ahh so looking a bit further into this bug, it sems like the IdIndex that we were trying to (erroneously) parse here is the special IdIndex(0x0) which looks like could apparently be an optionally "None" Id index

[theKidOfArcrania]

Found the culprit: rust-lang/rust#96475

At the moment, with rustc there are the following defects in the LF_BUILDINFO record:

• path to the build tool is missing, i.e. uses an invalid type index, which makes DIA2Dump choke and llvm pdbutil crash
• command-line is missing, again uses an invalid type index
• source file is wrong, e.g. it is "src\main.rs@\2j9iw9kw1zbigor6" where it should be "src\main.rs"

[landaire]

Thanks for chasing that down. I recall Cody telling me that the pdbview utility fails on parsing its own PDB, which is very Not Good™ but never had time to track it down.

I saw someone there has a working draft, if this is critical for some project I'd recommend compiling the stage1 compiler (https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html) with their patch and cargo +stage1 build your target, run pdbview over the PDB and see if it works.

It sounds like a pain but I swear it's actually not terrible.

[theKidOfArcrania]

Is the .expect() here necessary? i.e. is it valid for the arguments for build_info string to be some default null-like string if it ends up being a null entry (I believe this is what llvm-dump does)? At least for us, having us to rebuild using a custom stage1 compiler is completely untenable for us, given that the rust project in question (not controlled by us) is already extremely fragile in terms of requiring specific rust versions, not to mention, all of these have to be running inside CI pipelines.

[landaire]

Is the .expect() here necessary?

Absolutely not. Most of the panics in these try_from() implementations were because I was too lazy to figure out the right way to do a fallible iterator. Try the latest develop branch and let me know if it works against your target PDB -- this should be fixed.

At least for us, having us to rebuild using a custom stage1 compiler is completely untenable for us,

The suggestion wasn't necessarily to build all the time with a custom compiler just to work around this, but instead to see if that fixed the bug. With that said, it wasn't clear to me last night that this issue was just with BuildInfo and could be easily worked around in this crate.

[theKidOfArcrania]

Yeah that seems to fix the panic issue.

[landaire]

Cool, I'll push out an update soon and close this out once it's done.

[landaire]

Fixed in v0.6.0