non-deterministic enumeration of imported libraries
mewmew opened this issue · 1 comments
Upon two consecutive executions of binee
(with added debug statements for SearchFile
, the following debug output was obtained. Notice that rpcrt4.dll
follows shell32.dll
in the output of the first execution, while msvcrt.dll
follows shell32.dll
in the outut of the second execution; thus indicating non-deterministic results.
emu.SearchPath
SearchFile("apisetschema.dll")
SearchFile("ntdll.dll")
SearchFile("kernel32.dll")
SearchFile("shell32.dll")
SearchFile("rpcrt4.dll")
SearchFile("advapi32.dll")
SearchFile("secur32.dll")
SearchFile("shlwapi.dll")
SearchFile("gdi32.dll")
SearchFile("user32.dll")
SearchFile("msvcrt.dll")
SearchFile("version.dll")
emu.SearchPath
SearchFile("apisetschema.dll")
SearchFile("ntdll.dll")
SearchFile("kernel32.dll")
SearchFile("shell32.dll")
SearchFile("msvcrt.dll")
SearchFile("rpcrt4.dll")
SearchFile("secur32.dll")
SearchFile("advapi32.dll")
SearchFile("shlwapi.dll")
SearchFile("gdi32.dll")
SearchFile("user32.dll")
SearchFile("version.dll")
I think this was the only source of non-determinism was in ImportedDlls
, and as such, this issue should be fixed by #42. Given the nature of non-deterministic bugs, this cannot be guaranteed.
As such, it would be good to add a test case that has a few additional imports (except kernel32.dll
and ntdll.dll
which are always at fixed locations in the list of imported libraries). Any CI test case failures would then let us know if this issue was also caused by other non-deterministic computations.