[ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH]

SourceForge.net noreply at sourceforge.net
Mon Jan 16 09:46:13 CET 2006


Bugs item #1402308, was opened at 2006-01-11 01:38
Message generated for change (Comment added) made by titty
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralf Schmitt (titty)
Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault when using mmap(-1,...) [+PATCH]

Initial Comment:
This is happening on OSX, Python 2.4.2:

ralf at mini:~/Python-2.4.2$ cat ~/t.py
#! /usr/bin/env python
import sys
print sys.version

import mmap

mmap.mmap(-1, 4096)
ralf at mini:~/Python-2.4.2$ ./python ~/t.py
2.4.2 (#1, Jan 11 2006, 00:58:35) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)]
Segmentation fault


The following one line diff solves that problem (mmap's data member 
is otherwise uninitialized...)

ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig 
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig   
2006-01-11 01:12:32.000000000 +0100
+++ Modules/mmapmodule.c        2006-01-11 01:13:06.000000000 
+0100
@@ -910,6 +910,7 @@
 #endif
        m_obj = PyObject_New (mmap_object, &mmap_object_type);
        if (m_obj == NULL) {return NULL;}
+       m_obj->data = NULL;
        m_obj->size = (size_t) map_size;
        m_obj->pos = (size_t) 0;
        m_obj->fd = dup(fd);




However, the problem is that passing -1 as filedescriptor to mmap
is perfectly ok when one wants to mmap anonymous memory (at least 
on FreeeBSD and OS X). The following patch also solves that problem.
[mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...]
Any chance to get this included? Passing -1 to mmap should not hurt 
anybody, as systems which do not support it, should then return an 
error from mmap. 

ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig 
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig   
2006-01-11 01:12:32.000000000 +0100
+++ Modules/mmapmodule.c        2006-01-11 01:23:52.000000000 
+0100
@@ -910,10 +910,12 @@
 #endif
        m_obj = PyObject_New (mmap_object, &mmap_object_type);
        if (m_obj == NULL) {return NULL;}
+       m_obj->data = NULL;
        m_obj->size = (size_t) map_size;
        m_obj->pos = (size_t) 0;
-       m_obj->fd = dup(fd);
-       if (m_obj->fd == -1) {
+       if (fd == -1) {
+               m_obj->fd = -1;
+       } else if ((m_obj->fd = dup(fd)) == -1) {
                Py_DECREF(m_obj);
                PyErr_SetFromErrno(mmap_module_error);
                return NULL;


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

>Comment By: Ralf Schmitt (titty)
Date: 2006-01-16 09:46

Message:
Logged In: YES 
user_id=17929

patch submitted: https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=1402308&group_id=5470

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

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-14 22:12

Message:
Logged In: YES 
user_id=1188172

Note that MAP_ANON isn't mentioned in the docs, so it's not
official.

Otherwise, I agree with Ralf. -1 should be excluded from
dup()ing and this should be documented.

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

Comment By: Ralf Schmitt (titty)
Date: 2006-01-14 13:45

Message:
Logged In: YES 
user_id=17929

1.The mmap module exports MAP_ANON/MAP_ANONYMOUS on unix like 
systems, so someone who has been using mmap in C most probably would 
expect that passing -1 as fileno is possible in order to do anonymous 
mmap's.
(Those who have been using prior versions of python and anonymous mmap 
would also expect the same).

2. The workaround (if -1 is artificially forbidden as fileno) is to open /dev/
zero and using that as a fileno to mmap (this doesn't work on OS X). However, 
since filedescriptors passed to mmap are now dup'ed (starting from version 
2.4.2) this leads to excessive abuse of filedescriptors up to the point that one 
might not be able to use anonymous mmap's because of filedescriptor 
limitations.
 
3. On Windows one can currently pass 0 as fileno in order to allocate 
anonymous memory (which seems wrong, even on windows 0 might be a 
valid filedescriptor? -1 would be a better value here). This is handled as a 
special case in the windows code. So, in Python 2.4.2 it's now harder, maybe 
even impossible, to use anonymous mmap's on unix, whereas in windows it's 
a no brainer. And this module got it's name from a unix system call :).

4. I don't consider this a feature request. 2.4.2 broke existing code.

Guess, I'll have to send a patch.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-14 08:40

Message:
Logged In: YES 
user_id=33168

Thanks.  I only fixed the bug as the second part is a
feature request.

Committed revision 42012.
Committed revision 42041. (2.4)

I'm not opposed to adding the feature, but would like to
keep the unix and windows versions as similar as possible. 
I don't know what windows does in this case.  I'm going to
close this bug report.

If you are interested in making a patch that handles
windows, unix, and the doc feel free to submit a patch for
it.  Also, when you submit a patch please attach a file
since SF screws up the formatting.  For the one-liner it's
not a big deal to inline, but it could be a problem for
python code still.

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

Comment By: Ralf Schmitt (titty)
Date: 2006-01-11 09:43

Message:
Logged In: YES 
user_id=17929

this is a regression from 2.4.1. On 2.4.1 mmap(-1, 4096,
mmap.MAP_ANON) works without problems.


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

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


More information about the Python-bugs-list mailing list