On vanilla 2.6.14 the following alias causes a seg fault when probed: probe kernel.syscall.fadvise64 = kernel.function("sys_fadvise64_64") { name = "fadvise64" fd = $fd offset = $offset len = $len advice = $advice }
Please be more specific. Is this a translator SEGV? On which architecture? (I can't trigger it on an i686 or x86_64 with cvs systemtap against a recent FC4 kernel.) Or is this a probe execution-time crash? More details?
OK, I can reproduce the segv; -22.17.EL i686 kernel, cvs systemtap. % stap -e 'probe kernel.syscall.fadvise64 {}' The crash occurs in loc2c.c, during the processing of the $len 64-bit target variable. I attach a vmware png screenshot (sorry) of the gdb backtrace. The given "location" pointer appears to be corrupt. Another data point. When the same test is run on a recentish FC3 kernel, the translator succeeds. Oddly, for an 8-byte value, only a single "piece" is fetched. If so, maybe the debuginfo is again crappy. Still if so, loc2c should live with that better. intptr_t value; { union { char bytes[8]; struct { uint0_t p0; } pieces __attribute__ ((packed)); uint64_t whole; } u; intptr_t addr; { // DWARF expression: 0x74 { intptr_t s0; s0 = fetch_register (4) + 0L; addr = s0; } } u.pieces.p0 = deref (sizeof u.pieces.p0, addr); value = u.whole; } printk (" ---> %ld\n", (unsigned long) value);
Created attachment 767 [details] vmware backtrace screenshot
Please point to the particular kernel build that produced the loc2c-test output in comment #2.
Unless there is more than one 2.6.9-22.17.EL i686 kernel, it'd be the one under dist/4E-U3.
That is not what I asked. Supply details about the "recentish FC3 kernel" build from which the loc2c-test output in comment #2 comes.
Oh. The FC3 kernel. 2.6.12-1.1381_FC3smp i686
It does appear that both failure modes for those different kernels were the same bug. I've checked in some fixes to loc2c to handle the problem case. The bug arose when a noncontiguous location is partially in memory and partially in registers. After the fix, the loc2c-test output for the 1.1381_FC3 kernel looks correct. I was not able to test running probes on that kernel because the kernel-smp-devel rpms for that version seem to be AWOL. On the RHEL4 kernel, the fix cures the crash and I saw no testsuite failures. Please verify the fix further.
Works great, thanks.