Closed mpw5421 closed 8 months ago
@wangli5665 any change you could have look into it?
@mpw5421 Any chance running this under gdb and getting a backtrace? See: https://github.com/linux-test-project/ltp/#debugging-with-gdb
@metan-ucw I read the link you provided, but wasn't exactly sure how to execute that.
I ran the test manually under strace since I knew how to do that from troubleshooting other LTP testcases I opened bugs for against RedHat. The output is attached.
Doesn't reproduce for me on RHEL9.3. Could you try running it under valgrind? (e.g. valgrind ./irqbalance01)
Also, is this x86_64 or ppc64le?
Also, is this x86_64 or ppc64le?
It's actually s390x on LPAR. Sorry for not including that in the original comment.
Sure, valgrind output attached:
@mpw5421 Thanks, that looks like we have a bug in test, which fails to parse /proc/interrupts. Could you please attach also output of "cat /proc/interrupts"?
It appears to be enough to move named interrupts to begging of file to trigger it on x86 as well. "row" variable keeps incrementing and eventually there's a write out-of-bounds:
irqbalance01.c:129: TINFO: Found 8 CPUS, 45 IRQs
realloc(): invalid next size
tst_test.c:1653: TBROK: Test killed by SIGIOT/SIGABRT!
Output from cat /proc/interrupts:
Thanks, that confirms my suspicion. It's a bit too late today, so this could be wrong, but I was thinking:
@@ -154,7 +154,6 @@ static void collect_irq_info(void)
if (acc != -1)
tst_brk(TBROK, "Unexpected EOL");
col = 0;
- row++;
break;
case '0' ... '9':
if (acc == -1)
@@ -167,6 +166,7 @@ static void collect_irq_info(void)
if (acc == -1 || col != 0)
tst_brk(TBROK, "Unexpected ':'");
irq_ids[row] = acc;
+ row++;
acc = -1;
break;
default:
CC @richiejp
To be honest I can't remember how it works and I'm not working on LTP at the moment. However it sounds plausible because the parser made a lot of assumptions about the file format.
v1 patch posted to ML: https://lists.linux.it/pipermail/ltp/2024-January/036666.html
I opened a bugzilla against RedHat for the irqbalance01 testcase on RHEL9.3, but since the testcase is reported as broken I was instructed to open an issue against LTP instead. Here is the testcase output from a RHEL9.3 system: