Red Hat Bugzilla – Bug 714773
qemu missing marker for qemu.kvm.qemu_vmalloc
Last modified: 2013-01-09 18:59:59 EST
Description of problem: qemu-kvm for rhel-6.1 has support for systemtap probes. There is a marker missing for qemu.kvm.qemu_vmalloc. Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.160.el6.x86_64 systemtap-1.4-6.el6_1.1.x86_64 systemtap-server-1.4-6.el6_1.1.x86_64 How reproducible: Always Steps to Reproduce: 1. Install the needed rpms: qemu-kvm systemtaptap 2. Get the uprobe module built as root: /usr/libexec/systemtap/stap-gen-cert make -C /usr/share/systemtap/runtime/uprobes 3. try to probe the problem place: stap -e 'probe qemu.kvm.qemu_vmalloc {printf("%s\n", pn())}' Actual results: Obtain the following error message: semantic error: no match while resolving probe point process("/usr/libexec/qemu-kvm").mark("qemu_vmalloc") semantic error: no match while resolving probe point qemu.kvm.qemu_vmalloc Pass 2: analysis failed. Try again with another '--vp 01' option. Expected results: Should probe the probe point without error. Additional info: There appears to be missing trace_qemu_vmalloc in the qemu-kvm/osdep.c file. Looking through the osdep.c file there is a trace_qemu_vmalloc() call in qemu_vmalloc() for the _WIN32 version, but the non-_WIN32 version doesn't have a trace call in it: /* alloc shared memory pages */ void *qemu_vmalloc(size_t size) { #ifndef __ia64__ return qemu_memalign(getpagesize(), size); #else return qemu_memalign(65536, size); #endif } There be a trace_qemu_vmalloc() in there.
I have reproduced this issue with steps in Comment #0. After step 3, got following error: # stap -e 'probe qemu.kvm.qemu_vmalloc {printf("%s\n", pn())}' semantic error: no match while resolving probe point process("/usr/libexec/qemu-kvm").mark("qemu_vmalloc") semantic error: no match while resolving probe point qemu.kvm.qemu_vmalloc Pass 2: analysis failed. Try again with another '--vp 01' option. Host info: # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.165.el6.x86_64 # rpm -qa|grep systemtap systemtap-runtime-1.4-6.el6.x86_64 systemtap-1.4-6.el6.x86_64 systemtap-server-1.4-6.el6.x86_64
Fix posted upstream, will backport as soon as it is accepted there.
It looks like the marker that was missing in upstream had already gone into our RHEL 6 tree, so the problem is different from what I had thought. Need to consult the author of the trace code to find out what could be going wrong. It looks like the marker for vmalloc is marked, but it doesn't show up in the symbol table for some reason. Back to the drawing board. Jes
Ok I was confused, the marker was indeed missing for non win32 - patch posted for rhel6.
Verified this issue with steps mentioned in Comment #0, after step 3, no error pop up. Additional test: Launched a guest, executed following script: # cat systemtap-vmalloc.stp probe qemu.kvm.qemu_vmalloc { printf("size is %d \n",size); } # stap systemtap-vmalloc.stp ... size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 16384 size is 131072 size is 131072 size is 16384 size is 8192 size is 65536 size is 65536 size is 16384 size is 16384 size is 16384 -----Conclusion: Based on Comment #2 and this comment, this issue has been fixed.
above testing based on following environment: # rpm -qa | grep systemtap systemtap-1.6-2.el6.x86_64 systemtap-sdt-devel-1.6-2.el6.x86_64 systemtap-runtime-1.6-2.el6.x86_64 systemtap-server-1.6-2.el6.x86_64 # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.184.el6.x86_64
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: missing probe marker for qemu.kvm.qemu_vmalloc Consequence: not possible to use "probe qemu.kvm.qemu_vmalloc" on a SystemTap script. Change: added marker to the qemu_vmalloc() function Result: now it's possible to use "probe qemu.kvm.qemu_vmalloc" on a SystemTap script
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2011-1531.html