/usr/lib/yp/ypxfr produces segmentation fault

Got:
Transferring passwd.byuid...
Transferring ypservers...
Transferring passwd.byname...
Transferring shadow.byname...
/usr/lib/yp/ypinit: line 37: 27831 Segmentation fault $YPBINDIR/ypxfr -f -h $MASTER -c -d $DOMAIN $map
YPINIT: WARNING: Couldn't exec /usr/lib/yp/ypxfr -f -h <server> -c -d <domain> shadow.byname
Transferring group.byname...
Transferring group.bygid...
....

I've reproduced this on dapper. ypxfr crashes on amd64 if there is a YP_SECURE key in the map (so mostly only for shadow maps).

Backtrace:

#0 0x00002aaaaae47c05 in free () from /lib/libc.so.6
#1 0x00002aaaaaecb9a8 in xdr_bytes_internal () from /lib/libc.so.6
#2 0x00000000004033b8 in xdr_valdat (xdrs=0x6400000001, objp=0x0)
    at ypxfr_xdr.c:53
#3 0x000000000040340c in xdr_ypresp_val (xdrs=0x7fffff938c10,
    objp=0x7fffff93ae80) at ypxfr_xdr.c:64
#4 0x00002aaaaaecb2b5 in xdr_free () from /lib/libc.so.6
#5 0x0000000000402a79 in ypxfr (map=0x7fffff93c99f "shadow.byname",
    source_host=<value optimized out>,
    source_domain=0x7fffff93c991 "sirena.org.uk",
    target_domain=0x7fffff93c991 "sirena.org.uk", noclear=1, force=1)
    at ypxfr.c:681
#6 0x0000000000403062 in main (argc=<value optimized out>,
    argv=0x7fffff93b160) at ypxfr.c:868

This is unlikely to be Ubuntu-specific.

Actually, this may well be Ubuntu-specific: it looks like a compiler bug. xdr_ypresp_val() should be passing the xdrs it was given into xdr_valdat() but as can be seen from the backtrace it isn't. It looks rather like the first argument has been dropped and the remaining arguments are being passed one ahead of where they should be.

Rebuilding with NOOPT avoids the segfault; I guess a bug should be filed against GCC but it's probably worth checking to see that this isn't fixed already before doing so,

This patch works around the problem in a non-invasive fashion - I wasn't able to come up with a code based workaround. None of the unoptimised code should be particularly performance critical.

I'm not sufficiently familiar with how this stuff is handled to know what to do with this now.

Seems like a sensible state given that Ubuntu doesn't use bzr for this.

No SRU request here, unsub'ing ubuntu-sru.

I've reproduced the problem on dapper.

I uploaded your patch to dapper-proposed, please test.

Also, is this still an issue in Gutsy and hardy? We need to fix it in Hardy first before this can go to any -updates.

It's only an issue in dapper - it was a bug in the compiler which was resolved before feisty.

Will try to test this weekend.

Thanks for the confirmation. Closing the hardy task.

Unfortunately I can't provide testing for dapper at present - none of the AMD64 systems I have appear able to boot it these days. :(

I've spent a fair amount of time attempting to reproduce this bug on an am64 dapper instance, unfortunately with no success. I am able to ypxfr maps with the YP_SECURE key set on it from a hardy nis server to both the originally shipped version of nis (3.15-3ubuntu2) and the version in dapper-proposed (3.15-3ubuntu3).

However, my knowledge of the details of nis configuration are limited, so it would be helpful if either a simplified testcase that reproduces the issue could be developed or if the original reporter or another person with the same issue could confirm that the package in dapper-proposed does indeed fix the issue. Thanks!

What architecture is the NIS server? The NIS server must be a Linux server running on an incompatible architecture (eg, i386).

The problem is that NIS attempts to transfer the map by copying the architecture dependant database file verbatim rather than transferring the keys individually. It may be important that the server is running an older version of the NIS server - I'm not aware of any workaround there, though.

YP_SECURE should be irrelevant, I was doing all my testing with the passwd.byname map IIRC.

Ah, thanks, that's the problem, I was testing from a hardy amd64 NIS master server. I'll try to reproduce again from an i386 master. Thanks!

Steve, thank you for testing! BTW, since this is so old already, I'm
actually more concerned about a test which shows that the package
still by and large works. If the bug is not reproducible, we shouldn't
waste too much time trying to reproduce it.

If the bug is not fully fixed, we can always do another upload.
Regressions or total breakage are far worse, and that's what we should
focus testing on. Thanks!

I was able to successfully reproduce the issue using the dapper amd64 version of nis 3.15-3ubuntu2 in a slave configuration against an i386 hardy NIS master server. After upgrading the version of nis on the dapper slave to the version in dapper-proposed, 3.15-3ubuntu3, I can confirm that that the ypxfr segfault no longer happens.

I also nominally looked for regressions from installing the -proposed package; I was able to succesfully set up the package in both a slave and master configuration and ypcat, ypmatch, and yptest all returned sensible results in both master and slave configurations.

Copied to dapper-updates, thank you!