This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: FAIL in 2.6.24-rc3
- From: Srinivasa Ds <srinivasa at in dot ibm dot com>
- To: Wenji Huang <wenji dot huang at oracle dot com>
- Cc: systemtap at sourceware dot org
- Date: Mon, 26 Nov 2007 14:49:32 +0530
- Subject: Re: FAIL in 2.6.24-rc3
- References: <474A7736.6030602@oracle.com>
Wenji Huang wrote:
It seems that accessing parameters in return probe results in the above
failures.
I could reproduce the problem on x86_64 and ppc64. On debugging with GDB, It looks like reason for failure in both the testcases are similar.
=====================================================
Loaded symbols for /home/systemtap/tmp/stap_testing_200711260838/install/lib/systemtap/libebl_x86_64.so
Core was generated by `./stap -vvvv ../src/testsuite/buildok/fortyfive.stp'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004519c9 in require<expression*> (v=0x7fffa9be2860,
dst=0x7fffa9be28d8, src=0x202c642522286674)
at /home/systemtap/tmp/stap_testing_200711260838/src/staptree.h:845
845 src->visit(v);
(gdb)
(gdb)
(gdb) t
[Current thread is 1 (process 14563)]
(gdb) bt
#0 0x00000000004519c9 in require<expression*> (v=0x7fffa9be2860,
dst=0x7fffa9be28d8, src=0x202c642522286674)
at /home/systemtap/tmp/stap_testing_200711260838/src/staptree.h:845
#1 0x0000000000451aa2 in deep_copy_visitor::deep_copy (s=0x202c642522286674)
at /home/systemtap/tmp/stap_testing_200711260838/src/staptree.cxx:2389
#2 0x00000000004837e0 in derived_probe (this=0x2776d40, p=0xc3d210, l=0xc3d080)
at /home/systemtap/tmp/stap_testing_200711260838/src/elaborate.cxx:56
#3 0x0000000000532aa2 in be_derived_probe (this=0x2776d40, p=0xc3d210,
l=0xc3d080, t=BEGIN, pr=0)
at /home/systemtap/tmp/stap_testing_200711260838/src/tapsets.cxx:85
#4 0x00000000005331e6 in be_builder::build (this=0x82b360, base=0xc3d210,
location=0xc3d080, parameters=@0x7fffa9be2b70,
finished_results=@0x7fffa9be3530)
========================================
Problem is not there in kretprobes, but may be in processing return value.
Is that related to kernel config? Do I miss something?
No, Its a bug.
Thanks
Srinivasa DS