[ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH]
Bugs item #1402308, was opened at 2006-01-11 00: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: Open
Resolution: None
Priority: 5
Submitted By: Ralf Schmitt (titty)
Assigned to: Nobody/Anonymous (nobody)
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-11 08: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
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail
Bugs item #1394135, was opened at 2005-12-31 15:24 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&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: Dan Bisalputra (danbiz) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting first item causes anydbm.first() to fail Initial Comment: If the first item in a database is deleted, the first call to anydbm.first() after the deletion causes a DBNotFoundError exception to be raised. The attached program causes the error on my system. I am currently working around the problem by calling first() after each deletion, enclosed by a try block. I am using Python 2.4.2 running under Windows ME. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-01-11 23:19 Message: Logged In: YES user_id=29957 Which backend is this using? anydbm is just a very very simple wrapper around a bunch of different backends - I have difficulty believing that they _all_ have the same problem. :) -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-11 09:50 Message: Logged In: YES user_id=1188172 Confirmed here (Linux, various Pythons). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403068 ] cannot import extension module with Purify
Bugs item #1403068, was opened at 2006-01-11 17:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: cannot import extension module with Purify Initial Comment: When run with Purify, Python cannot load any extension module. Here is a typical output: Starting Purify'd application... Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "", line 1, in ? File "c:\python\lib\socket.py", line 45, in ? import _socket ImportError: Module use of python24__d$Purify_c_python.dll conflicts with this version of Python. It reproduces with python 2.4.2 and 2.5a0. It works with python 2.3.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403068 ] cannot import extension module with Purify
Bugs item #1403068, was opened at 2006-01-11 17:02
Message generated for change (Comment added) made by amauryf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot import extension module with Purify
Initial Comment:
When run with Purify, Python cannot load any extension
module.
Here is a typical output:
Starting Purify'd application...
Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import socket
Traceback (most recent call last):
File "", line 1, in ?
File "c:\python\lib\socket.py", line 45, in ?
import _socket
ImportError: Module use of
python24__d$Purify_c_python.dll conflicts with this
version of Python.
It reproduces with python 2.4.2 and 2.5a0.
It works with python 2.3.3.
--
>Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2006-01-11 17:22
Message:
Logged In: YES
user_id=389140
The pb seems to be in dynload_win.c, line 136:
while (*pch && pch[0] != '_' && pch[1] != 'd' && pch[2] !=
'.') {
This means that if a .pyd has "python_something.dll" in its
import table, it will be taken as THE python DLL.
I think the line should be:
while (*pch && (pch[0] != '_' || pch[1] != 'd' || pch[2] !=
'.')) {
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403068 ] cannot import extension module with Purify
Bugs item #1403068, was opened at 2006-01-11 17:02
Message generated for change (Comment added) made by amauryf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot import extension module with Purify
Initial Comment:
When run with Purify, Python cannot load any extension
module.
Here is a typical output:
Starting Purify'd application...
Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import socket
Traceback (most recent call last):
File "", line 1, in ?
File "c:\python\lib\socket.py", line 45, in ?
import _socket
ImportError: Module use of
python24__d$Purify_c_python.dll conflicts with this
version of Python.
It reproduces with python 2.4.2 and 2.5a0.
It works with python 2.3.3.
--
>Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2006-01-11 17:35
Message:
Logged In: YES
user_id=389140
The root cause it that Purify renames all DLLs with names like
"python24__d$Purify_c_python.dll".
With python 2.3, this name was not taken as the python DLL,
and no check was performed.
The broken logic in my previous comment changed this for 2.4.
A more correct fix is to get the python DLL name from the
current process, using GetModuleName(PyWin_DLLhModule).
--
Comment By: Amaury Forgeot d'Arc (amauryf)
Date: 2006-01-11 17:22
Message:
Logged In: YES
user_id=389140
The pb seems to be in dynload_win.c, line 136:
while (*pch && pch[0] != '_' && pch[1] != 'd' && pch[2] !=
'.') {
This means that if a .pyd has "python_something.dll" in its
import table, it will be taken as THE python DLL.
I think the line should be:
while (*pch && (pch[0] != '_' || pch[1] != 'd' || pch[2] !=
'.')) {
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail
Bugs item #1394135, was opened at 2005-12-30 20:24 Message generated for change (Comment added) made by danbiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&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: Dan Bisalputra (danbiz) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting first item causes anydbm.first() to fail Initial Comment: If the first item in a database is deleted, the first call to anydbm.first() after the deletion causes a DBNotFoundError exception to be raised. The attached program causes the error on my system. I am currently working around the problem by calling first() after each deletion, enclosed by a try block. I am using Python 2.4.2 running under Windows ME. -- >Comment By: Dan Bisalputra (danbiz) Date: 2006-01-11 09:51 Message: Logged In: YES user_id=534494 whichdb() tells me it is using dbhash. By the way, my workaround using the try/except block ended up deferring the problem until later. I eventually ended up closing and reopening the database after each deletion. Not a problem for the simple application I was building; the database worked great otherwise. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-01-11 04:19 Message: Logged In: YES user_id=29957 Which backend is this using? anydbm is just a very very simple wrapper around a bunch of different backends - I have difficulty believing that they _all_ have the same problem. :) -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 14:50 Message: Logged In: YES user_id=1188172 Confirmed here (Linux, various Pythons). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403221 ] 2.3.5 source RPM install fails w/o tk-devel
Bugs item #1403221, was opened at 2006-01-11 13:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&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: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 source RPM install fails w/o tk-devel Initial Comment: Install fails because _tkinter.so is not found. This library is not built if the tk header files are not found, but the installer treats this as a fatal error. This dependece upon tk-devel is not noted in the .spec file, so the install fails late (and unclearly) instead of early & clearly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403225 ] 2.3.5 RPM provides incompatibility
Bugs item #1403225, was opened at 2006-01-11 13:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&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: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 RPM provides incompatibility Initial Comment: The 2.3.5 rpm provides list is substantially out of sync with the 2.3.4-14 provides list for CEntOS, making it impossible (for me) to use this rpm to upgrade my installation. Help? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename
Bugs item #1403349, was opened at 2006-01-11 16:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&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: Michal P. (mpasniew)
Assigned to: Nobody/Anonymous (nobody)
Summary: in email can't get attachments' filenames using get_filename
Initial Comment:
in the email package (2.4.1) the get_filename() method
returns the MIME field "filename" but some messages
have 'name' field instead, for example:
USUALLY THE HEADER IS:
Content-Type: application/octet-stream;
name="XX.pdf"
Content-Transfer-Encoding: base64
Content-Description: XX.pdf
Content-Disposition: attachment;
filename="XX.pdf"
BUT SOMETIMES THE HEADER IS:
Content-type: application/octet-stream; name="XX.xls"
Content-transfer-encoding: base64
For this to work properly I had to code a hack along
these lines:
filename = part.get_filename()
if not filename:
ct = part.get("Content-type")
m = re.compile('name=\"(\S+)\"').search(ct, 1)
if m: filename=m.group(1)
But it would be helpful to code this in the get_filename()
Michal
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-837242 ] id() for large ptr should return a long
Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? -- Comment By: Martin v. Löwis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1393109 ] cannot build SVN trunk on old systems
Bugs item #1393109, was opened at 2005-12-29 21:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: cannot build SVN trunk on old systems Initial Comment: Parser/asdl_c.py uses "/usr/bin/env python" to find a proper python, but the script don't work on old Pythons (at least it fails on 2.1 and older). iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 23:47 Message: Logged In: YES user_id=21627 Is this still a problem? Parser/asdl_c.py should not normally be invoked, unless you edit the grammar -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-02 05:31 Message: Logged In: YES user_id=33168 One issue I see in asdl.py is that new-style classes are used. I don't know if they are really necessary. You could try adding something like this to the top of asdl.py and see if that fixes things: try: object except NameError: class object: pass Or maybe we just shouldn't make them new-style if that does fix things. I don't have an old version of python around. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1397850 ] libpython2.4.so get not installed
Bugs item #1397850, was opened at 2006-01-05 17:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M elsetrue; \^M ... -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 23:55 Message: Logged In: YES user_id=21627 --enable-shared simply isn't supported on AIX. I'm tempted to reject this as "won't fix". If anything should be fixed, we should add *) AC_MSG_ERROR(--enable-shared not supported on this system) ;; to the # Other platforms follow if test $enable_shared = "yes"; then block. -- Comment By: hajo (hajoehlers) Date: 2006-01-10 22:26 Message: Logged In: YES user_id=1420117 Hi Neal if give up to test/fix the configure.in With the help from Ulrich Berning i build a static version and convert these to a shared one. See notes down below. Tnx for supporting Hajo $ cat ./mkshared.python
[ python-Bugs-1379984 ] HP-UX: Can't shl_load() a library containing Thread Local
Bugs item #1379984, was opened at 2005-12-14 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&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: Threads Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: Can't shl_load() a library containing Thread Local Initial Comment: HP-UX runtime loader does not support dynamic load of shared libraries that contain (TLS) thread local storage. As a result, when attempting to import modules that contain TLS the following error is reported: "/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage" This problem was discussed previously on the python.org mail list: http://mail.python.org/pipermail/python-list/2003-May/164024.html There is another option: Use LD_PRELOAD environment variable to cuase the runtime loader to 'pre-load' the pthreads library (and dependancies of the pthread library). See the dld.sl(5) man page for more info on LD_PRELOAD. But, I think a 5th option is ideal. If libpthread.sl (and the dependancies of libpthread) are linked into the python executable at build time then all of these problems are avoided. I suggest that the HP-UX (includes hp-ux on ia64) build process be modified so that libpthead (and depends) are linked in. Or, at least, make a note of this problem/solution in the HP-UX section of the README file distributed with python source. Here is the process I use to work around the TLS problem: HP-UX: bash$ BASECFLAGS="-DTHREAD_STACK_SIZE=0x5"; export BASECFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs='-lpthread -lstd_v2 -lCsup_v2 -lcl' bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install HP-UX on ia64: bash$ CC=cc; export CC bash$ CXX=aCC; export CXX bash$ BASECFLAGS="+DD64 -DTHREAD_STACK_SIZE=0x5"; export BASECFLAGS bash$ LDFLAGS="+DD64"; export LDFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs="-lpthread -lCsup -lstd_v2 -lunwind" bash$ unset CC bash$ unset CXX bash$ unset BASECFLAGS bash$ unset LDFLAGS bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install -- >Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 23:56 Message: Logged In: YES user_id=21627 Can you provide a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased
Bugs item #1379804, was opened at 2005-12-13 21:22
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&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: Documentation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Blade (blade_doyle)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP-UX thread stack size needs to be increased
Initial Comment:
On HP-UX the default thread stack size is
"insufficient" and probably needs to be increased if
threads are performing any heavy tasks. Obviously, the
ideal size depends on you application but I find that
THREAD_STACK_SIZE=0x5 works well for me.
Using the default thread stack size my multi-threading
tests were failing with a corrupt stack sometimes and
this stack trace other times:
#0 0x79db8c0c in _isspace+0x2d8 () from
/usr/lib/libnss_dns.1
#1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2
#2 0x7af4d320 in __gethostbyname_r+0x140 () from
/usr/lib/libc.2
#3 0x7af4d4bc in gethostbyname+0x94 () from
/usr/lib/libc.2
#4 here, I am calling: gethostbyname("localhost")
[cut]
#23 0x7a8c49ac in OpSession::begin+0x1c0 ()
from /space/bdoyle/hprisc/lib/oopython.sl
#24 0x7aa42660 in PyCFunction_Call+0xc8 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
[cut]
#38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#39 0x7ab17e8c in t_bootstrap+0xa0 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#40 0x7ab6400c in __pthread_body+0x44 () from
/usr/lib/libpthread.1
#41 0x7ab6e29c in __pthread_start+0x14 () from
/usr/lib/libpthread.1
I tested both Python 2.3.4 and 2.4.2 and increased
stack size solves the probem on both.
I suggest that a note be added to the Python README
under the HP-UX section. The note should suggest that
the "BASECFLAGS" environment variable be set to include
"-DTHREAD_STACK_SIZE=0x5" prior to running
configure. I dont know that 0x5 is really the
ideal stack size.
Blade.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-01-11 23:57
Message:
Logged In: YES
user_id=21627
Can you provide a patch to configure.in that adds this
automatically?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1403410 ] TypeError unsubscriptable object caused by warnings.py
Bugs item #1403410, was opened at 2006-01-12 00:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&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: FreyP (freyp_haufe) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError unsubscriptable object caused by warnings.py Initial Comment: We recently hit a problem with use of Python 2.4 under Zope. #The problem is that warnings.py expects that function warn_explicit is called with either module or filename beeing a string. This is not always true, especially when the warning is caused by a Python script, e.g. a non-ASCII character without encoding declaration causing a "Non-ASCII character ... in file ... on line ..., but no encoding declared; see ..." the slice operation 'if module[-3:].lower() == ".py":' in line 64 (Python 2.4.1) or 67 (Python 2.4.2) causes a TypeError: unsubscriptable object because both module and filename are None. The original warning message that would be very helpful gets lost and is replaced by a misterious TypeError that is hard to find unless debugging and stepping into the Python runtime. There would be a simple fix by modifing the assignment in the line above from module = filename to module = filename or "(unknown)" we found also bugtracker entry [ 890010 ] "Odd warning behaviors" that is similar but has a completely different focus. Could someone please fix this problem either with the fix above or something better? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1397850 ] libpython2.4.so get not installed
Bugs item #1397850, was opened at 2006-01-05 08:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M elsetrue; \^M ... -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-11 15:02 Message: Logged In: YES user_id=33168 If it's not supported, then I definitely agree we should add the error message you propose. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 14:55 Message: Logged In: YES user_id=21627 --enable-shared simply isn't supported on AIX. I'm tempted to reject this as "won't fix". If anything should be fixed, we should add *) AC_MSG_ERROR(--enable-shared not supported on this system) ;; to the # Other platforms follow if test $enable_shared = "yes"; then block. -- Comment By: hajo (hajoehlers) Date: 2006-01-10 13:26 Message: Logged In: YES user_id=1420117 Hi Neal if give up to test/fix the configure.in With the help from Ulrich Berning i build a static version and convert these to a shared one. See notes down below. Tnx for supporting Hajo $ cat ./mkshared.python
[ python-Bugs-1379984 ] HP-UX: Can't shl_load() a library containing Thread Local
Bugs item #1379984, was opened at 2005-12-14 00:20 Message generated for change (Comment added) made by blade_doyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&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: Threads Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: Can't shl_load() a library containing Thread Local Initial Comment: HP-UX runtime loader does not support dynamic load of shared libraries that contain (TLS) thread local storage. As a result, when attempting to import modules that contain TLS the following error is reported: "/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage" This problem was discussed previously on the python.org mail list: http://mail.python.org/pipermail/python-list/2003-May/164024.html There is another option: Use LD_PRELOAD environment variable to cuase the runtime loader to 'pre-load' the pthreads library (and dependancies of the pthread library). See the dld.sl(5) man page for more info on LD_PRELOAD. But, I think a 5th option is ideal. If libpthread.sl (and the dependancies of libpthread) are linked into the python executable at build time then all of these problems are avoided. I suggest that the HP-UX (includes hp-ux on ia64) build process be modified so that libpthead (and depends) are linked in. Or, at least, make a note of this problem/solution in the HP-UX section of the README file distributed with python source. Here is the process I use to work around the TLS problem: HP-UX: bash$ BASECFLAGS="-DTHREAD_STACK_SIZE=0x5"; export BASECFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs='-lpthread -lstd_v2 -lCsup_v2 -lcl' bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install HP-UX on ia64: bash$ CC=cc; export CC bash$ CXX=aCC; export CXX bash$ BASECFLAGS="+DD64 -DTHREAD_STACK_SIZE=0x5"; export BASECFLAGS bash$ LDFLAGS="+DD64"; export LDFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs="-lpthread -lCsup -lstd_v2 -lunwind" bash$ unset CC bash$ unset CXX bash$ unset BASECFLAGS bash$ unset LDFLAGS bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install -- >Comment By: Blade (blade_doyle) Date: 2006-01-11 23:20 Message: Logged In: YES user_id=1404264 I think so. Please stay tuned. I'll post the patch when I have it ready. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 22:56 Message: Logged In: YES user_id=21627 Can you provide a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased
Bugs item #1379804, was opened at 2005-12-13 20:22
Message generated for change (Comment added) made by blade_doyle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&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: Documentation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Blade (blade_doyle)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP-UX thread stack size needs to be increased
Initial Comment:
On HP-UX the default thread stack size is
"insufficient" and probably needs to be increased if
threads are performing any heavy tasks. Obviously, the
ideal size depends on you application but I find that
THREAD_STACK_SIZE=0x5 works well for me.
Using the default thread stack size my multi-threading
tests were failing with a corrupt stack sometimes and
this stack trace other times:
#0 0x79db8c0c in _isspace+0x2d8 () from
/usr/lib/libnss_dns.1
#1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2
#2 0x7af4d320 in __gethostbyname_r+0x140 () from
/usr/lib/libc.2
#3 0x7af4d4bc in gethostbyname+0x94 () from
/usr/lib/libc.2
#4 here, I am calling: gethostbyname("localhost")
[cut]
#23 0x7a8c49ac in OpSession::begin+0x1c0 ()
from /space/bdoyle/hprisc/lib/oopython.sl
#24 0x7aa42660 in PyCFunction_Call+0xc8 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
[cut]
#38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#39 0x7ab17e8c in t_bootstrap+0xa0 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#40 0x7ab6400c in __pthread_body+0x44 () from
/usr/lib/libpthread.1
#41 0x7ab6e29c in __pthread_start+0x14 () from
/usr/lib/libpthread.1
I tested both Python 2.3.4 and 2.4.2 and increased
stack size solves the probem on both.
I suggest that a note be added to the Python README
under the HP-UX section. The note should suggest that
the "BASECFLAGS" environment variable be set to include
"-DTHREAD_STACK_SIZE=0x5" prior to running
configure. I dont know that 0x5 is really the
ideal stack size.
Blade.
--
>Comment By: Blade (blade_doyle)
Date: 2006-01-11 23:42
Message:
Logged In: YES
user_id=1404264
I think I can generate that patch. I'll give a try. I
found the patch guidelines for the Python project at
http://www.python.org/patches/ so that greatly increases my
chances of success!
One concern that I have is with the stack size value of
"0x5". I find that there is a wide range of default
stack sizes for the various operating systems. There does
not seem to be any consensus on a good default value. This
quote exemplifies the situation:
"On Tru64 UNIX, the default thread stack size increased from
24 KB to 5 MB in Version 5.0. On HP-UX, it is only 64 KB on
PA systems and 256 KB on Itanium®-based systems."
Quote From:
http://devrsrc1.external.hp.com/STKT/impacts/i375.html
How can I settle on a stacksize for this patch? Unless
there are other suggestions I'll stick with "0x5"
because I have tested that and know it works for what I
consider an 'average' application.
Thanks,
Blade.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-01-11 22:57
Message:
Logged In: YES
user_id=21627
Can you provide a patch to configure.in that adds this
automatically?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased
Bugs item #1379804, was opened at 2005-12-13 21:22
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&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: Documentation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Blade (blade_doyle)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP-UX thread stack size needs to be increased
Initial Comment:
On HP-UX the default thread stack size is
"insufficient" and probably needs to be increased if
threads are performing any heavy tasks. Obviously, the
ideal size depends on you application but I find that
THREAD_STACK_SIZE=0x5 works well for me.
Using the default thread stack size my multi-threading
tests were failing with a corrupt stack sometimes and
this stack trace other times:
#0 0x79db8c0c in _isspace+0x2d8 () from
/usr/lib/libnss_dns.1
#1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2
#2 0x7af4d320 in __gethostbyname_r+0x140 () from
/usr/lib/libc.2
#3 0x7af4d4bc in gethostbyname+0x94 () from
/usr/lib/libc.2
#4 here, I am calling: gethostbyname("localhost")
[cut]
#23 0x7a8c49ac in OpSession::begin+0x1c0 ()
from /space/bdoyle/hprisc/lib/oopython.sl
#24 0x7aa42660 in PyCFunction_Call+0xc8 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
[cut]
#38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#39 0x7ab17e8c in t_bootstrap+0xa0 ()
from
/space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl
#40 0x7ab6400c in __pthread_body+0x44 () from
/usr/lib/libpthread.1
#41 0x7ab6e29c in __pthread_start+0x14 () from
/usr/lib/libpthread.1
I tested both Python 2.3.4 and 2.4.2 and increased
stack size solves the probem on both.
I suggest that a note be added to the Python README
under the HP-UX section. The note should suggest that
the "BASECFLAGS" environment variable be set to include
"-DTHREAD_STACK_SIZE=0x5" prior to running
configure. I dont know that 0x5 is really the
ideal stack size.
Blade.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-01-12 06:40
Message:
Logged In: YES
user_id=21627
Python has a standard, cross-platform initial recursion
limit (sys.getrecursionlimit()). The stacksize should be
large enough to accommodate this recursion limit, or else
the initial recursionlimit should be decreased on the
platform to fit into the default stacksize.
If you increase sys.setrecursionlimit, you should be able to
overrun the processor stack with a recursive program, so you
can find out what recursion depth the standard stack supports.
--
Comment By: Blade (blade_doyle)
Date: 2006-01-12 00:42
Message:
Logged In: YES
user_id=1404264
I think I can generate that patch. I'll give a try. I
found the patch guidelines for the Python project at
http://www.python.org/patches/ so that greatly increases my
chances of success!
One concern that I have is with the stack size value of
"0x5". I find that there is a wide range of default
stack sizes for the various operating systems. There does
not seem to be any consensus on a good default value. This
quote exemplifies the situation:
"On Tru64 UNIX, the default thread stack size increased from
24 KB to 5 MB in Version 5.0. On HP-UX, it is only 64 KB on
PA systems and 256 KB on Itanium®-based systems."
Quote From:
http://devrsrc1.external.hp.com/STKT/impacts/i375.html
How can I settle on a stacksize for this patch? Unless
there are other suggestions I'll stick with "0x5"
because I have tested that and know it works for what I
consider an 'average' application.
Thanks,
Blade.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-01-11 23:57
Message:
Logged In: YES
user_id=21627
Can you provide a patch to configure.in that adds this
automatically?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
