| 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) *  |
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) * |
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) * |
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) * |
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) * |
Date: 2008-01-05 18:27 |
| Check this for 2.6 or close it. |
|
|
| msg82073 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
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 . |
|
|