[Affected versions]: - 61.0b12 build1 (20180607135512) - 60.0b16 build1 (20180426170554) [Affected platforms]: - Windows 10 64/32bit - Windows 8.1 64/32bit - Windows 7 64/32bit [Steps to reproduce]: 1. Download target.cppunittest.tests.zip from https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=873262bdac1b (look for Windows 2012 x64 opt N if using Windows 64bit and the Windows 2012 opt N if using Windows 32bit) 2. Unzip its content 3. Open the Command Prompt (in the folder created in step 2), type in TestDllInterceptorCrossProcess.exe and press Enter. - per bug 1461654, the missing dll error is triggered, but it can be avoided if taking the missing files from the target.zip) [Expected result]: - Per https://bugzilla.mozilla.org/show_bug.cgi?id=1451511#c16, all of output displayed after running the TestDllInterceptorCrossProcess.exe file is: TEST-PASS [Actual result]: - On Windows 8.1 & 10, the "TEST-UNEXPECTED-FAIL | WindowsDllInterceptor | Failed to add hook" is triggered - On Windows 7, the "TEST-PASS | WindowsDllInterceptor | Hook added" is displayed, but after that the TestDllInterceptorCrossProcess.exe stops working (the following prompt is displayed https://drive.google.com/file/d/0B0nYKG6PRiCcYjl6R0UwMWg5SXc/view?usp=sharing) and then the "TEST-UNEXPECTED-FAIL | WindowsDllInterceptor | Child process failed to finish" is triggered [Regression range]: - bug 1451511 does not regressed this issue, as Firefox 60 is also affected

bug 1451511 added this test, so moving to the same component.

* bug 1451511 did not land until 61, so we should be ignoring 60 for purpose of these tests. * (For release management): This does not block anything, as the code in question is currently only used in a non-default configuration on Firefox 62.

I have found one problem where the compiler, when in opt mode, will inline a function in the test that shouldn't be inlined. I've written a patch for that part. But those failures don't match what I'm seeing in the bug report, so I'm running a try build and will attempt with the binaries that are generated by that. https://treeherder.mozilla.org/#/jobs?repo=try&revision=f52f952a7687d0c17d6360fcc2ec6e9b14e2062b

1) The test wasn't robust against being launched via a relative path. Now we ensure that argv[0] contains an absolute path. 2) noinline isn't having the effect that we want on clang (See https://bugs.llvm.org/show_bug.cgi?id=26545#c3). To work around that, we call GetProcAddress on ourselves and then use that function pointer instead.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a42278d971435d702b2850b5da5139dc2a4dd2ad Bug 1467798: Fix problems with inlining and paths in TestDllInterceptorCrossProcess; r=handyman

During testing for the 63 version, I've come across the attached result. Aaron, reckon we need to open a new bug for this one?

New bug, please. Also include your OS version and the build number for user32.dll