lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] How did this unit test fail?


From: Vadim Zeitlin
Subject: Re: [lmi] How did this unit test fail?
Date: Tue, 20 Mar 2018 00:05:20 +0100

On Mon, 19 Mar 2018 21:13:08 +0000 Greg Chicares <address@hidden> wrote:

GC> When I tested my last set of commits carefully before pushing, I was
GC> really surprised to see that 'bourn_cast_test' failed (without the
GC> change that I sneaked into 'bourn_cast_test.cpp' in commit 3d3e2b6).

 Unfortunately I don't see this failure, neither under Linux x86_64 (which
wasn't really surprising) nor under MSW, using the official makefiles.

GC> Reverting those changes to that file only, which amount only to this:
GC> 
GC> -    stifle_warning_for_unused_variable(z);
GC> +    (void)&z;
GC> 
GC> in two places, reproduces the error, which is:
GC> 
GC> ???? test failed:
GC> ???? test failed: 0
GC> [invoked from file /opt/lmi/src/lmi/bourn_cast_test.cpp, line: 781]
GC> [file /opt/lmi/src/lmi/bourn_cast_test.cpp, line 261]

 I did, using the latest master, i.e. 3d3e2b67916c72c7446f140f2f986456b1164b1e

        git checkout 3d3e2b6~ -- bourn_cast_test.cpp

followed by

        make bourn_cast_test.exe
        make bourn_cast_test.exe-run

(BTW, wouldn't it make sense for "%-run" to depend on "%"?) and the test
still succeeds, with 599 checks passing (under Linux 600 of them pass).

 Do I need to do anything special when building or running the test to see
the problem?


GC> Anyway, I committed it with (1) only, because that's the minimal
GC> change that doesn't break the unit test. I suppose I could separate
GC> class minmax out into its own header independent of "miscellany.hpp",
GC> but I don't like voodoo workarounds for problems I don't understand.

 Me neither, so from this point of view everything seems just fine -- I
don't see any inexplicable problems here. Of course, this also doesn't help
you at all.

GC> Vadim--I can't guess what went wrong here. Can you see it?

 No, unfortunately I don't. As always, I'd recommend cleaning everything
and rebuilding once again, and if the problem still persists after doing
this, we'd need to compare the binaries produced in your and my builds and
maybe try running your binary here and vice versa to ascertain whether the
problem is in the binary itself or in the environment (I'd really like to
blame Wine, but I don't see how could it be its fault...).

 Please let me know if you'd like me to send you my binary for testing,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]