[issue7160] Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes

2009-10-17 Thread Michael J. Fromberger 

New submission from Michael J. Fromberger :

A segmentation fault is generated in _ctypes.so when calling a function that 
returns a char pointer on a system 
with 64-bit pointer types.  The attached crash dump is from a Python 2.6.3 
built from MacPorts ("port install 
python26 +no_tkinter"), but the same behaviour occurs with the Python 2.6.1 
installed by Apple.

To reproduce, build the attached sample program ("testlib.c"):

% gcc -Wall -c testlib.o
% ld -dylib -o testlib.so testlib.o

Then, in Python:

# Common setup for each of the cases below.
>>> from ctypes import *
>>> lib = CDLL('testlib.so')

# Case 1: Integer return value (no crash).
>>> get_value = CFUNCTYPE(c_int)(lib.get_value)
>>> get_value()
12345

# Case 2: Pointer argument value (no crash).
>>> buf = create_string_buffer(256)
>>> copy_message = CFUNCTYPE(None, c_char_p)(lib.copy_message)
>>> copy_message(buf)

# Case 3: Pointer return value (crash).
>>> get_message = CFUNCTYPE(c_char_p)(lib.get_message)
>>> get_message()
Segmentation fault

-- System information:

% uname -a
MacOS 10.6.1
Darwin gorion.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 
PDT 2009; root:xnu-
1456.1.25~1/RELEASE_I386 i386

% python
Python 2.6.3 (r263:75183, Oct 17 2009, 01:49:30) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin

% gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)

--
assignee: theller
components: ctypes
files: testlib.c
messages: 94181
nosy: creachadair, theller
severity: normal
status: open
title: Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15154/testlib.c

___
Python tracker 
<http://bugs.python.org/issue7160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7160] Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes

2009-10-17 Thread Michael J. Fromberger 

Changes by Michael J. Fromberger :


Added file: http://bugs.python.org/file15155/crash-report.txt

___
Python tracker 
<http://bugs.python.org/issue7160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7160] Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes

2009-10-17 Thread Michael J. Fromberger 

Michael J. Fromberger  added the comment:

I believe this error occurs because a pointer value is being truncated to 
32 bits.  The exception code is

KERN_INVALID_ADDRESS at 0x002fe020

If you add a diagnostic printout to the body of get_message(), you will 
see that its return value is 0x1002fe020, so in other words, the high-
order word 0x0001 is being discarded somewhere.

--

___
Python tracker 
<http://bugs.python.org/issue7160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7160] Crash when returning a 64-bit char pointer in Python 2.6.3 ctypes

2009-10-19 Thread Michael J. Fromberger 

Michael J. Fromberger  added the comment:

Thank you for setting me straight. 

I see now that I misunderstood the scope of `CFUNCTYPE`, as I was using 
it as a general wrapper when in fact it's only needed for callbacks. 
Mistakenly, I inferred from reading section 16.15.2.4 of the ctypes 
manual [1] that it would be necessary to create prototype wrappers for 
calls into the foreign library as well. Obviously that is not the case, 
since your described solution works fine.

[1] <http://www.python.org/doc/2.6.3/library/ctypes.html#function-
prototypes>

--
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue7160>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5809] "No such file or directory" with framework build under MacOS 10.4.11

2009-04-21 Thread Michael J. Fromberger 

New submission from Michael J. Fromberger :

Checkout:
<http://svn.python.org/projects/python/tags/r262>

Configure:
env CFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib" sh 
./configure --enable-framework --enable-shared --enable-readline

Build:
make

The configuration step completes successfully, and the build proceeds; 
however, the following error occurs:

gcc -L/opt/local/lib -u _PyMac_Error 
Python.framework/Versions/2.6/Python -o python.exe \
Modules/python.o \
-L. -lpython2.6 -ldl  

This appears to be a problem in the definition of the LINKFORSHARED 
variable in the Makefile, but I am not sure what the intended meaning of 
that variable is, so I'm not sure what the fix should be.

A complete make trace is attached.

--
components: Build
files: makedump.txt
messages: 86245
nosy: creachadair
severity: normal
status: open
title: "No such file or directory" with framework build under MacOS 10.4.11
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file13728/makedump.txt

___
Python tracker 
<http://bugs.python.org/issue5809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5809] "No such file or directory" with framework build under MacOS 10.4.11

2009-04-21 Thread Michael J. Fromberger 

Michael J. Fromberger  added the comment:

Sorry, I managed to not copy the error message.  It is:

i686-apple-darwin8-gcc-4.0.1: Python.framework/Versions/2.6/Python: No 
such file or directory
make: *** [python.exe] Error 1

--

___
Python tracker 
<http://bugs.python.org/issue5809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5809] "No such file or directory" with framework build under MacOS 10.4.11

2009-05-08 Thread Michael J. Fromberger 

Michael J. Fromberger  added the comment:

Ned Deily writes:
> --enable-framework and --enable-shared are mutually exclusive options. 

Aha, I did not realize that, though I suppose in retrospect it should have 
been obvious.  Removing "--enable-shared" from my build configuration does 
enable me to build with "--enable-framework" selected.

I agree that this should be either better documented, or checked for by 
the configurator.

--

___
Python tracker 
<http://bugs.python.org/issue5809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com