Open derekbruening opened 9 years ago
From bruen...@google.com on April 10, 2014 13:30:00
Labels: GoodContrib Component-Tests
From bruen...@google.com on April 13, 2014 11:44:04
It looks like release build catches the exception: so it's only debug that doesn't
From bruen...@google.com on April 15, 2014 14:45:50
*\ TODO VS2012-built app on win8 x64 hitting a similar problem but only on NULL address?
This test on x64 win8 fails: http://build.chromium.org/p/client.dynamorio/builders/win-8-dr/builds/526/steps/pre-commit%20suite/logs/stdio I can reproduce locally. Natively it dies but further in than the VS2013 case:
% suite/tests/bin/security-common.retnonexisting.exe starting good function in foo first foo a=1 in foo second foo a=2 starting bad function looking at ring 0x0000000000000001 fault caught on 0x0000000000000001 looking at ring 0x0000000000000000 Segmentation fault
On both the win8 bot and my local machine, VS2012 is being used to build it.
From bruen...@google.com on April 15, 2014 15:15:27
turns out we already have issue #962 for the win8 failure. needs confirming but they are likely related
From bruen...@google.com on April 10, 2014 15:06:45
When built with VS2013, x64 security-common.retnonexisting fails. It fails natively as well:
% suite/tests/bin/security-common.retnonexisting.exe starting good function in foo first foo a=1 in foo second foo a=2 starting bad function looking at ring 0x0000000000000001 Segmentation fault
Can't seem to catch the fault. I can catch a write fault -- just not this jmp-to-0x1 fault. Local __try doesn't do it either. Debugger is no help as usual with exception handling problems.
We seem to be linking with "/safeseh:no" but removing it makes no difference. A simple build from cmdline doesn't fix it: % cd ~/dr/build_suite/build_debug-internal-64/suite/tests % cl /Zi /Febin/security-common.retnonexisting.exe ../../../../git/src/suite/tests/security-common/retnonexisting.c /I../../../../git/src/suite/tests /I../.. bin/tools.lib
Doing the same thing after "compilerVS2012_64" => the test works fine.
Why is this limited to VS2013?
Under DR, DR forges the exception, but the app doesn't even catch that. The SEH code in ntdll goes and does a fatal NtRaiseException. This happens even if I change the forged pc to be a real valid pc! : looking at ring 0x0000000000000001 <Application tried to execute from unreadable memory 0x0000000000000001. This may be a result of an unsuccessful attack or a potential application vulnerability.> Segmentation fault
I'm stumped. I thought that even if there's no entry in the SEH64 table (perhaps explaining the failure of __try to work), you could still catch faults at the top level. And given that this works when built with VS2012 -- what's going on?
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1423