There were a few changes recently in drgn involving data structures used for holding pointers to type information data. These changes introduced subtle differences in the APIs behavior, one of which affected our test suite.
Before when a type was looked up by name and there was no externed/global type with that name but multiple local (source file-specific ones), then one of those local ones was returned consistently. With the recent drgn changes, the behavior is that one of those local types will be randomly picked making one of our regression tests fail sometimes while other times it passed.
The specific test is ptype 'struct v' which we expect to output:
struct v {
uint8_t b[32];
}
..sometimes returns:
struct v {
uint8_t b[64];
}
The reason is that there are multiple definitions of this struct in the vdev_raidz code of ZFS:
This patch gets rid of this regression test as it causes occassional failures AND it's not really needed as the functionality that it tests is already covered by other tests.
A side-improvement of this patch is also printing in the Github test result output the differences between what we expect the output to be vs what we get from our reference crash dumps.
There were a few changes recently in drgn involving data structures used for holding pointers to type information data. These changes introduced subtle differences in the APIs behavior, one of which affected our test suite.
Before when a type was looked up by name and there was no externed/global type with that name but multiple local (source file-specific ones), then one of those local ones was returned consistently. With the recent drgn changes, the behavior is that one of those local types will be randomly picked making one of our regression tests fail sometimes while other times it passed.
The specific test is
ptype 'struct v'
which we expect to output:..sometimes returns:
The reason is that there are multiple definitions of this struct in the vdev_raidz code of ZFS:
This patch gets rid of this regression test as it causes occassional failures AND it's not really needed as the functionality that it tests is already covered by other tests.
A side-improvement of this patch is also printing in the Github test result output the differences between what we expect the output to be vs what we get from our reference crash dumps.