[ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Bugs item #1578513, was opened at 2006-10-17 07:27 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&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.4 Status: Open Resolution: None Priority: 7 Submitted By: smithj (smithj_rpath) Assigned to: Anthony Baxter (anthonybaxter) Summary: 2.4.4c1 will not build when cross compiling Initial Comment: When trying to build 2.4.4c1 with cross-compiling, I get the following error. checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling ./config.log:configure:20566: checking for /dev/ptmx ./config.log:configure:20572: error: cannot check for file existence when cross compiling This does not occur with 2.4.3. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 22:50 Message: Logged In: YES user_id=29957 Goody - autoconf debugging, my absolute favourite! r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon, 31 Jul 2006) | 3 lines Drop usage of test -e in configure as it is not portable. Fixes #1439538 -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-17 08:27 Message: Logged In: YES user_id=44345 Boosting this and at least provisionally assigning to Anthony since it's related to a change between 2.4.3 and 2.4.4c1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Bugs item #1578513, was opened at 2006-10-17 07:27 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&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.4 Status: Open Resolution: None >Priority: 9 Submitted By: smithj (smithj_rpath) >Assigned to: Martin v. Löwis (loewis) Summary: 2.4.4c1 will not build when cross compiling Initial Comment: When trying to build 2.4.4c1 with cross-compiling, I get the following error. checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling ./config.log:configure:20566: checking for /dev/ptmx ./config.log:configure:20572: error: cannot check for file existence when cross compiling This does not occur with 2.4.3. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 23:21 Message: Logged In: YES user_id=29957 Ok, this revision is definitely the problem - it switched from using our own test to autoconf's AC_CHECK_FILE. This breaks things. Yay. :-/ Looking closer - we used to use our own test -e check. autoconf uses test -r. The attached patch reverses that fix, and changes back to our own test, using test -r instead. Can you please test this? Martin, can you check this out? I had to hand-edit the patch, because autoconf on this box spat out a vast number of extra pointless changes. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 22:50 Message: Logged In: YES user_id=29957 Goody - autoconf debugging, my absolute favourite! r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon, 31 Jul 2006) | 3 lines Drop usage of test -e in configure as it is not portable. Fixes #1439538 -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-17 08:27 Message: Logged In: YES user_id=44345 Boosting this and at least provisionally assigning to Anthony since it's related to a change between 2.4.3 and 2.4.4c1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Bugs item #1578513, was opened at 2006-10-16 17:27 Message generated for change (Comment added) made by smithj_rpath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&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.4 Status: Open Resolution: None Priority: 9 Submitted By: smithj (smithj_rpath) Assigned to: Martin v. Löwis (loewis) Summary: 2.4.4c1 will not build when cross compiling Initial Comment: When trying to build 2.4.4c1 with cross-compiling, I get the following error. checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling ./config.log:configure:20566: checking for /dev/ptmx ./config.log:configure:20572: error: cannot check for file existence when cross compiling This does not occur with 2.4.3. -- >Comment By: smithj (smithj_rpath) Date: 2006-10-17 10:38 Message: Logged In: YES user_id=1622486 Yes, that patch does fix the issue. Thank you. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 09:21 Message: Logged In: YES user_id=29957 Ok, this revision is definitely the problem - it switched from using our own test to autoconf's AC_CHECK_FILE. This breaks things. Yay. :-/ Looking closer - we used to use our own test -e check. autoconf uses test -r. The attached patch reverses that fix, and changes back to our own test, using test -r instead. Can you please test this? Martin, can you check this out? I had to hand-edit the patch, because autoconf on this box spat out a vast number of extra pointless changes. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 08:50 Message: Logged In: YES user_id=29957 Goody - autoconf debugging, my absolute favourite! r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon, 31 Jul 2006) | 3 lines Drop usage of test -e in configure as it is not portable. Fixes #1439538 -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-16 18:27 Message: Logged In: YES user_id=44345 Boosting this and at least provisionally assigning to Anthony since it's related to a change between 2.4.3 and 2.4.4c1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 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=1579029&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Bugs item #1578513, was opened at 2006-10-16 23:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&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.4 Status: Open Resolution: None Priority: 9 Submitted By: smithj (smithj_rpath) Assigned to: Martin v. Löwis (loewis) Summary: 2.4.4c1 will not build when cross compiling Initial Comment: When trying to build 2.4.4c1 with cross-compiling, I get the following error. checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling ./config.log:configure:20566: checking for /dev/ptmx ./config.log:configure:20572: error: cannot check for file existence when cross compiling This does not occur with 2.4.3. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-17 17:37 Message: Logged In: YES user_id=21627 The patch looks fine to me. Of course, the check result is still bogus for cross-compilation (so it doesn't, and really can't, "work"), as we cannot know whether /dev/something exists on the target machine. As for regenerating configure: it should work fine if you install a stock autoconf 2.59 (I typically have one in ~/ac259). If you happen to use a Debian-or-Redhat-modified one, regeneration will often include unrelated changes. As there really isn't a better way to deal with it, this should then also be forward-ported to 2.5 and 2.6. -- Comment By: smithj (smithj_rpath) Date: 2006-10-17 16:38 Message: Logged In: YES user_id=1622486 Yes, that patch does fix the issue. Thank you. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 15:21 Message: Logged In: YES user_id=29957 Ok, this revision is definitely the problem - it switched from using our own test to autoconf's AC_CHECK_FILE. This breaks things. Yay. :-/ Looking closer - we used to use our own test -e check. autoconf uses test -r. The attached patch reverses that fix, and changes back to our own test, using test -r instead. Can you please test this? Martin, can you check this out? I had to hand-edit the patch, because autoconf on this box spat out a vast number of extra pointless changes. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 14:50 Message: Logged In: YES user_id=29957 Goody - autoconf debugging, my absolute favourite! r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon, 31 Jul 2006) | 3 lines Drop usage of test -e in configure as it is not portable. Fixes #1439538 -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-17 00:27 Message: Logged In: YES user_id=44345 Boosting this and at least provisionally assigning to Anthony since it's related to a change between 2.4.3 and 2.4.4c1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1578269 ] Add os.link() and os.symlink() support for Windows
Feature Requests item #1578269, was opened at 2006-10-16 17:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&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.6 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.link() and os.symlink() support for Windows Initial Comment: NTFS version 5.0 and up has all the needed APIs for creating hard links and symlinks (junctions), so it should be possible to add support for both hard links and symlinks to the posixmodule. Here are a few references: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html (see list of links at the end of the page) http://www.codeproject.com/w2k/junctionpoints.asp (junction points only, but includes analysis and source code) Note: NTFS 5.0 is supported in Win 2k, XP, 2003 and later. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-17 17:47 Message: Logged In: YES user_id=21627 We shouldn't expose junctions as symlinks. Instead, Vista will get real symlinks, so we should use that: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Bugs item #1578513, was opened at 2006-10-17 07:27 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&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: smithj (smithj_rpath) >Assigned to: Anthony Baxter (anthonybaxter) Summary: 2.4.4c1 will not build when cross compiling Initial Comment: When trying to build 2.4.4c1 with cross-compiling, I get the following error. checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling ./config.log:configure:20566: checking for /dev/ptmx ./config.log:configure:20572: error: cannot check for file existence when cross compiling This does not occur with 2.4.3. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-18 02:11 Message: Logged In: YES user_id=29957 Yeah, this is the ubuntu version of autoconf, oh well. I don't have time right now to mess around with installing a new autoconf (it's late, and I have a release in the morning). Checked into release24-maint as r52358, will be part of 2.4.4 (and 2.5.1 and 2.6 when I forward-port it). Leaving open as a reminder. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-18 01:37 Message: Logged In: YES user_id=21627 The patch looks fine to me. Of course, the check result is still bogus for cross-compilation (so it doesn't, and really can't, "work"), as we cannot know whether /dev/something exists on the target machine. As for regenerating configure: it should work fine if you install a stock autoconf 2.59 (I typically have one in ~/ac259). If you happen to use a Debian-or-Redhat-modified one, regeneration will often include unrelated changes. As there really isn't a better way to deal with it, this should then also be forward-ported to 2.5 and 2.6. -- Comment By: smithj (smithj_rpath) Date: 2006-10-18 00:38 Message: Logged In: YES user_id=1622486 Yes, that patch does fix the issue. Thank you. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 23:21 Message: Logged In: YES user_id=29957 Ok, this revision is definitely the problem - it switched from using our own test to autoconf's AC_CHECK_FILE. This breaks things. Yay. :-/ Looking closer - we used to use our own test -e check. autoconf uses test -r. The attached patch reverses that fix, and changes back to our own test, using test -r instead. Can you please test this? Martin, can you check this out? I had to hand-edit the patch, because autoconf on this box spat out a vast number of extra pointless changes. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 22:50 Message: Logged In: YES user_id=29957 Goody - autoconf debugging, my absolute favourite! r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon, 31 Jul 2006) | 3 lines Drop usage of test -e in configure as it is not portable. Fixes #1439538 -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-17 08:27 Message: Logged In: YES user_id=44345 Boosting this and at least provisionally assigning to Anthony since it's related to a change between 2.4.3 and 2.4.4c1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1575945 ] from_param and _as_parameter_ truncating 64-bit value
Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value
Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.
SConstruct to build library:
env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])
C code:
#include
void nnz(double *ary) {
printf("ary = %p\n", (void*)ary);
}
Python code:
import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)
Output on 32-bit system:
data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8
Output on 64-bit system:
data_as c_void_p(46912559644688)
array interface 0x2e740010
ary = 0x2e740010
ary = 0xae740010
_as_parameter 0x2e740010
--
>Comment By: Thomas Heller (theller)
Date: 2006-10-17 19:48
Message:
Logged In: YES
user_id=11105
I replaced in numpy/core/_internal.py, version 1.0rc2, the
get_as_parameter method with this code:
def get_as_parameter(self):
##return self._data
return self._ctypes.c_void_p(self._data)
and here is the script and the output on a 64-bit Linux
system, with Python 2.5:
[EMAIL PROTECTED]:~/devel/release25-maint$ cat param.py
import numpy
from numpy.ctypeslib import ndpointer
from ctypes import *
import _ctypes_test
A = numpy.eye(1280)
print A.__array_interface__['data'],
hex(A.__array_interface__['data'][0])
func = CDLL(_ctypes_test.__file__)._testfunc_p_p
func.restype = c_void_p
func.argtypes = [ndpointer(dtype=numpy.float64)]
print hex(func(A))
[EMAIL PROTECTED]:~/devel/release25-maint$ ./python param.py
(46912527945744, False) 0x2c905010
0x2c905010
[EMAIL PROTECTED]:~/devel/release25-maint$
As you can see the 64-bit pointer is passed through the
function. _testfunc_p_p in _ctypes_test.so is simply
char * _testfunc_p_p (void *s)
{
return (char *)s;
}
--
Comment By: Albert Strasheim (albertstrasheim)
Date: 2006-10-16 18:18
Message:
Logged In: YES
user_id=945096
Changing NumPy's _as_parameter_ to return the pointer as a
c_void_p causes ctypes to raise the following erorr:
ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1
--
Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05
Message:
Logged In: YES
user_id=11105
This is not a ctypes bug.
It seems that A.ctypes._as_parameter_ is a Python integer.
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)
To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-10-14 22:07
Message:
Logged In: YES
user_id=21627
Thomas, can you take a look? If not, please unassign.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1578513 ] 2.4.4c1 will not build when cross compiling
Bugs item #1578513, was opened at 2006-10-16 23:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&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: Closed >Resolution: Fixed Priority: 5 Submitted By: smithj (smithj_rpath) Assigned to: Anthony Baxter (anthonybaxter) Summary: 2.4.4c1 will not build when cross compiling Initial Comment: When trying to build 2.4.4c1 with cross-compiling, I get the following error. checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling ./config.log:configure:20566: checking for /dev/ptmx ./config.log:configure:20572: error: cannot check for file existence when cross compiling This does not occur with 2.4.3. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-17 21:00 Message: Logged In: YES user_id=21627 Committed into 2.5 as 52362, and the trunk as 52363. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 18:11 Message: Logged In: YES user_id=29957 Yeah, this is the ubuntu version of autoconf, oh well. I don't have time right now to mess around with installing a new autoconf (it's late, and I have a release in the morning). Checked into release24-maint as r52358, will be part of 2.4.4 (and 2.5.1 and 2.6 when I forward-port it). Leaving open as a reminder. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-17 17:37 Message: Logged In: YES user_id=21627 The patch looks fine to me. Of course, the check result is still bogus for cross-compilation (so it doesn't, and really can't, "work"), as we cannot know whether /dev/something exists on the target machine. As for regenerating configure: it should work fine if you install a stock autoconf 2.59 (I typically have one in ~/ac259). If you happen to use a Debian-or-Redhat-modified one, regeneration will often include unrelated changes. As there really isn't a better way to deal with it, this should then also be forward-ported to 2.5 and 2.6. -- Comment By: smithj (smithj_rpath) Date: 2006-10-17 16:38 Message: Logged In: YES user_id=1622486 Yes, that patch does fix the issue. Thank you. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 15:21 Message: Logged In: YES user_id=29957 Ok, this revision is definitely the problem - it switched from using our own test to autoconf's AC_CHECK_FILE. This breaks things. Yay. :-/ Looking closer - we used to use our own test -e check. autoconf uses test -r. The attached patch reverses that fix, and changes back to our own test, using test -r instead. Can you please test this? Martin, can you check this out? I had to hand-edit the patch, because autoconf on this box spat out a vast number of extra pointless changes. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-10-17 14:50 Message: Logged In: YES user_id=29957 Goody - autoconf debugging, my absolute favourite! r50983 | martin.v.loewis | 2006-07-31 00:11:03 +1000 (Mon, 31 Jul 2006) | 3 lines Drop usage of test -e in configure as it is not portable. Fixes #1439538 -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-17 00:27 Message: Logged In: YES user_id=44345 Boosting this and at least provisionally assigning to Anthony since it's related to a change between 2.4.3 and 2.4.4c1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1578513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574584 ] Error with callback function and as_parameter with NumPy ndp
Bugs item #1574584, was opened at 2006-10-10 17:11
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: Error with callback function and as_parameter with NumPy ndp
Initial Comment:
I posted to the ctypes-users mailing list about this
problem, but SourceForge failed to make that post and
its replies available in the ctypes-users archive, so
I'm repeating it here.
I'm using NumPy with ctypes. I would like to create a
callback function that calls into Python, allocates a
NumPy array and returns a suitable pointer to the C code.
NumPy has a function called ndpointer that allows one
to specify some details of NumPy arrays when dealing
with argtypes. This function also takes care of
extracting the array's data pointer.
Details here:
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/ctypeslib.py
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/core/_internal.py
Creating a callback function as follows works:
stuff = []
import numpy
def allocator1():
x = numpy.array([...], dtype='f4')
stuff.append(x)
return x.ctypes.data_as(POINTER(c_float))
CFUNCTYPE(POINTER(c_float))(allocator1)
However, if one adds ndpointer to the mix, an error occurs:
stuff = []
import numpy
def allocator2():
x = numpy.array([...], dtype='f4')
stuff.append(x)
return x
CFUNCTYPE(numpy.ctypeslib.ndpointer('f4'))(allocator2)
The error is:
SystemError: NULL result without error in PyObject_Call
Thomas Heller has a patch for this issue.
--
>Comment By: Thomas Heller (theller)
Date: 2006-10-17 21:47
Message:
Logged In: YES
user_id=11105
At least the 'SystemError: NULL result without error in
PyObject_Call' is fixed now in SVN revision 52367
(release25-maint), and revision 52365 (trunk).
You will now get a 'TypeError: unsupported result type for
callback function'.
That's all I can do for Python 2.5, anyway.
I suggest that possible workarounds should be discussed on
the ctypes-users list.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-723205 ] PyThreadState_Clear() docs incorrect
Bugs item #723205, was opened at 2003-04-17 18:12 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&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: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_Clear() docs incorrect Initial Comment: The docs state that the GIL must be held while PyThreadStare_Clear() is called. This seems incorrect, at least in Python 2.2 the thread state must not be NULL under certain conditions. See: http://mail.python.org/pipermail/python-dev/2003-April/034574.html -- >Comment By: Thomas Heller (theller) Date: 2006-10-17 21:57 Message: Logged In: YES user_id=11105 I retract this request. -- Comment By: Thomas Heller (theller) Date: 2003-04-17 20:36 Message: Logged In: YES user_id=11105 Sorry, that's because I'm still confused about thread states, and I think the experts ;-) should sort this out. No, I'm not claiming that the GIL does not need to be held, I'm claiming that this is not sufficient: *in addition* the current threadstate must not be NULL. To quote from the mentioned posts: I was doing this: pts = PyThreadState_Swap(NULL); PyThreadState_Clear(pts); PyThreadState_Delete(pts); PyEval_ReleaseLock(); and got a crash in PyThreadState_Clear(). If I understand the current docs correctly, this should be allowed, so (my conclusion) the docs are wrong. I had to change the code in this way to avoid the crashes: pts = PyThreadState_Get(); PyThreadState_Clear(pts); pts = PyThreadState_Swap(NULL); PyThreadState_Delete(pts); PyEval_ReleaseLock(); -- Comment By: Tim Peters (tim_one) Date: 2003-04-17 20:10 Message: Logged In: YES user_id=31435 That was a confusing thread, and this is a confusing bug report. Are you claiming that the GIL does not need to be held? If not (and it doesn't seem that you were in the thread), it's unclear why you mention the GIL. Best would be if you attached a patch incorporating what you think the resolution of that thread was. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723205&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1575945 ] from_param and _as_parameter_ truncating 64-bit value
Bugs item #1575945, was opened at 2006-10-12 16:25
Message generated for change (Comment added) made by sjvdw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: from_param and _as_parameter_ truncating 64-bit value
Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.
SConstruct to build library:
env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])
C code:
#include
void nnz(double *ary) {
printf("ary = %p\n", (void*)ary);
}
Python code:
import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)
Output on 32-bit system:
data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8
Output on 64-bit system:
data_as c_void_p(46912559644688)
array interface 0x2e740010
ary = 0x2e740010
ary = 0xae740010
_as_parameter 0x2e740010
--
Comment By: Stefan van der Walt (sjvdw)
Date: 2006-10-18 03:40
Message:
Logged In: YES
user_id=1104792
On both 32 and 64-bit systems, running param.py under python
2.4 with ctypes 1.0.0 and numpy from SVN (with patch
applied) I see:
$ python param.py
(-1264099320, False)
Traceback (most recent call last):
File "param.py", line 16, in ?
print hex(func(A))
ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1
--
Comment By: Thomas Heller (theller)
Date: 2006-10-17 19:48
Message:
Logged In: YES
user_id=11105
I replaced in numpy/core/_internal.py, version 1.0rc2, the
get_as_parameter method with this code:
def get_as_parameter(self):
##return self._data
return self._ctypes.c_void_p(self._data)
and here is the script and the output on a 64-bit Linux
system, with Python 2.5:
[EMAIL PROTECTED]:~/devel/release25-maint$ cat param.py
import numpy
from numpy.ctypeslib import ndpointer
from ctypes import *
import _ctypes_test
A = numpy.eye(1280)
print A.__array_interface__['data'],
hex(A.__array_interface__['data'][0])
func = CDLL(_ctypes_test.__file__)._testfunc_p_p
func.restype = c_void_p
func.argtypes = [ndpointer(dtype=numpy.float64)]
print hex(func(A))
[EMAIL PROTECTED]:~/devel/release25-maint$ ./python param.py
(46912527945744, False) 0x2c905010
0x2c905010
[EMAIL PROTECTED]:~/devel/release25-maint$
As you can see the 64-bit pointer is passed through the
function. _testfunc_p_p in _ctypes_test.so is simply
char * _testfunc_p_p (void *s)
{
return (char *)s;
}
--
Comment By: Albert Strasheim (albertstrasheim)
Date: 2006-10-16 18:18
Message:
Logged In: YES
user_id=945096
Changing NumPy's _as_parameter_ to return the pointer as a
c_void_p causes ctypes to raise the following erorr:
ctypes.ArgumentError: argument 1: exceptions.TypeError:
Don't know how to convert parameter 1
--
Comment By: Thomas Heller (theller)
Date: 2006-10-16 17:05
Message:
Logged In: YES
user_id=11105
This is not a ctypes bug.
It seems that A.ctypes._as_parameter_ is a Python integer.
These are passed as 'C int' type to foreign function calls.
(The C int type typically has 32 bits on 64-bit platforms,
while a pointer has 64 bit.)
To pass a pointer, A.ctypes._as_parameter_ should be a
ctypes c_void_p instance, not a Python integer.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-10-14 22:07
Message:
Logged In: YES
user_id=21627
Thomas, can you take a look? If not, please unassign.
--
You can respond by visiting:
https:/
[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-17 19:23 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=1579370&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-17 19:23 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- >Comment By: Mike Klaas (mklaas) Date: 2006-10-17 19:23 Message: Logged In: YES user_id=1611720 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208400192 (LWP 26235)] 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 94 if ((next != NULL && !PyTraceBack_Check(next)) || (gdb) bt #0 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 #1 0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4, throwflag=1) at Python/ceval.c:2459 #2 0x08101a40 in gen_send_ex (gen=0xb64f880c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #3 0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at Objects/genobject.c:128 #4 0x08101cde in gen_del (self=0xb64f880c) at Objects/genobject.c:163 #5 0x0810195b in gen_dealloc (gen=0xb64f880c) at Objects/genobject.c:31 #6 0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c, throwflag=1) at Python/ceval.c:2491 #7 0x08101a40 in gen_send_ex (gen=0xb64f362c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #8 0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at Objects/genobject.c:128 #9 0x08101cde in gen_del (self=0xb64f362c) at Objects/genobject.c:163 #10 0x0810195b in gen_dealloc (gen=0xb64f362c) at Objects/genobject.c:31 #11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at Objects/dictobject.c:801 #12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at Objects/typeobject.c:686 #13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at Objects/classobject.c:2285 #14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at Objects/dictobject.c:801 #15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at Objects/typeobject.c:686 #16 0x081028c5 in frame_dealloc (f=0x9c272bc) at Objects/frameobject.c:416 #17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at Python/traceback.c:34 #18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at Python/traceback.c:33 #19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at Python/traceback.c:33 #20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930, hash=1492466088, value=0xb3fb9914) at Objects/dictobject.c:394 #21 0x080811a4 in PyDict_SetItem (op=0xb7f56824, key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619 #22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824, key=0x8129284 "exc_traceback", item=0xb3fb9914) at Objects/dictobject.c:2103 #23 0x080e2837 in PySys_SetObject (name=0x8129284 "exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82 #24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c, throwflag=0) at Python/ceval.c:2954 #25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890, globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1, kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1, closure=0x0) at Python/ceval.c:2833 #26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c, throwflag=0) at Python/ceval.c:3662 #27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848, globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1, kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #28 0x08104083 in function_call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517 #29 0x0805a660 in PyObject_Call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860 #30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c, throwflag=0) at Python/ceval.c:3846 #31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608, globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2, kws=0x9b77664, kwcount=0, defs=0x0, defcount=0, closure=0xb7cfe874) at Python/ceval.c:2833 #32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c, throwflag=0) at Python/ceval.c:3662 #33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c, throwflag=0) at Pyt
[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-17 19:23 Message generated for change (Settings changed) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&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.5 Status: Open Resolution: None >Priority: 7 Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- Comment By: Mike Klaas (mklaas) Date: 2006-10-17 19:23 Message: Logged In: YES user_id=1611720 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208400192 (LWP 26235)] 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 94 if ((next != NULL && !PyTraceBack_Check(next)) || (gdb) bt #0 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 #1 0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4, throwflag=1) at Python/ceval.c:2459 #2 0x08101a40 in gen_send_ex (gen=0xb64f880c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #3 0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at Objects/genobject.c:128 #4 0x08101cde in gen_del (self=0xb64f880c) at Objects/genobject.c:163 #5 0x0810195b in gen_dealloc (gen=0xb64f880c) at Objects/genobject.c:31 #6 0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c, throwflag=1) at Python/ceval.c:2491 #7 0x08101a40 in gen_send_ex (gen=0xb64f362c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #8 0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at Objects/genobject.c:128 #9 0x08101cde in gen_del (self=0xb64f362c) at Objects/genobject.c:163 #10 0x0810195b in gen_dealloc (gen=0xb64f362c) at Objects/genobject.c:31 #11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at Objects/dictobject.c:801 #12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at Objects/typeobject.c:686 #13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at Objects/classobject.c:2285 #14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at Objects/dictobject.c:801 #15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at Objects/typeobject.c:686 #16 0x081028c5 in frame_dealloc (f=0x9c272bc) at Objects/frameobject.c:416 #17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at Python/traceback.c:34 #18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at Python/traceback.c:33 #19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at Python/traceback.c:33 #20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930, hash=1492466088, value=0xb3fb9914) at Objects/dictobject.c:394 #21 0x080811a4 in PyDict_SetItem (op=0xb7f56824, key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619 #22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824, key=0x8129284 "exc_traceback", item=0xb3fb9914) at Objects/dictobject.c:2103 #23 0x080e2837 in PySys_SetObject (name=0x8129284 "exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82 #24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c, throwflag=0) at Python/ceval.c:2954 #25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890, globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1, kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1, closure=0x0) at Python/ceval.c:2833 #26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c, throwflag=0) at Python/ceval.c:3662 #27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848, globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1, kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #28 0x08104083 in function_call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517 #29 0x0805a660 in PyObject_Call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860 #30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c, throwflag=0) at Python/ceval.c:3846 #31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608, globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2, kws=0x9b77664, kwcount=0, defs=0x0, defcount=0, closure=0xb7cfe874) at Python/ceval.c:2833 #32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c, throwflag=0) at Python/ceval.c:3662 #33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c, throwflag=0) at
