This is an archive of the discontinued LLVM Phabricator instance.

[LLDB] On Windows, fix tests
ClosedPublic

Authored by aganea on Oct 7 2020, 9:05 AM.

Details

Summary

This patch fixes a few issues seen when running ninja check-lldb in a Release build:

  • Some binaries couldn't be found (such as lldb-vscode.exe), because .exe wasn't appended to the file name.
  • Many tests used to fail since the OS error messages are not emitted in English, because of our installed French locale.
  • Also, because of our codepage being Windows-1252, python failed to decode the messages.

After this patch, all tests pass with VS2017.
When building with VS2019 or Clang 10, the following tests still do not pass:

lldb-api :: python_api/lldbutil/iter/TestLLDBIterator.py
lldb-shell :: SymbolFile/PDB/enums-layout.test
lldb-shell :: SymbolFile/PDB/typedefs.test
lldb-unit :: tools/lldb-server/tests/./LLDBServerTests.exe/StandardStartupTest.TestStopReplyContainsThreadPcs

For the first three tests above, this has to do with the debug info not being emitted as expected. I'm not sure about the last one.

Diff Detail

Event Timeline

aganea created this revision.Oct 7 2020, 9:05 AM
Herald added a project: Restricted Project. · View Herald Transcript
aganea requested review of this revision.Oct 7 2020, 9:05 AM
labath added a comment.Oct 7 2020, 9:18 AM

Is there a way to force a program to use a specific locale, ignoring the system-wide setting (something like export LC_ALL=C on unix)? Hardcoding the error message for all locales is not a viable long term strategy... :/

It's interesting that I haven't encountered some of these errors. There are five _other_ lldb tests that do fail for me. I have a fix in the works for some of those.

I agree with @labath that including error message patterns in various languages isn't scalable. Since dotest,py is starting up the processes under test, perhaps there's a way to force it to use a particular locale. Besides the language of system error messages, locales can change the format of numbers, dates, etc.

Unfortunately, I don't think it's as simple as an environment variable. I expect this is driven by the user's (or system default) locales settings as tracked by Windows. That's distinct from the C runtime concept of locales.

Maybe dotest.py could change its own Windows locale setting and the processes it spawns would inherit that. I don't know if that would work, but I don't see a good alternative.

lldb/unittests/Utility/StatusTest.cpp
80

Rather than an early return, perhaps the code should still be exercised, but the language-specific EXPECTs could be skipped.

Maybe dotest.py could change its own Windows locale setting and the processes it spawns would inherit that. I don't know if that would work, but I don't see a good alternative.

One problem is that some users might not have the English language pack installed. I only have fr-CA and en-CA installed but not en-US. There's absolutely no guarantee that there will be a en-XX package available. I'll do some more testing and upload a new diff, but I took a defensive approach, like for StatusTest.cpp, where the two tests below in TestTargetCommand.py would only run if en-US is the current locale. Maybe afterwards, in a subsequent patch, we could add more code to temporarily switch to en-US locale if it's available?

I really want to avoid having language specific strings in the tests. Skipping tests which depend on these is a reasonable approach (as you've discovered, there shouldn't be that many of them -- it's really just the tests which check that we actually can retrieve the error from the OS), and it could be later improved by switching to an english locale on a best-effort basis (i.e., if the locale is available).

I really want to avoid having language specific strings in the tests.

We all agree on that. I'll update the patch once it passes all tests on my machines.

aganea updated this revision to Diff 296809.Oct 7 2020, 3:12 PM
aganea marked an inline comment as done.

As discussed above:

  • Remove locale-specific messages.
  • Skip relevant locale-sensitive TestTargetCommand tests.
  • Only skip EXPECT calls in Utility/StatusTest.
aganea added a comment.EditedOct 7 2020, 3:35 PM

It's interesting that I haven't encountered some of these errors. There are five _other_ lldb tests that do fail for me. I have a fix in the works for some of those.

Please see my (remaining) failing tests (with VS2019 16.7.5):

labath accepted this revision.Oct 8 2020, 5:10 AM

This looks fine. Thanks.

lldb/unittests/Utility/StatusTest.cpp
76

llvm::array_lengthof(name);

77

reinterpret_cast?

This revision is now accepted and ready to land.Oct 8 2020, 5:10 AM
aganea marked 2 inline comments as done.Oct 8 2020, 8:46 AM

Thank you all for your time!

This revision was landed with ongoing or failed builds.Oct 8 2020, 8:47 AM
This revision was automatically updated to reflect the committed changes.
aganea added a comment.Oct 8 2020, 2:35 PM

I've commited one more fix here: https://reviews.llvm.org/rG97e7fbb343e2 - This didn't occur locally on my machine, but only on another machine. But in essence, the issue was the same, an accentuated Windows-1252 codepage character that was being decoded as UTF-8 by the Python runtime.