[ python-Bugs-1018492 ] Solaris: reentrancy issues

[SourceForge.net]

Bugs item #1018492, was opened at 2004-08-29 12:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Harrison (ssmmhh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris: reentrancy issues

Initial Comment:
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.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2004-09-05 18:23

Message:
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.

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

Comment By: Simon Harrison (ssmmhh)
Date: 2004-09-05 14:15

Message:
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.  

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

Comment By: Martin v. Löwis (loewis)
Date: 2004-09-04 22:55

Message:
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.

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

Comment By: Martin v. Löwis (loewis)
Date: 2004-09-04 18:47

Message:
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.

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

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