[Patches] [ python-Patches-633013 ] Fix NIS causing interpreter core dump

[noreply@sourceforge.net]

Patches item #633013, was opened at 2002-11-03 22:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633013&group_id=5470

Category: Core (C code)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix NIS causing interpreter core dump

Initial Comment:
When running on the Compaq test drive machines,
test_nis will cause the interpreter to core dump.  The
attached patch prevents the core dump which is caused
by passing a negative value to
PyString_FromStringAndSize().  I'm not sure if it's
100% correct, but the test passes and the interpreter
doesn't core dump.

Any one else know if this is correct?  I'll apply to
prevent the core dump, unless someone complains.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-11-04 00:11

Message:
Logged In: YES 
user_id=21627

A quick test shows that indeed the if(fix) block causes the
trouble; it crashes with mail.aliases, because both strings
are empty.

I'm not entirely sure what the fix mechanism is supposed to
achieve; it does appear that it indeed avoids copying an
extra null byte on Solaris. The comment about "makedbm -a"
sounds mystical: makedbm has no documented -a option. We
should probably ask Fred Gansevles, who added this in 2.15.
There is also a GvR comment who says it doesn't work for NIS+.

Unless a better strategy shows up, I suggest to skip entries
which have both empty keys and values.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-03 23:32

Message:
Logged In: YES 
user_id=21627

The patch looks wrong. What is the value of inkeylen and
invallen at the point of the crash? Might it be -1, due to
the prior decrement?

Was that for a 32-bit or a 64-bit binary? Could it be that
Python is using an incorrect signature of the foreach
function (despite the man page saying that this is the
correct signature)?

Could it be that the data are really large unsigned numbers?
If so, what are the corresponding data? The foreach function
is supposedly called once per record, so both sizes ought to
be small.

I am concerned about thread-safety of this entire module,
though. yp_all is invoked with the GIL released, yet the
callback function calls interpreter API. This asks for a
desaster if other threads simultanously access the interpreter.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=633013&group_id=5470