[ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH]
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:
[EMAIL PROTECTED]:~/Python-2.4.2$ cat ~/t.py
#! /usr/bin/env python
import sys
print sys.version
import mmap
mmap.mmap(-1, 4096)
[EMAIL PROTECTED]:~/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...)
[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:13:06.0
+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.
[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:23:52.0
+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-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.
---
[ python-Feature Requests-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-14 19:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? -- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH]
Bugs item #1402308, was opened at 2006-01-11 01:38
Message generated for change (Comment added) made by birkenfeld
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:
[EMAIL PROTECTED]:~/Python-2.4.2$ cat ~/t.py
#! /usr/bin/env python
import sys
print sys.version
import mmap
mmap.mmap(-1, 4096)
[EMAIL PROTECTED]:~/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...)
[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:13:06.0
+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.
[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:23:52.0
+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: 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 inter
[ python-Bugs-1396543 ] urlparse is confused by /
Bugs item #1396543, was opened at 2006-01-04 05:57
Message generated for change (Comment added) made by pterk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&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: Open
Resolution: None
Priority: 5
Submitted By: John Hansen (johnhansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse is confused by /
Initial Comment:
If the parameter field of a URL contains a '/', urlparse does not enter date
in the parameter field, but leaves it attached to the path.
The simplified example is:
>>> urlparse.urlparse("http://f/adi;s=a;c=b/";)
('http', 'f', '/adi;s=a;c=b/', '', '', '')
>>> urlparse.urlparse("http://f/adi;s=a;c=b";)
('http', 'f', '/adi', 's=a;c=b', '', '')
The realworld case was:
>>> urlparse.urlparse("http://ad.doubleclick.net/adi/
N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/
adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId%
3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900%
3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D")
(''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/
B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink%
7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime
%3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews%
5Fgeneral%3Blink%3D', '', '', '')
What's odd is that the code specifically says to do this:
def _splitparams(url):
if '/' in url:
i = url.find(';', url.rfind('/'))
if i < 0:
return url, ''
Is there a reason for the rfind?
--
Comment By: Peter van Kampen (pterk)
Date: 2006-01-14 22:19
Message:
Logged In: YES
user_id=174455
Actually section 3.3 of RFC2396 is relevant here and it
seems that it is indeed correctly implemented as is.
I'm not sure what the 'python policy' is on RFC vs The Real
World. My guess would be that RFC's carry some weight.
Following the 'real world' is too vague a reference. Your
world might be different than mine and tomorrow's world a
different world than today's.
You can always monkey-patch:
>>> def my_splitparams(url):
... i = url.find(';')
... return url[:i], url[i+1:]
...
>>> import urlparse
>>> urlparse._splitparams = my_splitparams
>>> urlparse.urlparse("http://f/adi;s=a;c=b/";)
('http', 'f', '/adi', 's=a;c=b/', '', '')
--
Comment By: John Hansen (johnhansen)
Date: 2006-01-13 19:19
Message:
Logged In: YES
user_id=1418831
Well RFC2396, section 3.4 says "/" is reserved within a query. However, the
real
world doesn't seem to follow RFC2396... so I still think it's a bug: the class
should be useful, rather than try to enforce an RFC. A warning would be fine.
--
Comment By: Peter van Kampen (pterk)
Date: 2006-01-13 01:25
Message:
Logged In: YES
user_id=174455
Looking at the testcases it appears the answers must be in
rfc's 1808 or 2396. http://www.ietf.org/rfc/rfc1808.txt and
http://www.ietf.org/rfc/rfc2396.txt See for example section
5.3 of 1808. I don't see why _splitparams does what is does
but I didn't exactly close-read the text either. Also be
sure to look at Lib/test/test_urlparse.py.
--
Comment By: John Hansen (johnhansen)
Date: 2006-01-04 17:31
Message:
Logged In: YES
user_id=1418831
The first line should have read:
If the parameter field of a URL contains a '/', urlparse does not enter it
into the parameter field, but leaves it attached to the path.
--
Comment By: John Hansen (johnhansen)
Date: 2006-01-04 06:00
Message:
Logged In: YES
user_id=1418831
The first line should have read:
If the parameter field of a URL contains a '/', urlparse does not enter it
into the parameter field, but leaves it attached to the path.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1371247 ] locale.windows_locale
Bugs item #1371247, was opened at 2005-12-01 22:50 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&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: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP -- Comment By: Peter van Kampen (pterk) Date: 2006-01-14 23:40 Message: Logged In: YES user_id=174455 See patch 1406159: http://sourceforge.net/tracker/index.php?func=detail&aid=1406159&group_id=5470&atid=305470 -- Comment By: Greg Hazel (ghazel) Date: 2005-12-01 23:30 Message: Logged In: YES user_id=731668 I believe there's a small typo in that page. Spanish 1034 says hex 0x0C0A when hex(1034) is 0x040A The rest seems correct (hex and int values match). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
