Project

General

Profile

action #57698

[QAM] test fails in gdb

Added by osukup about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2019-10-04
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-15-SP1-Server-DVD-Updates-s390x-mau-extratests@zkvm fails in
gdb

Test suite description

Run console tests against aggregated test repo

Reproducible

Fails since (at least) Build 20190911-1

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #56969: [qam] test fails in javaResolved2019-09-17

History

#1 Updated by apappas about 3 years ago

I don't think that this is a bug in the test, but a bug in openQA. The serial console is not working again, so the wait_serial function is failing.

#2 Updated by okurz about 3 years ago

apappas I think it simply never worked. It's unfortunate that it seems there is so little care for failing tests hence this was never detected because on s390x there is no (easy) way to revert to snapshots so the job failed for very long in #56969 and never reached gdb. I do not know how this is supposed to ever work, to just start gdb and assume that string would show up on the serial port as it's never forwarded there.

#3 Updated by okurz about 3 years ago

#4 Updated by apappas about 3 years ago

I think it's best that I rewrite the test as a python script to be interpreted by gdb.
It will not then be interactive and I will be able to just use assert_script_run.

What do you think okurz?

#5 Updated by okurz about 3 years ago

Makes sense. As an alternative you might want to log all output of gdb to /dev/$serialdev which allows to still use wait_serial. Both approaches sound easy to me.

#6 Updated by brhavel about 3 years ago

  • Priority changed from Normal to Urgent

#7 Updated by coolo about 3 years ago

As it's Urgent now: if you can't get this done today, please take the test out of QAM (and keep the ticket open)

#8 Updated by apappas about 3 years ago

  • Subject changed from [QAM] test fails in gdb to test fails in gdb
  • Assignee deleted (apappas)

#9 Updated by apappas about 3 years ago

  • Subject changed from test fails in gdb to [QAM] test fails in gdb
  • Assignee set to apappas
  • Priority changed from Urgent to Normal

#11 Updated by coolo about 3 years ago

Your link is misleading as it 10-2 wasn't tested for s390x (for whatever reason): https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=20191013-1&groupid=232 fails

I worked around it now by setting EXCLUDE_MODULES=gdb. So please fix and validate with care :)

#12 Updated by okurz about 3 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: extra_tests_in_textmode
https://openqa.suse.de/tests/3575790

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed

#13 Updated by okurz about 3 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: extra_tests_in_textmode
https://openqa.suse.de/tests/3575790

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed

#14 Updated by apappas almost 3 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF