Some of the more recent Windows PDBs use char8_t, which a type that is in the current (VS 19.10) MS DIA SDK, but is not in the known type maps for pdbex. This causes a crash due to a nullptr dereference in UdtFieldDefinition::VisitBaseType (there was already an issue for this - see #12).
This is an input command that caused pdbex to crash for me (most arguments probably unnecessary):
pdbex * WinTypes.pdb -o WinTypes.h -d -e i -u _anon_union_ -s _anon_struct_ -m -b -p-
where WinTypes.pdb is the PDB for WinTypes.dll 10.0.21390.1, found in C:\Symbols\WinTypes.pdb\383E6861B516E717207B5610F6C0D2F91.
The first commit in this PR fixes the nullptr dereference, should a new type be added to the MS DIA SDK again in future. The non-compilable string <unknown_type> will be printed instead.
The second commit adds the char8_t type to the known type maps so that pdbex knows about it. Example output from the same WinTypes.pdb, which looks correct to me:
Some of the more recent Windows PDBs use
char8_t
, which a type that is in the current (VS 19.10) MS DIA SDK, but is not in the known type maps for pdbex. This causes a crash due to a nullptr dereference inUdtFieldDefinition::VisitBaseType
(there was already an issue for this - see #12).This is an input command that caused pdbex to crash for me (most arguments probably unnecessary):
pdbex * WinTypes.pdb -o WinTypes.h -d -e i -u _anon_union_ -s _anon_struct_ -m -b -p-
whereWinTypes.pdb
is the PDB forWinTypes.dll
10.0.21390.1, found inC:\Symbols\WinTypes.pdb\383E6861B516E717207B5610F6C0D2F91
.The first commit in this PR fixes the nullptr dereference, should a new type be added to the MS DIA SDK again in future. The non-compilable string
<unknown_type>
will be printed instead.The second commit adds the
char8_t
type to the known type maps so that pdbex knows about it. Example output from the sameWinTypes.pdb
, which looks correct to me: