classification
Title: Solaris: reentrancy issues
Type: behavior Stage: test needed
Components: None Versions: Python 2.6
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, ajaksu2, christian.heimes, loewis, ssmmhh
Priority: normal Keywords:

Created on 2004-08-29 10:18 by ssmmhh, last changed 2010-08-19 16:10 by BreamoreBoy. This issue is now closed.

Files
File name Uploaded Description Edit
reentrant_check.py ssmmhh, 2004-08-29 10:18 reentrant_check.py
reentrantfix_2.4a2.patch ssmmhh, 2004-09-05 11:40 Partial patch
Messages (11)
msg22262 - (view) Author: Simon Harrison (ssmmhh) Date: 2004-08-29 10:18
Version: 2.3.4
Platform: Solaris (possibly other non-Linux).

In some cases reentrant API functions (ctime_r etc) are
used, but many cases not.  It's unlikely that this
would cause problems on single-processor machines. Run
the attached script giving Python source tree location
as argument.  A file report.html will be generated
detailing where there could be problems.

NB:  The script isn't foolproof and will come up with
matches to text inside comments as well.
msg22263 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-04 16:47
Logged In: YES 
user_id=21627

I fail to see the bug. I believe Python uses the reentrant
functions at precisely the places where it is necessary, and
is right in using the non-reentrant functions in all other
places. To my knowledge, the way that Python uses the
non-reentrant functions cannot possibly cause problems even
on multiprocessor machines.

So I'm closing this report as invalid. If you can find an
actual problem using your script, please submit a new bug
report.
msg22264 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-04 20:55
Logged In: YES 
user_id=21627

In private email, Simon pointed out that there is a problem
if Python is embedded and the embedded application
simultaneously also invokes non-reentrant functions. I'm
still uncertain whether that problem would be a bug in
Python, and if it is, whether it is worthwhile getting fixed.

OTOH, contributions would be certainly accepted.
msg22265 - (view) Author: Simon Harrison (ssmmhh) Date: 2004-09-05 12:15
Logged In: YES 
user_id=775521

Don't apply the patch - it's not tested, but just serves as
an example, and it's certainly not complete.

For some _r functions it's quite obvious how they should be
used.  For ones with variable-length buffers accompanying
the struct to be filled in it's not clear how they should be
sized. It's also not clear whether the ERANGE return should
be used to 'automatically' realloc a larger buffer, or
whether the ERANGE error should simply be passed back to
Python as a general failure.  For some buffers (asctime_r)
the maximum size can be guessed based on common sense, for
others, defines exist in system headers which may not be
portable, requiring possible further configure checks.

I think the way I would fix this is to introduce a wrapper
for each reentrant function that returns a malloc'ed buffer
that must be freed by the caller when done with the
structure.  The wrapper would continually allocate larger
buffers until the size was correct.

Alteratively, one might argue I'm being overly paranoid, and
that for each function we should be able to guess a sensible
buffer length, then just fail if the api call returns too
much data.  
msg22266 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-05 16:23
Logged In: YES 
user_id=21627

The patch looks good. It doesn't need to be complete, but it
should be correct for the APIs which it does change. A few
comments:
- there is probably little point in changing getaddrinfo.c.
This is an emulation that is only used on systems which
don't have a "proper" getaddrinfo, and most likely, all
systems offering gethostbyname_r also offer getaddrinfo.
- the usage of readdir_r is incorrect - you need to provide
for sufficient space.
- I don't think it is good to allocate 8k on the stack.
Instead, you should indeed start with a small buffer, then
grow it as needed, using malloc.
msg22267 - (view) Author: Simon Harrison (ssmmhh) Date: 2004-09-05 20:07
Logged In: YES 
user_id=775521

Point taken about readdir_r and getaddrinfo.  I'll submit
something more robust (and tested) probably next week.
msg22268 - (view) Author: Simon Harrison (ssmmhh) Date: 2004-09-07 22:28
Logged In: YES 
user_id=775521

I'm still looking at this, but running into difficulties.  

- Having looked again at readdir_r manual page I can't work
out the buffer sizing.  If anyone can point me at some
example code I'd appreciate it.
- I can't compile 2.4a3 on Solaris - got an error during
configure about term.h present but can't be compiled, and
therefore can't check my latest patch works.  System:
Solaris 8 2/02, gcc 3.3.3.  I'm not in a position to change
any of these versions, unfortunately.
msg22269 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-08 04:45
Logged In: YES 
user_id=21627

One approach of using readdir_r is presented at

http://www.belgeler.org/glibc/glibc-Reading-Closing-Directory.html

As for not being able to compile 2.4a3, please add a new bug
report, and show the relevant fragment of config.log in that
report.
msg59301 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-05 18:27
Check this for 2.6 or close it.
msg82073 - (view) Author: Daniel Diniz (ajaksu2) (Python triager) Date: 2009-02-14 14:43
Is this still a concern?
msg114374 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-19 16:10
No reply to msg82073.
History
Date User Action Args
2010-08-19 16:10:19BreamoreBoysetstatus: open -> closed

nosy: + BreamoreBoy
messages: + msg114374

resolution: out of date
2009-02-14 14:43:30ajaksu2setnosy: + ajaksu2
type: behavior
messages: + msg82073
stage: test needed
2008-01-05 18:27:20christian.heimessetnosy: + christian.heimes
messages: + msg59301
versions: + Python 2.6
2004-08-29 10:18:24ssmmhhcreate