Bug 1261596 - xdrstdio_create buffers do not output encoded values on ppc
xdrstdio_create buffers do not output encoded values on ppc
Status: NEW
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libtirpc (Show other bugs)
6.5
ppc64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Steve Dickson
Filesystem QE
:
Depends On:
Blocks: 1261738
  Show dependency treegraph
 
Reported: 2015-09-09 14:21 EDT by Michael Meseke
Modified: 2017-03-23 15:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1261738 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducer (9.51 KB, application/x-gzip)
2015-09-09 14:21 EDT, Michael Meseke
no flags Details

  None (edit)
Description Michael Meseke 2015-09-09 14:21:31 EDT
Created attachment 1071892 [details]
Reproducer

Description of problem:
Using xdrstdio_create to encode buffers does not work on PPC

Version-Release number of selected component (if applicable):
tirpc 0.2.1-10

How reproducible:
Every time.

Steps to Reproduce:
1. Compile the common example programs described in with tirpc: 

https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.progcomc/xdr_justif_ex.htm 

Actual results:

$ ./writer-tirpc | ./reader-tirpc
942013120 942013120 942013120 942013120 942013120 942013120 942013120 942013120 

with a version compiled without tirpc it works okay:

$ ./writer | ./reader
0 1 2 3 4 5 6 7 

The non-tirpc writer output looks like:
$ ./writer | hexdump
0000000 0000 0000 0000 0001 0000 0002 0000 0003
0000010 0000 0004 0000 0005 0000 0006 0000 0007
0000020

The tirpc writer output looks like:
$ ./writer\-tirpc  | hexdump
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000020

on x86, the tirpc writer output looks like:
$ ./writer-tirpc | hexdump
0000000 0000 0000 0000 0100 0000 0200 0000 0300
0000010 0000 0400 0000 0500 0000 0600 0000 0700
0000020

Expected results:

$ ./writer-tirpc | ./reader-tirpc
0 1 2 3 4 5 6 7 

Additional info:

Initially found while testing with with 0.2.1-5.  Upgraded to 0.2.1-10 to no avail.
Comment 2 xzhou 2015-09-10 01:37:04 EDT
		ppc64	s390	x86_64	i386
RHEL-7.2Snap1   fail    fail    pass     x
RHEL-6.7	fail	fail	pass	pass

cloning to rhel7.
Comment 4 Steve Dickson 2015-10-26 10:35:51 EDT
The only difference in the code is:

glibc:

bool_t
xdr_long (XDR *xdrs, long *lp)
{

  if (xdrs->x_op == XDR_ENCODE
      && (sizeof (int32_t) == sizeof (long)
      || (int32_t) *lp == *lp))
    return XDR_PUTLONG (xdrs, lp);

  if (xdrs->x_op == XDR_DECODE)
    return XDR_GETLONG (xdrs, lp);

  if (xdrs->x_op == XDR_FREE)
    return TRUE;

  return FALSE;
}

libtirpc:

bool_t
xdr_long(xdrs, lp)
    XDR *xdrs;
    long *lp;
{   
    switch (xdrs->x_op) {
    case XDR_ENCODE:
        return (XDR_PUTLONG(xdrs, lp));
    case XDR_DECODE:
        return (XDR_GETLONG(xdrs, lp));
    case XDR_FREE:
        return (TRUE);
    }
    /* NOTREACHED */
    return (FALSE);
}


So this extra checking was added on write side

  if (xdrs->x_op == XDR_ENCODE
      && (sizeof (int32_t) == sizeof (long)
      || (int32_t) *lp == *lp))
    return XDR_PUTLONG (xdrs, lp);

Its not clear what that check is for and how it is different
for PPC...

Note You need to log in before you can comment on or make changes to this bug.