Bug 2028840

Summary: [ppc64le] Assertion `index >= 0' failed
Product: Red Hat Enterprise Linux 8 Reporter: Martin Cermak <mcermak>
Component: systemtapAssignee: William Cohen <wcohen>
systemtap sub component: system-version QA Contact: Martin Cermak <mcermak>
Status: CLOSED ERRATA Docs Contact:
Severity: low    
Priority: unspecified CC: dsmith, fche, lberk, mcermak, mjw, scox, wcohen
Version: 8.6Keywords: Bugfix, Patch, Triaged
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: systemtap-4.7-1.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 2047256 (view as bug list) Environment:
Last Closed: 2022-11-08 09:35:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2047256    

Description Martin Cermak 2021-12-03 14:20:38 UTC
This happens (100% reproducible) on ppc64le only with 4.18.0-353.el8.ppc64le and systemtap-4.6-2.el8.ppc64le:

scr0   8.6 Server ppc64le # cat fork.stp 
#!/usr/bin/stap -g

global sshd_fork_count
global fork_to_fail=1

probe begin {
    printf("Started\n\n")
}

probe kernel.function("*do_fork").call {
    if (execname() == "sshd") {
        sshd_fork_count++
        printf(">>>%s[%5d] %s\n", execname(), pid(), $$parms)
        printf("  PPID=%d\n",ppid())
        printf("  sshd_fork_count=%d\n",sshd_fork_count)
    }
}

probe kernel.function("*do_fork").return {
    if (execname() == "sshd") {
        printf("<<<%s[%5d] %s\n", execname(), pid(), $$return)
        printf("  PPID=%d\n",ppid())
        printf("  RETURN:%d\n\n",$return)
        if (sshd_fork_count == fork_to_fail) {
            printf("!!! fork() will return -1\n")
            $return = -1
        }
    }
}

scr0   8.6 Server ppc64le # stap -vp2 -g fork.stp
Pass 1: parsed user script and 509 library scripts using 143488virt/108224res/21568shr/84096data kb, in 750usr/30sys/1025real ms.
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
stap: /builddir/build/BUILD/dyninst-11.0.0/dyninst-11.0.0/dataflowAPI/src/liveness.C:418: bool LivenessAnalyzer::query(Dyninst::ParseAPI::Location, LivenessAnalyzer::Type, const Dyninst::MachRegister&, bool&): Assertion `index >= 0' failed.
Aborted (core dumped)
(134) scr0   8.6 Server ppc64le #

Comment 2 Frank Ch. Eigler 2021-12-03 15:51:35 UTC
It doesn't look like this test should even trigger the liveness analyzer.  But it'd be good to make it robust with whatever bothered it here.

Comment 3 William Cohen 2021-12-03 16:50:26 UTC
There is a $return=-1 in probe kernel.function("*do_fork").return which could trigger the analysis as it is a write.  However, the question is what is causing:

stap: /builddir/build/BUILD/dyninst-11.0.0/dyninst-11.0.0/dataflowAPI/src/liveness.C:418: bool LivenessAnalyzer::query(Dyninst::ParseAPI::Location, LivenessAnalyzer::Type, const Dyninst::MachRegister&, bool&): Assertion `index >= 0' failed.

It looks like there is something going wrong with the register name machReg being passed into:

bool LivenessAnalyzer::query(Location loc, Type type, const MachRegister& machReg, bool &live){
	bitArray liveRegs;
	if (query(loc, type, liveRegs)){
        int index = getIndex(machReg);
        assert(index >= 0);
		live = liveRegs[index];
		return true;
	}
	return false;

}

One possible way things could be going wrong is if register width is gotten wrong and the wrong register name, 32-bit name rather than 64-bit, is passed in.  The analysis code is really picky about the register names being used as there are some differences in the ABIs between 32-bit and 64-bit variants of architectures (particularly x86).

I was thinking that some odd dwarf register number is being passed in, but if that was the case the analysis wouldn't run and the assert wouldn't happen.

Comment 4 William Cohen 2021-12-03 19:38:24 UTC
The register dyninst register selected for the liveness analysis looks sane, ppc64::r3.  The dyninst code is getting a bit confused whether this is 32-bit or 64-bit code being analyzed. It does 64-bit liveness analysis, but tries to use mappings for 32-bit register names (https://github.com/dyninst/dyninst/issues/1165).  That results in the ppc64::r3 not being found because the index only has ppc32::rn entries and the assert failing.

Comment 5 William Cohen 2021-12-04 02:11:15 UTC
Have a proposed systemtap patch on following branch that works around the issue with the ppc64/ppc32 register naming and avoids the assert fail:

https://sourceware.org/git/?p=systemtap.git;a=shortlog;h=refs/heads/wcohen/rhbz2028840

With the patch:

# stap -vp4 -g fork.stp
Pass 1: parsed user script and 509 library scripts using 143488virt/108224res/21632shr/84096data kb, in 290usr/30sys/308real ms.
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
Pass 2: analyzed script: 7 probes, 10 functions, 0 embeds, 2 globals using 3932992virt/2243072res/207744shr/3630080data kb, in 94210usr/970sys/17228real ms.
Pass 3: translated to C into "/tmp/stapY0bigs/stap_6f843142437f76749d5af4925919c4d7_5836_src.c" using 3932992virt/2243328res/208000shr/3630080data kb, in 30usr/80sys/115real ms.
/root/.systemtap/cache/6f/stap_6f843142437f76749d5af4925919c4d7_5836.ko
Pass 4: compiled C into "stap_6f843142437f76749d5af4925919c4d7_5836.ko" in 44200usr/1950sys/9341real ms.


There looks to be dyninst an issue with ppc64 handling related to this:

https://github.com/dyninst/dyninst/issues/1142

Comment 6 Martin Cermak 2022-05-13 11:46:24 UTC
Verified with systemtap-4.7-1.el8, dyninst-12.1.0-1.el8, on top of kernel-4.18.0-387.el8.  The script from Comment#0 now compiles (-vp2) without issues on all the arches.

Comment 9 errata-xmlrpc 2022-11-08 09:35:22 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (systemtap bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7538