PMI failure log often includes no useful information about failures

[AndyAyersMS]

eg:

jit-diff diff --pmi --diff
Using --output D:\repos\coreclr\bin\diffs
Using --diff D:\repos\coreclr\bin\Product\Windows_NT.x64.Checked
Using --arch x64
Using --core_root D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root

Warning: it is best practice to use a Release build for --core_root, --crossgen, and --test_root.

No assemblies specified; defaulting to corelib
Beginning PMI Diffs for System.Private.CoreLib.dll
/ Finished 0/0 Base 0/1 Diff [5.9 sec]Error running D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root\corerun.exe on D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root\System.Private.CoreLib.dll
1 errors compiling set.
Dasm command "jit-dasm-pmi --platform D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root --corerun D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root\corerun.exe --jit D:\repos\coreclr\bin\Product\Windows_NT.x64.Checked\clrjit.dll --nocopy --output D:\repos\coreclr\bin\diffs\dasmset_1\diff D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root\System.Private.CoreLib.dll" returned with 1 failures
| Finished 0/0 Base 1/1 Diff [5.9 sec]
Dasm commands returned 0 base failures, 1 diff failures.
Completed PMI Diffs for System.Private.CoreLib.dll in 5.92s
Diffs (if any) can be viewed by comparing: D:\repos\coreclr\bin\diffs\dasmset_1\base D:\repos\coreclr\bin\diffs\dasmset_1\diff

Warning: Failures detected generating asm: 0 base, 1 diff

has failure log:

Failed PREPALL on D:\repos\coreclr\bin\tests\Windows_NT.x64.Checked\Tests\Core_Root\System.Private.CoreLib.dll

[mikedn]

Is this PMI specific? I'm pretty sure I've seen a similar issue with non-PMI diffs - if the JIT asserts the assert output is no where to be found.

[AndyAyersMS]

Not sure. Looking at it now.

[AndyAyersMS]

PMI writes a .err file to the CWD named after the assembly, but it's no more helpful.

General error, no assert seen.

Seems like if DRIVEALL can't auto-diagnose the error (so we can retry to get past asserts) it should just spew out the subprocess stream.

And we should have this end up in the same place as the log file (or be part of the log file).

[mikedn]

I did a quick test with crossgen - the assert text does go to stderr but attempting to redirect that results in a partial message. Might be a flushing issue in JIT.

[mikedn]

Actually no, I take that back. Redirecting stderr (via the Process class) works fine.

[mikedn]

Apparently doAssert behaves differently when run using jit-dasm. Can't figure out why.

[mikedn]

Turns out that in my case it's just that I'm using the Release VM with a Checked JIT. In that case the JIT calls doAssert but the VM basically doesn't do anything with it, that's why the assert message is no where to be seen, that's unfortunate.

But I see that you're using a checked VM. If I do that (with either PMI or crossgen) I do see the JIT assert in the log file produced by jit-dasm.