lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Intermittent unit-test failure


From: Greg Chicares
Subject: Re: [lmi] Intermittent unit-test failure
Date: Mon, 06 Oct 2014 02:37:59 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 2014-10-05 23:35Z, Vadim Zeitlin wrote:
> On Sun, 05 Oct 2014 14:37:38 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2012-06-13 11:20Z, Greg Chicares wrote:
[...]
> GC> > Running it in a loop:
> GC> >   /lmi/src/build/lmi/CYGWIN_NT-5.1/gcc/ship[0]$while true; do 
> ./system_command_test.exe --accept && echo okay; done
> GC> > I see it fail on the order of ten percent of the time.
> GC> 
> GC> FWIW, this no longer seems to be a problem.
> 
>  All I can say is that I could never reproduce it and still can't.

Good enough--as far as 'system_command_test' is concerned. The only
reason why I even mentioned it is that I observe sporadic failure
with one unit test, and I knew I had written something on that
subject here...

...so I found this message from a couple years ago, and it seemed
like a good idea to retest this quondam issue; and it's good to
know that you've done likewise, to make assurance doubly sure...

[and you probably want to stop reading here, as the rest of this
message merely documents the resolution of obscure defects that
arose when a once-reasonable workaround putrefied]

...but it turns out that the failure I'm observing, sporadically,
is in another unit test:

Running premium_tax_test:

** uncaught exception: std::runtime_error: Unable to parse xml file 
'C:/lmi/src/build/lmi/CYGWIN_NT-5.1/gcc/ship/sample.policy': Document is empty

And I know how to reproduce it: delete 'sample.policy' from
$(build_directory) (the directory where '.o' files are written
and unit tests are run), then
  make unit_tests unit_test_targets=premium_tax_test.exe
[omitting the trailing '.exe' for non-.exe-afflicted platforms].

This always fails, even though the deleted file is rendered
undead by this snippet from 'workhorse.make':

  # Some test targets require 'sample.policy' to exist even though they
  # don't actually read its contents.

  $(test_targets): sample.policy

  sample.policy:
          @$(TOUCH) $@

The diagnostic is 'Unable to parse xml file' because the file
is, of course, empty. To fix the problem at hand, I'll make
'premium_tax_test' write a valid 'sample.policy' instead.
(Usually it "worked" because 'product_file_test' writes such
a valid file, which is not normally deleted.)

But a further problem is revealed by removing the suspicious
code quoted above from 'workhorse.make': the 'cgi_tests'
target then fails. And, as alluded to by the comment above,
the CGI binary really does read only that file's name, not
its contents. Reason: every illustration must specify a
'ProductName', which was an unconstrained string a decade
or more ago when I last worked on CGI--but since then we've
added 'product_names.cpp' and 'ce_product_name.cpp', which
constrain that string to match the name of an actual
'.policy' file. Creating a zero-byte file was just a sloppy
workaround, which obstructed my efforts to understand the
intermittent problem with 'premium_tax_test'; I'll remove
it, and fix the CGI binary.




reply via email to

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