message_compiler.py build failure due to innocent enum ordering changes

[Finnur Thorarinsson]

I started getting a build error today that, frustratingly, surfaces even on a clean pull of chromium in Windows 10.

The error is: "mc.exe output different from files in c:\Src\chromium\src\build\win\..\..\third_party\win_build_output\mc/chrome/common/win, see c:\users\finnur\appdata\local\temp\tmp4bonnc"

The error is printed when this line executes in message_compiler.py.

As a test, I took the input file it uses (eventlog_messages.mc) and put it in a folder called mc on my Desktop and compiled it manually with mc.exe, using:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\mc.exe" -h %USERPROFILE%\\Desktop\\mc -r %USERPROFILE%\\Desktop\\mc -u eventlog_messages.mc

Interestingly, this produces warnings not shown during build but somewhat explain the file diff failure that the error is complaining about. 

eventlog_messages.mc(7) : warning : Redefining value of Informational

eventlog_messages.mc(8) : warning : Redefining value of Warning

eventlog_messages.mc(9) : warning : Redefining value of Error

And the definitions are now ordered as such:

#define STATUS_SEVERITY_WARNING          0x1

#define STATUS_SEVERITY_INFORMATIONAL    0x0

#define STATUS_SEVERITY_FATAL            0x3

#define STATUS_SEVERITY_ERROR            0x2

Emphasis mine -- but note how the emphasized lines are ordered incorrectly? (The diff expects order 0,1,2,3 but the output is ordered 1,0,3,2.) 

Note: My generated file has the same enums with the same values, but they're just ordered weirdly and therefore the diff balks.

Since this "error" looked innocuous enough, I tried commenting out the diff in message_compiler.py, but ran into a similar diff error in midl.py. 

That one also looked innocent (only the build date etc. changed) so I commented out that diff as well.

And now it seems to build fine, but I'd like to get rid of the commenting out of the diff commands... :)

Anyone with tips on what to try?

[Nico Weber]

Can you file a bug? Guess we'll have to make the wrapper sort these lines :-(

Which msvc are you using? The hermetic one? 2015 or 2017?

[Nico Weber]

On that bug, please also mention if https://chromium-review.googlesource.com/649768 fixes things for you.

[Nico Weber]

On Mon, Sep 4, 2017 at 3:10 PM, Finnur Thorarinsson <fin...@chromium.org> wrote:

I started getting a build error today that, frustratingly, surfaces even on a clean pull of chromium in Windows 10.

The error is: "mc.exe output different from files in c:\Src\chromium\src\build\win\..\..\third_party\win_build_output\mc/chrome/common/win, see c:\users\finnur\appdata\local\temp\tmp4bonnc"

The error is printed when this line executes in message_compiler.py.

As a test, I took the input file it uses (eventlog_messages.mc) and put it in a folder called mc on my Desktop and compiled it manually with mc.exe, using:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\mc.exe" -h %USERPROFILE%\\Desktop\\mc -r %USERPROFILE%\\Desktop\\mc -u eventlog_messages.mc

Interestingly, this produces warnings not shown during build but somewhat explain the file diff failure that the error is complaining about. 

eventlog_messages.mc(7) : warning : Redefining value of Informational

eventlog_messages.mc(8) : warning : Redefining value of Warning

eventlog_messages.mc(9) : warning : Redefining value of Error

Oh, and I think these warnings are unrelated. I'm seeing these locally too, but I think they're harmless. According to https://msdn.microsoft.com/en-us/library/windows/desktop/dd996906(v=vs.85).aspx , the default SeverityNames are `SeverityNames=(   Success=0x0   Informational=0x1   Warning=0x2   Error=0x3)` while our file explicitly says

SeverityNames=(Informational=0x0:STATUS_SEVERITY_INFORMATIONAL

               Warning=0x1:STATUS_SEVERITY_WARNING

               Error=0x2:STATUS_SEVERITY_ERROR

               Fatal=0x3:STATUS_SEVERITY_FATAL

              )

Note that this does change the numeric value of Informational from 1 to 0, of Warning from 2 to 1, and of Error from 3 to 2. pastarmovj, do you remember if we intentionally change the severity levels here?

(But, as said above, that's unrelated to the build error you're seeing, it's just a warning in the same file. Please file a bug for the build error including details like MSVC version, and check if https://chromium-review.googlesource.com/c/chromium/src/+/649768 helps.)

[Ben Wells]

I'm getting similar errors with MIDL (full output below). It seems like the diff fails if your version is slightly different. This is on a non-corp machine with a fully up to date visual studio 2017, but it seems like it's midl tool is not quite new enough,

Maybe the diff should ignore version numbers?

Build outupt:

FAILED: gen/third_party/isimpledom/ISimpleDOMNode.h gen/third_party/isimpledom/ISimpleDOMNode.dlldata.c gen/third_party/isimpledom/ISimpleDOMNode_i.c gen/third_party/isimpledom/ISimpleDOMNode_p.c

C:/src/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/midl.py environment.x64 gen/third_party/isimpledom ISimpleDOMNode.tlb ISimpleDOMNode.h ISimpleDOMNode.dlldata.c ISimpleDOMNode_i.c ISimpleDOMNode_p.c ../../third_party/isimpledom/ISimpleDOMNode.idl /char signed /env x64 /Oicf

midl.exe output different from files in C:\src\chrome\src\build\toolchain\win\..\..\..\third_party\win_build_output\midl/third_party/isimpledom\ISimpleDOMNode.idl\x64, see c:\users\build\appdata\local\temp\tmpaxo4kn

diff c:\users\build\appdata\local\temp\tmpaxo4kn C:\src\chrome\src\build\toolchain\win\..\..\..\third_party\win_build_output\midl/third_party/isimpledom\ISimpleDOMNode.idl\x64

Identical files : ['ISimpleDOMNode.dlldata.c']

Differing files : ['ISimpleDOMNode.h', 'ISimpleDOMNode_i.c', 'ISimpleDOMNode_p.c']

--- C:\src\chrome\src\build\toolchain\win\..\..\..\third_party\win_build_output\midl/third_party/isimpledom\ISimpleDOMNode.idl\x64\ISimpleDOMNode.h

+++ c:\users\build\appdata\local\temp\tmpaxo4kn\ISimpleDOMNode.h

@@ -3,11 +3,11 @@

 /* this ALWAYS GENERATED file contains the definitions for the interfaces */

- /* File created by MIDL compiler version 8.01.0622 */

-/* at a redacted point in time

+ /* File created by MIDL compiler version 8.01.0620 */

+/* at Tue Jan 19 14:14:07 2038

  */

 /* Compiler settings for ../../third_party/isimpledom/ISimpleDOMNode.idl:

-    Oicf, W1, Zp8, env=Win64 (32b run), target_arch=AMD64 8.01.0622

+    Oicf, W1, Zp8, env=Win64 (32b run), target_arch=AMD64 8.01.0620

     protocol : dce , ms_ext, c_ext, robust

     error checks: allocation ref bounds_check enum stub_data

     VC __declspec() decoration level:

--- C:\src\chrome\src\build\toolchain\win\..\..\..\third_party\win_build_output\midl/third_party/isimpledom\ISimpleDOMNode.idl\x64\ISimpleDOMNode_i.c

+++ c:\users\build\appdata\local\temp\tmpaxo4kn\ISimpleDOMNode_i.c

@@ -5,11 +5,11 @@

 /* link this file in with the server and any clients */

- /* File created by MIDL compiler version 8.01.0622 */

-/* at a redacted point in time

+ /* File created by MIDL compiler version 8.01.0620 */

+/* at Tue Jan 19 14:14:07 2038

  */

 /* Compiler settings for ../../third_party/isimpledom/ISimpleDOMNode.idl:

-    Oicf, W1, Zp8, env=Win64 (32b run), target_arch=AMD64 8.01.0622

+    Oicf, W1, Zp8, env=Win64 (32b run), target_arch=AMD64 8.01.0620

     protocol : dce , ms_ext, c_ext, robust

     error checks: allocation ref bounds_check enum stub_data

     VC __declspec() decoration level:

@@ -65,7 +65,7 @@

 #define MIDL_DEFINE_GUID(type,name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \

         EXTERN_C __declspec(selectany) const type name = {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}

-#endif // !_MIDL_USE_GUIDDEF_

+#endif !_MIDL_USE_GUIDDEF_

 MIDL_DEFINE_GUID(IID, IID_ISimpleDOMNode,0x1814ceeb,0x49e2,0x407f,0xaf,0x99,0xfa,0x75,0x5a,0x7d,0x26,0x07);

--- C:\src\chrome\src\build\toolchain\win\..\..\..\third_party\win_build_output\midl/third_party/isimpledom\ISimpleDOMNode.idl\x64\ISimpleDOMNode_p.c

+++ c:\users\build\appdata\local\temp\tmpaxo4kn\ISimpleDOMNode_p.c

@@ -3,11 +3,11 @@

 /* this ALWAYS GENERATED file contains the proxy stub code */

- /* File created by MIDL compiler version 8.01.0622 */

-/* at a redacted point in time

+ /* File created by MIDL compiler version 8.01.0620 */

+/* at Tue Jan 19 14:14:07 2038

  */

 /* Compiler settings for ../../third_party/isimpledom/ISimpleDOMNode.idl:

-    Oicf, W1, Zp8, env=Win64 (32b run), target_arch=AMD64 8.01.0622

+    Oicf, W1, Zp8, env=Win64 (32b run), target_arch=AMD64 8.01.0620

     protocol : dce , ms_ext, c_ext, robust

     error checks: allocation ref bounds_check enum stub_data

     VC __declspec() decoration level:

@@ -952,7 +952,7 @@

     1, /* -error bounds_check flag */

     0x50002, /* Ndr library version */

     0,

-    0x801026e, /* MIDL Version 8.1.622 */

+    0x801026c, /* MIDL Version 8.1.620 */

     0,

     UserMarshalRoutines,

     0,  /* notify & notify_flag routine table */

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiF-zS366w%2BuDuct8xAmMgLaXwr0WDw7d34LvjpsMFC8_g%40mail.gmail.com.

[Nico Weber]

That should be addressed by https://chromium-review.googlesource.com/c/651848/

[Ben Wells]

Awesome, thanks!

[Finnur Thorarinsson]

I don't think a new bug is needed, since the problem with message_compiler.py is fixed with your checked in CL (verified tip of tree) and the problem Ben mentioned is being addressed with the last chrome-review link you sent. Once you check that in I think we're all good.

Thanks for a quick fix!

PS. This was on a non-corp machine with VS 2015 update 3.

[Nico Weber]

On Wed, Sep 6, 2017 at 12:45 PM, Finnur Thorarinsson <fin...@chromium.org> wrote:

I don't think a new bug is needed, since the problem with message_compiler.py is fixed with your checked in CL

By now it isn't, but it would've been nice if I could've just referenced bugs in my CLs instead of saying "see thread foo", see comment 3 on review for issue bar", etc. crbug is good in showing "blocked on" data, and using the bug tracker for bugs makes things a bit more structured. But yeah, Too late for this issue :-)

[Finnur Thorarinsson]

Fair enough. 

[bruce...@chromium.org]

If you open up a "Developer Command Prompt for VS" (2015 or 2017) and type 'where midl' you will find that the midl compiler is part of the Windows 10 SDK. So, it turns out that your version of Visual Studio is only of secondary importance. What really matters is the Windows 10 SDK version you have installed.

Chrome on the build machines currently builds with the Creators Update SDK (10.0.15063). Some developers only have the Anniversary Edition SDK (10.0.14393) installed which is why their results are different.

We may start requiring the Creators Update SDK at some point, which will resolve this issue for a bit. We probably would have required it earlier but there were several buggy versions that shipped. The current version (10.0.15063.468 is its full name) works well.