[Python-3000] Possible py3k problem.

[Lambert, David W (S&T)]

Attached program works with

callback = GSL_FUNCTION(self.f)
set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)

But core dumps with

set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)

I do not understand the difference. Must be one of these possibilities:

1) Python3rc1+ is broken, or I don't understand it.

2) ctypes is broken, or I misunderstand.

3) My system---linux on 64 bit opteron---has installation sickness.

4) The actual cause.

Source attached. You'll possibly need to modify the code that loads
gsl.so's.

If it's a python problem, you should know of it.
If it's my problem---I've found the work 'round but I'd like to
understand.

Thanks! Dave.

[Christian Heimes]

Lambert, David W (S&T) wrote:
> Attached program works with
>
> callback = GSL_FUNCTION(self.f)
> set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)
>
> But core dumps with
>
> set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)
>

I had to change your module a bit to load the right library on my
system. Here is a backtrace:

This GDB was configured as "x86_64-linux-gnu"...
(gdb) run dump.py 1
Starting program: /home/heimes/dev/python/py3k/python dump.py 1
[Thread debugging using libthread_db enabled]
[New Thread 0x7fb4ed67d6e0 (LWP 18856)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb4ed67d6e0 (LWP 18856)]
0x00007fb4ebf094b0 in ?? () from /usr/lib/libgsl.so.0
(gdb) bt
#0 0x00007fb4ebf094b0 in ?? () from /usr/lib/libgsl.so.0
#1 0x00007fb4ebf08e07 in gsl_min_fminimizer_iterate () from
/usr/lib/libgsl.so.0
#2 0x00007fb4ec67281c in ffi_call_unix64 ()
at
/home/heimes/dev/python/py3k/Modules/_ctypes/libffi/src/x86/unix64.S:75
#3 0x00007fb4ec67222c in ffi_call (cif=0x7ffff569e650,
fn=0x7fb4ebf08dd0 <gsl_min_fminimizer_iterate>,
rvalue=0x7ffff569e710, avalue=0x7ffff569e6f0)
at
/home/heimes/dev/python/py3k/Modules/_ctypes/libffi/src/x86/ffi64.c:430
#4 0x00007fb4ec667a4d in _call_function_pointer (flags=4353,
pProc=0x7fb4ebf08dd0 <gsl_min_fminimizer_iterate>,
avalues=0x7ffff569e6f0, atypes=0x7ffff569e6d0,
restype=0xb37830, resmem=0x7ffff569e710, argcount=1)
at /home/heimes/dev/python/py3k/Modules/_ctypes/callproc.c:803
#5 0x00007fb4ec668665 in _CallProc (pProc=0x7fb4ebf08dd0
<gsl_min_fminimizer_iterate>, argtuple=0xb73b50,
flags=4353, argtypes=0xae9a00, restype=0xb37370, checker=0x0)
at /home/heimes/dev/python/py3k/Modules/_ctypes/callproc.c:1150
#6 0x00007fb4ec6616ca in CFuncPtr_call (self=0xa87e60, inargs=0xb73b50,
kwds=0x0)
at /home/heimes/dev/python/py3k/Modules/_ctypes/_ctypes.c:3775
#7 0x00000000004e819a in PyObject_Call (func=0xa87e60, arg=0xb73b50,
kw=0x0) at Objects/abstract.c:2184
_______________________________________________
Python-3000 mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: http://mail.python.org/mailman/options/python-3000/python-3000-garchive-63646%40googlegroups.com

[Guido van Rossum]

Core dumps generated using ctypes are not covered by the warrantee. ;-)

> _______________________________________________
> Python-3000 mailing list
> Pytho...@python.org
> http://mail.python.org/mailman/listinfo/python-3000

> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

[Nick Coghlan]

Guido van Rossum wrote:
> Core dumps generated using ctypes are not covered by the warrantee. ;-)

True, although it's a little bizarre that the version with the temporary
variable works, but the one without it doesn't.

Then again, the temp variable does change the timing on the Python side
as well as the memory layout, both of which could be relevant to whether
the program dumps core or not.

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
---------------------------------------------------------------

[Victor Stinner]

> Attached program works with

GSL is needed. Debian package: libgsl0-dev

dump.py works correctly on computer:
- Debian Sid
- python 3.0 trunk
- i386

Problem specific to x86_64?

Where is the issue? :-)

Victor

[pytho...@udmvt.ru]

On Tue, Nov 18, 2008 at 03:26:32PM -0500, Lambert, David W (S&T) wrote:
>
> Attached program works with
>
> callback = GSL_FUNCTION(self.f)
> set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)
>
> But core dumps with
>
> set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)
>
>
> I do not understand the difference. Must be one of these possibilities:

It would be interesting to know if slightly modified first version works
too:
set_with_values(mnzr,(typeof(callback))GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)

I'm not sure, that it will segfault too. But can't test it on Opteron, sorry
for that.

To clear out the situation, just want to ask, what is the type of callback
variable and how it differs from the type of GSL_FUNCTION(...) expression.

[Christian Heimes]

Victor Stinner wrote:
>> Attached program works with
>
> GSL is needed. Debian package: libgsl0-dev
>
> dump.py works correctly on computer:
> - Debian Sid
> - python 3.0 trunk
> - i386
>
> Problem specific to x86_64?
>
> Where is the issue? :-)

How did you run dump.py? It crashes only with "python3.0 dump.py 1"

Christian

[Victor Stinner]

Le Wednesday 19 November 2008 10:21:16 Victor Stinner, vous avez écrit :
> > Attached program works with
>
> GSL is needed. Debian package: libgsl0-dev
>
> dump.py works correctly on computer:

Ooops, "./python dump.py" is ok but "./python dump.py 1" does crash (on i386
and x86_64).

On i386, ffi_closure_SYSV_inner() crashs at "cif = closure->cif;" because
closure is NULL.

[Martin (gzlist)]

On 18/11/2008, Lambert, David W (S&T) <Lamb...@corning.com> wrote:
>
> Attached program works with
>
> callback = GSL_FUNCTION(self.f)
> set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB)
>
> But core dumps with
>
> set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB)

This is covered in the documentation, isn't it?

<http://docs.python.org/library/ctypes.html#callback-functions>

Important note for callback functions:

Make sure you keep references to CFUNCTYPE objects as long as they are
used from C code. ctypes doesn't, and if you don't, they may be
garbage collected, crashing your program when a callback is made.

Martin

[Victor Stinner]

Le Wednesday 19 November 2008 15:39:43 Martin (gzlist), vous avez écrit :
> This is covered in the documentation, isn't it?
>
> <http://docs.python.org/library/ctypes.html#callback-functions>
>
> Important note for callback functions:
>
> Make sure you keep references to CFUNCTYPE objects as long as they are
> used from C code. ctypes doesn't, and if you don't, they may be
> garbage collected, crashing your program when a callback is made.

Oh yes, I remember this problem... I took me hours/days to understand the
problem.

Is there a FAQ for ctypes? To list the most common problems. The bug is in the
documentation :-)

Victor

[Thomas Heller]

Victor Stinner schrieb:

> Le Wednesday 19 November 2008 15:39:43 Martin (gzlist), vous avez écrit :
>> This is covered in the documentation, isn't it?
>>
>> <http://docs.python.org/library/ctypes.html#callback-functions>
>>
>> Important note for callback functions:
>>
>> Make sure you keep references to CFUNCTYPE objects as long as they are
>> used from C code. ctypes doesn't, and if you don't, they may be
>> garbage collected, crashing your program when a callback is made.
>
> Oh yes, I remember this problem... I took me hours/days to understand the
> problem.
>
> Is there a FAQ for ctypes? To list the most common problems. The bug is in the
> documentation :-)

Ok, so can someone please contribute a patch for the docs to fix this 'bug'?
Or write a ctypes FAQ somewhere (where?)

--
Thanks,
Thomas