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.
Bug 732346 - warning: make exited with status: 2
Summary: warning: make exited with status: 2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: systemtap
Version: 6.2
Hardware: All
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Frank Ch. Eigler
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
: 745953 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-22 05:46 UTC by Han Pingtian
Modified: 2011-12-06 15:18 UTC (History)
6 users (show)

Fixed In Version: systemtap-1.6-4
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2011-12-06 15:18:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
verbose outputs of stap -l 'kernel.trace("*")' (464.62 KB, text/plain)
2011-08-22 05:46 UTC, Han Pingtian 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1517 0 normal SHIPPED_LIVE systemtap bug fix and enhancement update 2011-12-06 00:50:46 UTC
Sourceware 13100 0 P2 RESOLVED Building tracepoint cache all at once fails when kernel debuginfo installed 2020-06-26 19:08:18 UTC

Description Han Pingtian 2011-08-22 05:46:49 UTC 
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:
Comment 2 David Smith 2011-09-08 18:32:53 UTC 
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.
Comment 3 Frank Ch. Eigler 2011-09-20 14:52:27 UTC 
upstream commit e86f32e makes the "Warning: make exited with status: 2"
message go away.
Comment 4 Frank Ch. Eigler 2011-09-21 14:19:05 UTC 
Let's repurpose this PR as to the misleading warning.
Hidden build problems with tracepoint headers can be left to bug #730884.
Comment 6 Frank Ch. Eigler 2011-09-30 14:36:31 UTC 
During the next respin, we need to add upstream commit a73b5001 - another
one-liner - to fix another warning mistakenly introduced by my patch above.
Comment 8 Frank Ch. Eigler 2011-10-13 15:44:36 UTC 
*** Bug 745953 has been marked as a duplicate of this bug. ***
Comment 9 Frank Ch. Eigler 2011-10-13 15:46:32 UTC 
At least upstream commit #a73b5001 needs to be added to this patch,
in order to silence a warning introduced by this patch.
Comment 15 William Cohen 2011-11-11 20:13:22 UTC 
    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.
Comment 16 errata-xmlrpc 2011-12-06 15:18:30 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, 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
Note You need to log in before you can comment on or make changes to this bug.