osandov / drgn

Programmable debugger
Other
1.78k stars 165 forks source link

tests: tests are failing on powerpc #414

Closed sourabhjains closed 4 months ago

sourabhjains commented 4 months ago

Found that the following tests are failing on PowerPC:

  1. tests.linux_kernel.helpers.test_common.test_identify_vmap

def test_identify_vmap(self): self.assertTrue( identify_address(self.prog["drgn_test_vmalloc_va"]).startswith("vmap: 0x") )

Seems like the expected address is vmap where as on PowrePC identify_address returns vmap stack: ... from identify function.

For example:

Expected (x86)

>>> identify_address(prog["drgn_test_vmalloc_va"])
'vmap: 0xffffaa50c0ab3000-0xffffaa50c0ab5000'

On PowerPC:

>>> identify_address(prog["drgn_test_vmalloc_va"])
'vmap stack: 1 (systemd) +0x8000001098000'

Any hint on what is going wrong?

  1. tests.linux_kernel.helpers.test_stackdepot.TestStackDepot)

    
    Traceback (most recent call last):
    File "/root/drgn/tests/linux_kernel/helpers/test_stackdepot.py", line 20, in test_stack_depot_fetch
    self._test_drgn_test_kthread_trace(
    File "/root/drgn/tests/linux_kernel/test_stack_trace.py", line 21, in _test_drgn_test_kthread_trace
    for i, frame in enumerate(trace):
    TypeError: 'NoneType' object is not iterable

Seem like pool_index is calculated wrong. Doing the following change in stack_depot_fetch function fixes the test:

--- a/drgn/helpers/linux/stackdepot.py +++ b/drgn/helpers/linux/stackdepot.py @@ -43,9 +43,12 @@ def stack_depot_fetch(handle: Object) -> Optional[StackTrace]: try: pool_index = handle_parts.pool_index_plus_1 - 1 except AttributeError:



Please share you thoughts on above test failure and proposed fix.

Thanks,
Sourabh Jain
osandov commented 4 months ago

1 is a legitimate bug that I missed. I just pushed the fix, but please reopen this if you find that it wasn't fixed.

2 is likely a known breakage in the kernel that unfortunately slipped in for a couple of rcs and stable releases. The comment in the helper explains the situation: https://github.com/osandov/drgn/blob/1832240fc639413530063b1a52b2c3f37b0654f4/drgn/helpers/linux/stackdepot.py#L37-L46 If the kernel you're testing has commit torvalds/linux@3ee34eabac2abb6b1b6fcdebffe18870719ad000 but not torvalds/linux@a6c1d9cb9a68bfa4512248419c4f4d880d19fe90, you'll need to apply the latter. If that doesn't fix it, please let me know.

sourabhjains commented 4 months ago

1 is a legitimate bug that I missed. I just pushed the fix, but please reopen this if you find that it wasn't fixed.

Thanks for the fix. I will try it out.

2 is likely a known breakage in the kernel that unfortunately slipped in for a couple of rcs and stable releases. The comment in the helper explains the situation:

https://github.com/osandov/drgn/blob/1832240fc639413530063b1a52b2c3f37b0654f4/drgn/helpers/linux/stackdepot.py#L37-L46

If the kernel you're testing has commit torvalds/linux@3ee34ea but not torvalds/linux@a6c1d9c, you'll need to apply the latter. If that doesn't fix it, please let me know.

Thanks for the info. I will include kernel fix and try again.