This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Solaris: reentrancy issues
Type: behavior Stage: test needed
Components: None Versions: Python 2.6
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 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit ssmmhh, 2004-08-29 10:18
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 

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
msg22264 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-04 20:55
Logged In: YES 

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 

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 

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
- 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 

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 

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 

One approach of using readdir_r is presented at

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
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.
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40841
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