Actions
action #133319
openBackend dies when passing russian letters to the 'type_string' function
Status:
New
Priority:
Normal
Assignee:
-
Category:
Regressions/Crashes
Target version:
QA (public, currently private due to #173521) - future
Start date:
2023-07-25
Due date:
% Done:
0%
Estimated time:
Description
Observation¶
The backend process dies after passing russian language characters to the 'type_string' function:
Result: incomplete, finished about 18 hours ago (01:41 minutes)
Reason: backend died: No map for 'Ã' at /usr/lib/os-autoinst/consoles/VNC.pm line 660.
Also, when using russian language in 'virtual_terminal', for example, by using the 'assert_script_run' function, these characters are displayed in 'serial_terminal' as a set of characters "Ã", "Â" and "µ":
# echo "ÃÂõÃÂÃÂ" > ÃÂõÃÂÃÂ; echo Cq4TM-$?-
autoinst-log
Steps to reproduce¶
- Create 'test_language/t01_test_type_string.pm'
- Create 'test_language/t02_test_assert_script_run.pm'
- Prepare 'main.pm'
- Create a job
- Observe result for 'type_string'
- Replace the Russian word "тест" with the English "test" in 'test_language/t01_test_type_string.pm'
- Create a job
- Observe result for 'assert_script_run'
Impact¶
We estimate the impact of the problem very highly, since the possibility of full-fledged testing of products with Russian interfaces is blocked.
Problem¶
- Encoding problems?
- Missing settings / variables?
- Incorrectly configured PostgreSQL database?
By the way, before launching 'openqa-setup-db.service', we decided to try to create a PostgreSQL database with the locale 'en_US.UTF-8', instead of 'ru_RU.UTF-8' by default, due to the language of the system.
According to the "Migrating PostgreSQL database on OpenSUSE" (https://open.qa/docs/#_migrating_postgresql_database_on_opensuse / "5. Prepare the migration" / 2nd "IMPORTANT" note) before setting up openQA, the database was initialized with the standard openQA locale and encoding:
--encoding=UTF 8 --locale=en_US.UTF-8 --lc-collate=C --lc-ctype=en_US.UTF-8 --lc-messages=C --lc-monetary=C --lc-numeric=C --lc-time=C
But, unfortunately, this did not affect the reproduction of the error. - Perhaps the OCR that is not working with us is related to this issue, but that's another story...
Workaround¶
Currently unknown.
Files
Actions