Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause
stap tests which tracepoints ('kernel.trace("*")') are available
by using a "make" command.
Consequence
When stap first searches for those available tracepoints it
will print out a number of error messages from the "make" which
are harmless. SystemTap caches the results, so only the first
run of the search produces the extraneous error messages.
Fix
The "make" for the tracepoint search was replaces with "make -i"
(ignore errors) so the messages from those make operations
testing the availability of the tracepoints are not seen by the user.
Result
There is no misleading output when performing from the internal
"make" process stap uses to determine the available tracepoints.
Created attachment 519221[details]
verbose outputs of stap -l 'kernel.trace("*")'
Description of problem:
This problem can only be produced once on one system. When running this command:
stap -l 'kernel.trace("*")' -vvvv
in the first time on a system, it will echo some warning messages like
Warning: make exited with status: 2
and there are some compiling error messages in the verbose outputs like
...
include/linux/jbd2.h:1225: note: previous definition of ‘is_journal_aborted’ was here
include/linux/jbd.h:1033: error: redefinition of ‘is_handle_aborted’
include/linux/jbd2.h:1230: note: previous definition of ‘is_handle_aborted’ was here
include/linux/jbd.h:1050: error: redefinition of ‘tid_gt’
include/linux/jbd2.h:1247: note: previous definition of ‘tid_gt’ was here
include/linux/jbd.h:1056: error: redefinition of ‘tid_geq’
include/linux/jbd2.h:1253: note: previous definition of ‘tid_geq’ was here
include/linux/jbd.h:1068: error: redefinition of ‘jbd_space_needed’
include/linux/jbd2.h:1266: note: previous definition of ‘jbd_space_needed’ was here
In file included from include/trace/events/jbd.h:7,
from /tmp/stapvdbvYi/tracequery_kmod_1/tracequery_kmod_1.c:44:
include/linux/jbd.h:1084:1: error: "BJ_Metadata" redefined
In file included from /usr/src/debug////////kernel-2.6.32-191.el6/linux-2.6.32-191.el6.ppc64/fs/ext4/ext4.h:22,
from /tmp/stapvdbvYi/tracequery_kmod_1/tracequery_kmod_1.c:26:
include/linux/jbd2.h:1281:1: error: this is the location of the previous definition
In file included from include/trace/events/jbd.h:7,
from /tmp/stapvdbvYi/tracequery_kmod_1/tracequery_kmod_1.c:44:
include/linux/jbd.h:1085:1: error: "BJ_Forget" redefined
...
But when run it second times, there is no such warning messages any more.
Version-Release number of selected component (if applicable):
kernel 2.6.32-191.el6
systemtap-1.6-2.el6
How reproducible:
always
Steps to Reproduce:
1. refresh install a system,
2. on the system, run stap -vvvv -l 'kernel.trace("*")'
3.
Actual results:
will get warning messages and compiling errors for the first time run
Expected results:
Additional info:
You can reproduce this one on a non-freshly installed system like this:
# rm -rf ~/.systemtap/cache
# stap -vvvv -l 'kernel.trace("*")'
These messages are seen only the first time because the results get cached, so future runs use the cached results.
There is a similar upstream bug, sourceware pr13100. These are really just "soft" errors, since after that compile fails systemtap will try a slower method.
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
stap tests which tracepoints ('kernel.trace("*")') are available
by using a "make" command.
Consequence
When stap first searches for those available tracepoints it
will print out a number of error messages from the "make" which
are harmless. SystemTap caches the results, so only the first
run of the search produces the extraneous error messages.
Fix
The "make" for the tracepoint search was replaces with "make -i"
(ignore errors) so the messages from those make operations
testing the availability of the tracepoints are not seen by the user.
Result
There is no misleading output when performing from the internal
"make" process stap uses to determine the available tracepoints.
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/RHBA-2011-1517.html
Created attachment 519221 [details] verbose outputs of stap -l 'kernel.trace("*")' Description of problem: This problem can only be produced once on one system. When running this command: stap -l 'kernel.trace("*")' -vvvv in the first time on a system, it will echo some warning messages like Warning: make exited with status: 2 and there are some compiling error messages in the verbose outputs like ... include/linux/jbd2.h:1225: note: previous definition of ‘is_journal_aborted’ was here include/linux/jbd.h:1033: error: redefinition of ‘is_handle_aborted’ include/linux/jbd2.h:1230: note: previous definition of ‘is_handle_aborted’ was here include/linux/jbd.h:1050: error: redefinition of ‘tid_gt’ include/linux/jbd2.h:1247: note: previous definition of ‘tid_gt’ was here include/linux/jbd.h:1056: error: redefinition of ‘tid_geq’ include/linux/jbd2.h:1253: note: previous definition of ‘tid_geq’ was here include/linux/jbd.h:1068: error: redefinition of ‘jbd_space_needed’ include/linux/jbd2.h:1266: note: previous definition of ‘jbd_space_needed’ was here In file included from include/trace/events/jbd.h:7, from /tmp/stapvdbvYi/tracequery_kmod_1/tracequery_kmod_1.c:44: include/linux/jbd.h:1084:1: error: "BJ_Metadata" redefined In file included from /usr/src/debug////////kernel-2.6.32-191.el6/linux-2.6.32-191.el6.ppc64/fs/ext4/ext4.h:22, from /tmp/stapvdbvYi/tracequery_kmod_1/tracequery_kmod_1.c:26: include/linux/jbd2.h:1281:1: error: this is the location of the previous definition In file included from include/trace/events/jbd.h:7, from /tmp/stapvdbvYi/tracequery_kmod_1/tracequery_kmod_1.c:44: include/linux/jbd.h:1085:1: error: "BJ_Forget" redefined ... But when run it second times, there is no such warning messages any more. Version-Release number of selected component (if applicable): kernel 2.6.32-191.el6 systemtap-1.6-2.el6 How reproducible: always Steps to Reproduce: 1. refresh install a system, 2. on the system, run stap -vvvv -l 'kernel.trace("*")' 3. Actual results: will get warning messages and compiling errors for the first time run Expected results: Additional info: