Closed oleid closed 8 months ago
@DanielT Another option to this fix would be returning the variable without type info, but advancing nonetheless. But then one would need to handle the missing type info at a different place. Not sure what is preferable. That change would look like this:
diff --git a/src/dwarf/iter.rs b/src/dwarf/iter.rs
index 6d0ec36..e914f5e 100644
--- a/src/dwarf/iter.rs
+++ b/src/dwarf/iter.rs
@@ -196,6 +196,7 @@ impl<'a> Iterator for VariablesIterator<'a> {
self.type_iter = Some(TypeInfoIter::new(ti));
} else {
self.type_iter = None;
+ self.current_var = self.var_iter.next();
}
Some((varname.to_string(), typeinfo, *address))
} else {
@@ -288,6 +289,14 @@ fn test_varinfo_iter() {
typeref: 1,
},
);
+ variables.insert(
+ "var_d_wo_type_info".to_string(),
+ VarInfo {
+ address: 4,
+ typeref: 404, // some number with no correspondence in the types hash map
+ },
+ );
+
let mut types = HashMap::<usize, TypeInfo>::new();
let mut structmembers: HashMap<String, (TypeInfo, u64)> = HashMap::new();
structmembers.insert("member_1".to_string(), (TypeInfo::Uint8, 0));
@@ -309,5 +318,5 @@ fn test_varinfo_iter() {
for item in iter {
println!("{}", item.0);
}
- assert_eq!(VariablesIterator::new(&debugdata).count(), 5);
+ assert_eq!(VariablesIterator::new(&debugdata).count(), 6);
}
Thanks for the fix!
I prefer the second approach, where variables without typeinfo are still returned by the iterator. Later on I intend to extend the insert code to handle variables without types. After all we do have addresses for them, so pretending such variables have some simple type (char?) and creating a measurement/characteristic is already useful.
I prefer the second approach, where variables without typeinfo are still returned by the iterator.
Here you are. The PR is updated.
Thanks!
This prevents an infinite loop if the type info for the current type is missing. The modified unit test demonstrates the issue.
fixes #18