Hi
I've been looking at bug 4437, where a game demo works perfectly with the native MSVCRT.DLL but dies on startup with the builtin due to a division by zero.
The builtin doesn't have any fixmes, warnings or errors. Comparing builtin +relay and native +snoop traces shows the divide by zero doesn't happen with the native, everything else looks the same. A +msvcrt log is 200000 lines long but there is nothing obviously wrong either, a +all,+relay log shows nothing useful before the crash - the last function called before the crash is a simple printf without any %'s, which produces the same results on native and builtin. Disassembling around the crash shows a long chain of calculations that dies on the fated idivl. So it looks like a nasty delayed-effect bug.
I'd welcome any new ideas, and I also have a few questions. Does +relay catch all function calls? Because some functions like sscanf only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug.
Thank you Damjan
On 6/18/07, Damjan Jovanovic damjan.jov@gmail.com wrote:
only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug.
You can definitely use LoadLibrary() / GetProcAddress() inside of a builtin DLL manually to compare results against the native function. You'll have to change the name of the native DLL to avoid loading the builtin one by accident. Of course, none of that type of debugging code should be in the main git tree. Take a look at the tests/ folders for good examples of how to dynamically load the DLLs and functions.
-
Damjan Jovanovic -
Jason Green