Issue 1087741: subclassable mmap - Python tracker (original) (raw)
Created on 2004-12-19 00:16 by josiahcarlson, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (9)
Author: Josiah Carlson (josiahcarlson) * 
Date: 2004-12-19 00:16
As the subject says, it would be nice if mmaps were subclassable...like nearly every other Python object type.
Note that pseudo-subclasses (copying the instance methods to a different class (not necessarily of the same type) instance) don't work completely due to python.org/sf/1087735 , and is probably a Python "anti-pattern".
Author: Neal Norwitz (nnorwitz) * 
Date: 2007-03-16 06:17
Josiah, care to work up a patch?
Author: Josiah Carlson (josiahcarlson) *
Date: 2007-03-16 06:27
I honestly wouldn't know where to start. I don't know what the differences are between the currently un-subclassable mmap, and something like int/list/dict.
Author: Ralf Schmitt (schmir)
Date: 2008-01-21 09:30
I'm attaching a patch, which makes mmap.mmap the mmap class itself and also makes it subclassable. It also contains changes to the documentation. This is against revision 60148 of trunk.
Author: Georg Brandl (georg.brandl) *
Date: 2008-01-21 14:16
Reviewed and committed in r60152.
Author: Ralf Schmitt (schmir)
Date: 2008-01-21 14:22
Many thanks for handling it immediately.
Author: Ralf Schmitt (schmir)
Date: 2008-01-22 13:25
sorry, I somehow managed to introduce a segfault:
~/pydev/trunk/ cat t.py
ralf@red ok
from mmap import mmap
class anon_mmap(mmap): def new(klass, *args, **kwargs): res = mmap.new(klass, -1, *args, **kwargs) print "NEW:", res return res
anon_mmap(4096)
~/pydev/trunk/ ./python t.py
ralf@red ok
NEW: <__main__.anon_mmap object at 0x866b10>
Debug memory block at address p=0x866b10:
18374686479671623679 bytes originally requested
The 8 pad bytes at p-8 are not all FORBIDDENBYTE (0xfb):
at p-8: 0xcb *** OUCH
at p-7: 0xcb *** OUCH
at p-6: 0xcb *** OUCH
at p-5: 0xcb *** OUCH
at p-4: 0xcb *** OUCH
at p-3: 0xcb *** OUCH
at p-2: 0xcb *** OUCH
at p-1: 0xcb *** OUCH
Because memory is corrupted at the start, the count of bytes requested
may be bogus, and checking the trailing pad bytes may segfault.
The 8 pad bytes at tail=0xff00000000866b0f are zsh: segmentation
fault ./python t.py
The following fixes it for me:
~/pydev/trunk/ cat patch
ralf@red failed 139
diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c
--- a/Modules/mmapmodule.c
+++ b/Modules/mmapmodule.c
@@ -129,7 +129,7 @@ mmap_object_dealloc(mmap_object m_obj)
}
#endif / UNIX */
PyObject_Del(m_obj);
m_obj->ob_type->tp_free((PyObject*)m_obj);
}
static PyObject *
I'll write a test for this issue and will attach a complete patch. Sorry again.
Author: Ralf Schmitt (schmir)
Date: 2008-01-22 13:35
./python Lib/test/test_mmap.py works with a debug build with this patch.
Author: Georg Brandl (georg.brandl) *
Date: 2008-01-22 19:56
Committed as r60202. Thanks for the care!
History
Date
User
Action
Args
2022-04-11 14:56:08
admin
set
github: 41341
2008-01-22 19:56:27
georg.brandl
set
messages: +
2008-01-22 13:35:35
schmir
set
messages: +
2008-01-22 13:34:12
schmir
set
files: + subclass_mmap_patch.txt
2008-01-22 13:25:28
schmir
set
messages: +
2008-01-21 14:22:27
schmir
set
messages: +
2008-01-21 14:16:56
georg.brandl
set
status: open -> closed
nosy: + georg.brandl
resolution: accepted
messages: +
2008-01-21 09:30:53
schmir
set
files: + mmapclass.txt
nosy: + schmir
messages: +
2004-12-19 00:16:54
josiahcarlson
create