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.

Bug 1113758

Summary: dbus-API-call test fail
Product: Red Hat Enterprise Linux 7 Reporter: Matěj Cepl <mcepl>
Component: dbusAssignee: David King <dking>
Status: CLOSED NOTABUG QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: dking, mcepl, vbenes, vrutkovs
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-16 15:03:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
testing code none

Description Matěj Cepl 2014-06-26 20:33:45 UTC
Created attachment 912572 [details]
testing code

Description of problem:
This test script runs the test script test.sh. This is the cover script:

    #!/bin/bash
    set -u
    CURDIR=$(readlink -f $(pwd))

    FLAGS=$(pkg-config --cflags --libs dbus-1)
    gcc -g -o dbus-API ${FLAGS} dbus-API.c

    su -c "dbus-launch $CURDIR/test.sh" test
    ERRCODE=$?

    pkill -u test -f dbus-daemon

    if [ $ERRCODE -eq 0 ] ; then
        RESULT="PASS"
    else
        RESULT="FAIL"
    fi

    rhts-report-result $TEST $RESULT "result.log"
    exit $ERRCODE

This is the test script test.sh:

    #!/bin/bash
    set -ux
    set +o posix

    echo "*** invoking dbus-API listen"
    ./dbus-API listen &

    echo "*** sending query 42"
    query_out=$(./dbus-API query 42)

    number=1
    if [ "$(uname -m)" == 's390x' ] || [ "$(uname -m)" == 'ppc64' ] ; then
        number=0
    fi

    query_wanted="Calling remote method with 42\n\
    Request Sent\n\
    Got Reply: $number, 21614"

    exit_code=0

    if cmp <(echo -e "$query_wanted") <(echo -e "$query_out") ; then
        echo -e "\nPASS: query output shown as expected:\n$query_wanted"
    else
        echo -e "\nFAIL: this should be shown:\n$query_wanted\nbut this was shown:"
        echo -e $query_out
        exit_code=1
    fi

    kill $(pidof dbus-API) >/dev/null 2>&1

    exit $exit_code

(./dbus-API is compiled from the attached C-code)

When run for the first time the test script fails as follows:

    [root@qe-dell-ovs5-vm-28 dbus-API-call]# ./runtest.sh 
    *** invoking dbus-API listen
    *** sending query 42
    Listening for method calls
    Argument is not boolean!
    cmp: EOF on /dev/fd/62

    FAIL: this should be shown:
    Calling remote method with 42
    Request Sent
    Got Reply: 1, 21614
    but this was shown:
    Calling remote method with 42 Request Sent
    dbus-API-call result: FAIL
       Log: result.log
       AVC_ERROR undefined. Using +no_file as default.
        Warning: AVC_ERROR environment variable not defined.  Using epoch as start time
         Searching logs...
         Info: No AVC messages found.
     Writing to /mnt/testarea/tmp.rhts-db-submit-result.HC8Rsw
    :
       AvcLog: /mnt/testarea/tmp.rhts-db-submit-result.HC8Rsw
    [root@qe-dell-ovs5-vm-28 dbus-API-call]# 

The strange thing is that when run for the second time, it succeeds:

    [root@qe-dell-ovs5-vm-28 dbus-API-call]# ./runtest.sh 
    *** invoking dbus-API listen
    *** sending query 42
    Listening for method calls
    Method called with 42

    PASS: query output shown as expected:
    Calling remote method with 42
    Request Sent
    Got Reply: 1, 21614
    dbus-API-call result: PASS
       Log: result.log
       AVC_ERROR undefined. Using +no_file as default.
        Warning: AVC_ERROR environment variable not defined.  Using epoch as start time
         Searching logs...
         Info: No AVC messages found.
     Writing to /mnt/testarea/tmp.rhts-db-submit-result.9_m843
    :
       AvcLog: /mnt/testarea/tmp.rhts-db-submit-result.9_m843
    [root@qe-dell-ovs5-vm-28 dbus-API-call]# 

I don’t understand why for the first time EOL characters are eliminated.

Version-Release number of selected component (if applicable):
dbus-1.6.12-8.el7.x86_64

How reproducible:
Reproduced as described above many times.

Actual results:
Test fails for the first time, then succeeds.

Expected results:
Test should work with constant (positive) results.

Comment 2 David King 2015-01-09 15:37:29 UTC
I investigated the contents of the test, and it seems to be based on an API example from 2005. This is fine in itself, but the code makes assumptions about message order, which are not guaranteed by the dbus specification (and so are unreliable to subject to testing).

After checking the upstream dbus test suite (which is run inside the check phase in the spec, and as the dbus-unit-tests test), it seems that the upstream test-service test already covers the checks in the downstream dbus-API-call and dbus-API-send tests.

I went a bit further, and checked that the downstream CVE tests (CVE-2011-2200 and bz464674-CVE-2008-3834-dbus-DoS) are also correct and included upstream (and in dbus-1.6.12-8.el7). They can therefore safely be dropped from the downstream tests, if desired. The downstream machine-id test is valid, and should probably be kept exclusively downstream.

Matěj, are you happy for me to NOTABUG on that basis?

Comment 4 Matěj Cepl 2015-01-15 18:22:13 UTC
So, yes for the original description this bug can be closed as NOTABUG, but what to do with those failing upstream tests? Should I just give up (make check || /bin/true)?

Comment 5 David King 2015-01-16 15:03:18 UTC
For any (other) failing tests, a separate bug is best. If it can be reproduced, preferably locally, I should be able to fix it.