This is happening on OSX, Python 2.4.2:

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

import mmap

mmap.mmap(-1, 4096)
ralf@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@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@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;

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.

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.

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.

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.

Logged In: YES 
user_id=17929

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