lmi
[Top][All Lists]
Advanced

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

[lmi] Strange new GUI tests failures in the CI builds


From: Vadim Zeitlin
Subject: [lmi] Strange new GUI tests failures in the CI builds
Date: Sat, 5 Mar 2022 22:17:53 +0100

 Hello,

 You can safely skip reading of this email as it's just a log of my
attempts to fix the latest problem that arose in the CI builds, but without
any conclusion so far -- so the only useful thing this post achieves is to
let you know that I'm aware of this problem and am working (or, rather, was
working, as I'm going to make a break now) on it, and you don't need to
read any further to be aware of it.

 But if you're irredeemably curious, this is about the weird assert
failures in the latest GUI tests runs in the CI builds. Copying the log
from https://github.com/let-me-illustrate/lmi/runs/5428529518

---------------------------------- >8 --------------------------------------
0064:err:ole:start_rpcss Failed to open RpcSs service
NOTE: starting the test suite
about_dialog_version: started
About dialog version string is '20220104T1348Z'.
time=2082ms (for about_dialog_version)
about_dialog_version: ok
benchmark_census: started
time=0ms (for benchmark_census)
benchmark_census: ok
calculation_summary: started
time=12595ms (for calculation_summary)
calculation_summary: ok
configurable_settings: started
configurable_settings: skipped (not running distribution tests)
create_open_census: started
time=186ms (for create_open_census)
create_open_census: ok
create_open_database: started
time=596ms (for create_open_database)
create_open_database: ok
create_open_gpt: started
time=797ms (for create_open_gpt)
create_open_gpt: ok
create_open_illustration: started
time=2734ms (for create_open_illustration)
create_open_illustration: ok
create_open_mec: started
time=646ms (for create_open_mec)
create_open_mec: ok
create_open_policy: started
time=470ms (for create_open_policy)
create_open_policy: ok
create_open_rounding: started
time=1311ms (for create_open_rounding)
create_open_rounding: ok
create_open_strata: started
time=313ms (for create_open_strata)
create_open_strata: ok
create_open_text: started
time=121ms (for create_open_text)
create_open_text: ok
default_input: started
default_input: skipped (not running distribution tests)
default_update: started
default_update: skipped (not running distribution tests)
expiry_dates: started
Expiry dates: begin=2450449 (1996-12-31), end=2472011 (2056-01-13)
time=1ms (for expiry_dates)
expiry_dates: ok
input_sequences: started
input_sequences: ERROR (Assertion failure: strftime() failed [file 
/__w/lmi/lmi/third_party/wx/src/common/datetime.cpp, line 296, in 
wxCallStrftime()].)
input_validation: started
input_validation: skipped (not running distribution tests)
log_error: started
time=0ms (for log_error)
log_error: ok
paste_census: started
paste_census: ERROR (Assertion failure: strftime() failed [file 
/__w/lmi/lmi/third_party/wx/src/common/datetime.cpp, line 296, in 
wxCallStrftime()].)
pdf_census: started
time=2547ms (for pdf_census)
pdf_census: ok
pdf_illustration: started
pdf_illustration: ERROR (Assertion failure: strftime() failed [file 
/__w/lmi/lmi/third_party/wx/src/common/datetime.cpp, line 296, in 
wxCallStrftime()].)
validate_output_census: started
validate_output_census: ERROR (Assertion failure: strftime() failed [file 
/__w/lmi/lmi/third_party/wx/src/common/datetime.cpp, line 296, in 
wxCallStrftime()].)
validate_output_illustration: started
validate_output_illustration: ERROR (Assertion failure: strftime() failed [file 
/__w/lmi/lmi/third_party/wx/src/common/datetime.cpp, line 296, in 
wxCallStrftime()].)
validate_output_mec: started
time=321ms (for validate_output_mec)
validate_output_mec: ok
time=32316ms (for all tests)
FAILURE: 5 out of 25 tests failed.
NOTE: 4 tests were skipped
0064:err:ole:start_rpcss Failed to open RpcSs service
---------------------------------- >8 --------------------------------------

 Obviously your last commit a4a993dfe (Merge 'blessed' proprietary
repositories, 2022-03-04) didn't change anything in lmi code (and, in
fact, the CI builds shouldn't have run at all and I'll fix the path
expression in the workflow file to prevent this happening again in the
future), so it's not due to the changes in lmi itself but probably due
to Wine upgrade from 5.0.3 to 6.0.2, which seems to have happened
relatively recently in Debian Sid.

 Unfortunately I can't reproduce the error locally in my Sid chroot and I
have no idea why would strftime(), called by wxCallStrftime(), fail. After
looking at this code, we could get rid of wxCallStrftime() calls that are
done by wxDateTime::FormatDate(), which is used by wxGridCellDateRenderer
and that we also currently use directly, with this change:

---------------------------------- >8 --------------------------------------
diff --git a/census_view.cpp b/census_view.cpp
index 4b10635ec..eecb05aa7 100644
--- a/census_view.cpp
+++ b/census_view.cpp
@@ -469,8 +469,7 @@ class table_date_converter
   public:
     wxString to_renderer_value(std::string const& value) const override
     {
-        auto const date = ConvertDateToWx(value_cast<calendar_date>(value));
-        return date.FormatDate();
+        return value_cast<calendar_date>(value).str();
     }
 
     std::string from_editor_value(wxString const& value) const override
@@ -485,7 +484,7 @@ class table_date_converter
   private:
     wxGridCellRenderer* create_renderer() const override
     {
-        return new(wx) wxGridCellDateRenderer();
+        return new(wx) wxGridCellStringRenderer();
     }
 
     wxGridCellEditor* create_editor() const override
---------------------------------- >8 --------------------------------------

but I don't like changing the code to work around a problem I don't
understand, doing this makes the format used for the displayed date (always
ISO 8601) and for the date being edited (the short date format used in the
current locale, which will probably be different from ISO 8601 in any
environment except those used by lmi developers). And even if we did this,
wxCallStrftime() would still be used in other places, notably inside
wxGridCellDateEditor that we still need to use.

 The really puzzling thing is that I can't reproduce the problem even
though I'm using exactly the same commands for building everything in an
environment that should normally be exactly the same too. I'll try to
recreate the *exactly* same environment later. I even thought that these
strftime failures could somehow be time-dependent, but I've checked that
the arguments of wxCallStrftime() don't depend on the current time (except
for just one of them, done to get the time zone once only), so this can't
be due to this neither. And yet it seems to be reliably reproducible in the
GitHub CI environment, as it happened in the next rebuild, that I launched
manually, too. Note that in both cases it only happens in 32 bit build, not
in 64 bits. A sign that we should be switching to the latter, perhaps?

 Anyhow, I'll try to return to this a.s.a.p. and hopefully will find a way
to reproduce it.

 Best regards,
VZ

Attachment: pgpTYxJRKYEfb.pgp
Description: PGP signature


reply via email to

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