Platform: TRU64 v5.1a

Ran configure with --with-dec-threads options. 
Also used --without-gcc although this has no impact on
test failure.

The ouput from ./python ./Lib/test/test_nis.py is large
so I've included it in an attached file rather than
pasted here.

The machine that Python is being built on is a NIS
server as well as client.

Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

Logged In: YES 
user_id=594846

Uploading the output file from ./python ./Lib/test/test_nis.py.

Logged In: YES 
user_id=21627

This sounds like some serious memory corruption is going on.
Unfortunately, I can't spot a problem, so somebody with
access to such a system would need to debug it.

My first guess is that the type of the callback function is
incorrect. Can you please find out what signatures are
involved in yp_all(3)? On Solaris, the callback signature is
not declared in a header, but only documented in
yp_clnt(3NSL), as

                foreach(int instatus, char *inkey,
                int inkeylen, char *inval,
                int invallen, char *indata);

Logged In: YES 
user_id=594846

On TRU64 this is doucmented as


       foreach(instatus, inkey, inkeylen, inval, invallen,
indata);
       int instatus;
       char *inkey;
       int inkeylen;
       char *inval;
       int invallen;
       char *indata;

Logged In: YES 
user_id=33168

I fixed a similar problem on Nov 4.  Can you test the latest
CVS versions from the head or for 2.2.2+?

Logged In: YES 
user_id=33168

Patrick, are you able to test if this has been fixed?

Logged In: YES 
user_id=33168

I believe this has been fixed.  If not, please open a new
bug report.