Bug 615313

upstream

 https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=522,0

Ticket #522: condor_chirp fails when querying the value of a non-existing attribute

    When querying the value of a non-existing attribute the condor_chirp get_job_attr command aborts, returning "abnormal program termination" on Windows and a core from SIGABRT on non-Windows.

[Append remarks]
Remarks:

    2010-Jul-15 00:05:24 by matt:
    Here's the skinny...

    On the shadow side,

    A get_job_attr for an attribute that does not exist hits pseudo_ops.cpp:pseudo_get_job_attr(name, expr) and returns -1: e = ad->Lookup(name); if(e) { ... } else { ...; return -1; }"

    The -1 gets returned to the "case CONDOR_get_job_attr" in NTreceivers.cpp, which happily handles it by encoding a response of "code(-1); code(0);" -- the -1 is the return value and 0 is the default errno.

    On the starter side,

    The receiver in io_proxy_handler.cpp eventually calls IOProxyHandler::convert to translate the errno (remember it was 0) into a CHIRP_ERROR code to send to condor_chirp. However, errno is not a known code, resulting in CHIRP_ERROR_UNKNOWN and a dprintf of "Starter ioproxy server got unknown unix errno:0"

    On the condor_chirp side,

    Result of CHIRP_ERROR_UNKNOWN is received, which triggers an unceremonious fprintf to stderr of "chirp: couldn't get response from server: Success" followed swiftly by abort(). The "Success" is from strerror(errno) and is meaningless.

    This behavior is definitely broken.

    2010-Jul-15 00:28:05 by matt:
    Options for resolving this broken behavior -

    condor_chirp/PROTOCOL equates get_job_attr with getenv, which returns NULL if the env name isn't present

        * Stop aborting, return non-zero - however, abort() is a actually triggered by a problem in the protocol
        * Make unix_errno=0 known to IOProxyHandler::convert - however, requires picking an error code for 0, maybe CHIRP_ERROR_DOESNT_EXIST, changing all chirp client implementations to handle the new code, results in breaking wire protocol between new starter and old chirp clients
        * Change pseudo_get_job_attr to set errno, maybe to ENOENT - better than converting errno=0 to CHIRP_ERROR_DOESNT_EXIST in IOProxyHandler::convert, but has all the same drawbacks
        * Change pseudo_get_job_attr to return UNDEFINED - requires no protocol changes and no client changes, aligns well with ClassAd semantics and getenv("DOESNT_EXIST") -> NULL (Lookup("DOESNT_EXIST") -> UNDEFINED) 

    2010-Jul-15 00:29:29 by matt:

    diff --git a/src/condor_shadow.V6.1/pseudo_ops.cpp b/src/condor_shadow.V6.1/pseudo_ops.cpp
    index c71e1c2..c80230f 100644
    --- a/src/condor_shadow.V6.1/pseudo_ops.cpp
    +++ b/src/condor_shadow.V6.1/pseudo_ops.cpp
    @@ -705,8 +705,9 @@ pseudo_get_job_attr( const char *name, MyString &expr )
                    dprintf(D_SYSCALLS,"pseudo_get_job_attr(%s) = %s\n",name,expr.Value());
                    return 0;
            } else {
    -               dprintf(D_SYSCALLS,"pseudo_get_job_attr(%s) failed\n",name);
    -               return -1;
    +               dprintf(D_SYSCALLS,"pseudo_get_job_attr(%s) is UNDEFINED\n",name);
    +               expr = "UNDEFINED";
    +               return 0;
            }
     }

Resolved upstream, will be built post 7.4.4-0.4

Tested with (version):
condor-7.4.4-0.8

Tested on:
RHEL5 x86_64  - passed
RHEL5 i386    - passed
RHEL4 x86_64  - passed
RHEL4 i386    - passed

>>> VERIFIED

    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:
Previously, when querying the value of a non-existing attribute the "condor_chirp get_job_attr" command aborted, returning "abnormal program termination" on a Windows system and a core from SIGABRT on a non-Windows system. With this update, these errors no longer occur and 'condor_chirp' works as expected.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0773.html