From ideasman42 at gmail.com  Fri Oct  3 08:31:58 2008
From: ideasman42 at gmail.com (Campbell Barton)
Date: Fri, 3 Oct 2008 16:31:58 +1000
Subject: [capi-sig] overriding pythons import - change in 2.6
Message-ID: <7c1ab96d0810022331g7a65ed31m454ff0c4a11e512a@mail.gmail.com>

was trying to hunt down why modules would not import in Blender3D with
python 2.6, and found its caused by an extra argument to import that
was making our own internal replacement for __builtin__.__import__
fail.

Added an #ifdef to work around this, for anyone else replacing the
builtin import, this could save you some time.

static PyObject *blender_import( PyObject * self, PyObject * args )
{
	PyObject *exception, *err, *tb;
	char *name;
	PyObject *globals = NULL, *locals = NULL, *fromlist = NULL;
	PyObject *m;
	//PyObject_Print(args, stderr, 0);
#if (PY_VERSION_HEX >= 0x02060000)
	int dummy_val; /* what does this do?*/
	
	if( !PyArg_ParseTuple( args, "s|OOOi:bimport",
			       &name, &globals, &locals, &fromlist, &dummy_val) )
		return NULL;
#else
	if( !PyArg_ParseTuple( args, "s|OOO:bimport",
			       &name, &globals, &locals, &fromlist ) )
		return NULL;
#endif
	m = PyImport_ImportModuleEx( name, globals, locals, fromlist );

	if( m )
		return m;
	else
		PyErr_Fetch( &exception, &err, &tb );	/*restore for probable later use */



-- 
- Campbell

From doriankrause at web.de  Thu Oct  9 10:25:26 2008
From: doriankrause at web.de (Dorian Krause)
Date: Thu, 09 Oct 2008 10:25:26 +0200
Subject: [capi-sig] python and fpos_t
Message-ID: <861377372@web.de>

Hello everybody,

I stumbled about a curious problem: Including <Python.h> changes the size of fpos_t.

m01% cat fpos_python.cc 
#ifdef HAVE_PYTHON_H
#include <Python.h>
#endif /* HAVE_PYTHON_H */
#include <stdio.h>
int main(int argc, char** argv)
{
  printf("sizeof(fpos_t) = %d\n",sizeof(fpos_t));
}
m01% g++ -DHAVE_PYTHON_H -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out
sizeof(fpos_t) = 16
m01% g++ -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out 
sizeof(fpos_t) = 12

This breaks my code if I do not include <Python.h> in ALL of my compilation modules (which is not pratical in my opinion).

Is this a known problem? I personally would call this definitely a bug. What is the rational behind changing fpos_t?

Thanks.

Regards,
Dorian K.





________________________________________________________________________
"50 erste Dates" mit Adam Sandler u. Drew Barrymore kostenlos anschauen!
Exklusiv f?r alle WEB.DE Nutzer. http://www.blockbuster.web.de


From rhamph at gmail.com  Thu Oct  9 10:52:58 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Thu, 9 Oct 2008 02:52:58 -0600
Subject: [capi-sig] python and fpos_t
In-Reply-To: <861377372@web.de>
References: <861377372@web.de>
Message-ID: <aac2c7cb0810090152o67ce0fbbs8ac264385f391b03@mail.gmail.com>

On Thu, Oct 9, 2008 at 2:25 AM, Dorian Krause <doriankrause at web.de> wrote:
> Hello everybody,
>
> I stumbled about a curious problem: Including <Python.h> changes the size of fpos_t.
>
> m01% cat fpos_python.cc
> #ifdef HAVE_PYTHON_H
> #include <Python.h>
> #endif /* HAVE_PYTHON_H */
> #include <stdio.h>
> int main(int argc, char** argv)
> {
>  printf("sizeof(fpos_t) = %d\n",sizeof(fpos_t));
> }
> m01% g++ -DHAVE_PYTHON_H -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out
> sizeof(fpos_t) = 16
> m01% g++ -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out
> sizeof(fpos_t) = 12
>
> This breaks my code if I do not include <Python.h> in ALL of my compilation modules (which is not pratical in my opinion).
>
> Is this a known problem? I personally would call this definitely a bug. What is the rational behind changing fpos_t?

Definitely a bug, but the question is why it happens.  I don't see any
python headers redefining it.  It may be a bug in the system headers
that python is just provoking.

gcc's -save-temps may provide some diagnostics.  Also, try moving
#include <stdio.h> above Python.h.  I can't think of anything else at
the moment.


-- 
Adam Olsen, aka Rhamphoryncus

From hniksic at xemacs.org  Thu Oct  9 10:50:06 2008
From: hniksic at xemacs.org (Hrvoje Niksic)
Date: Thu, 09 Oct 2008 10:50:06 +0200
Subject: [capi-sig] python and fpos_t
In-Reply-To: <861377372@web.de> (Dorian Krause's message of "Thu\,
	09 Oct 2008 10\:25\:26 +0200")
References: <861377372@web.de>
Message-ID: <87tzbm885d.fsf@mulj.homelinux.net>

Dorian Krause <doriankrause at web.de> writes:

> I stumbled about a curious problem: Including <Python.h> changes the
> size of fpos_t.
[...]
> This breaks my code if I do not include <Python.h> in ALL of my
> compilation modules (which is not pratical in my opinion).
>
> Is this a known problem? I personally would call this definitely a
> bug. What is the rational behind changing fpos_t?

This is a result of Python.h requesting "large file support" from the
libc, by something like "#define _FILE_OFFSET_BITS 64".  So it's not
the case that Python defines its own version fpos_t, it tells libc to
consistently use 64-bit quantities for file offset, which changes
off_t, fpos_t, and probably other file-related types.  Without this
Python itself wouldn't support files larger than 2G.

You can compile your other modules with "#define _FILE_OFFSET_BITS 64"
and you'll be compatible with Python without including all of
Python.h.  These macros are described in some detail in the glibc
manual, "info libc 'Feature Test Macros'".

From anti00Zero at gmx.de  Thu Oct 16 11:17:30 2008
From: anti00Zero at gmx.de (anti00Zero)
Date: Thu, 16 Oct 2008 11:17:30 +0200
Subject: [capi-sig] Python2.6 and PyImport_ImportModule
Message-ID: <20081016091730.105760@gmx.net>

Hello.

I've use Python 2.5 and want to use Python 2.6.
But I have a problem with PyImport_ImportModule.

c++ code:

PyObject* pModule = PyImport_ImportModule(pBuffer);



pBuffer is for example theme.simple.index

and my script looks like:

import MyModule
import sys

def StartWebInterface(cppObjectWeb, cppObjectSettings):
	cppObjectWeb.SetHTTPHeaderContentType(u'text/html; charset=utf-8')
	cppObjectWeb.SetHTTPHeaderExt(u'')
	page = u''
	try:
		page = u'''<html>
					<head>
						<title>'''
		servername = cppObjectSettings.GetSettingsFromMethod(DeviceFriendlyName)
		page += servername
		page += u'''</title>
					</head>
					<body>
						<h1>'''
		page += servername
		page += u'''</h1>
					<a href="?f=browse">Browse Directory</a><br />
					<a href="?f=settings">Settings</a>
					</body>
			   </html>'''
	except:
		page = BuildErrorPage()
	
	cppObjectWeb.SetPage(page)

def BuildErrorPage():
	page = u'''<html>
					<head>
						<title>Python Error</title>
					</head>
					<body>'''
	page += sys.exc_info()
	page += u'</body></html>'
	return page



But the PyImport_ImportModule crashed my c++ program.
The index.py was compiled because a new index.pyc was created.


Thanks for help.
-- 
Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

From Jack.Jansen at cwi.nl  Thu Oct 16 22:00:13 2008
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Thu, 16 Oct 2008 22:00:13 +0200
Subject: [capi-sig] Python2.6 and PyImport_ImportModule
In-Reply-To: <20081016091730.105760@gmx.net>
References: <20081016091730.105760@gmx.net>
Message-ID: <1BBB5CBD-9F2A-4959-B4A5-8B496FBDD89E@cwi.nl>

This could be one of thousands of things. If it works with 2.5 and no  
more with 2.6 some possible candidates are (1) a bug in Python, (2) a  
difference in memory layout which caused buggy code to work correct in  
2.5 nonetheless or (3) a timing difference, with the same effect.

Oh yes, if you're on Windows and using the prebuilt dll it could also  
be caused by runtime library differences, I think 2.5 was built with  
VS2003 and 2.6 with VS2005.

You'll need to provide a bit more detail if you want more help (OS and  
version, how you built Python and your app, is your code in an  
extension module or embedding Python, how does it crash, did you get a  
stack trace, etc)

--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



From anti00Zero at gmx.de  Sat Oct 18 10:03:32 2008
From: anti00Zero at gmx.de (anti00Zero)
Date: Sat, 18 Oct 2008 10:03:32 +0200
Subject: [capi-sig] Python2.6 and PyImport_ImportModule
In-Reply-To: <1BBB5CBD-9F2A-4959-B4A5-8B496FBDD89E@cwi.nl>
References: <20081016091730.105760@gmx.net>
	<1BBB5CBD-9F2A-4959-B4A5-8B496FBDD89E@cwi.nl>
Message-ID: <48F99854.50003@gmx.de>

I'm sorry.
Here are some facts:

Winodws XP SP3 with newest updates
Visual Studio 2005
Microsoft Visual C++ 2005 Redistributable
I downloaded Python 2.6 installer for Windows from python.org
I use Python with boost 1.36 for Python (could this be a problem?)

I want to use Python 2.6 because it was (i think so) built with VS2005. 
So I haven't to use msvcr71.dll.
On monday I can send a stack trace and a screenshot of this crash a with 
E-Mail.


Jack Jansen wrote:
> This could be one of thousands of things. If it works with 2.5 and no 
> more with 2.6 some possible candidates are (1) a bug in Python, (2) a 
> difference in memory layout which caused buggy code to work correct in 
> 2.5 nonetheless or (3) a timing difference, with the same effect.
>
> Oh yes, if you're on Windows and using the prebuilt dll it could also 
> be caused by runtime library differences, I think 2.5 was built with 
> VS2003 and 2.6 with VS2005.
>
> You'll need to provide a bit more detail if you want more help (OS and 
> version, how you built Python and your app, is your code in an 
> extension module or embedding Python, how does it crash, did you get a 
> stack trace, etc)
>
> --
>
> Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack 
> <http://www.cwi.nl/%7Ejack>
>
> If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman
>
>
>

From anti00Zero at gmx.de  Mon Oct 20 15:24:10 2008
From: anti00Zero at gmx.de (anti00Zero)
Date: Mon, 20 Oct 2008 15:24:10 +0200
Subject: [capi-sig] Jack.Jansen@cwi.nl
Message-ID: <20081020132410.65060@gmx.net>

Here is a screenshot and the call stack:



 	ntdll.dll!_KiFastSystemCallRet at 0() 	
 	user32.dll!_NtUserWaitMessage at 0()  + 0xc bytes	
 	user32.dll!_InternalDialogBox at 24()  + 0xb6 bytes	
 	user32.dll!_SoftModalMessageBox at 4()  + 0x677 bytes	
 	user32.dll!_MessageBoxWorker at 4()  + 0x175 bytes	
 	user32.dll!_MessageBoxTimeoutW at 24()  + 0x7a bytes	
 	user32.dll!_MessageBoxTimeoutA at 24()  + 0x9c bytes	
 	user32.dll!_MessageBoxExA at 20()  + 0x1b bytes	
 	user32.dll!_MessageBoxA at 16()  + 0x45 bytes	
 	[Frames below may be incorrect and/or missing, no symbols loaded for python25.dll]	
 	kernel32.dll!_CreateFileA at 28()  + 0x2b bytes	
 	python26.dll!1e00f11b() 	
 	python26.dll!1e00c7b5() 	
 	python26.dll!1e007ac3() 	
 	python26.dll!1e01cceb() 	
 	msvcr90.dll!_sopen_helper(const char * path=0x0fd0dc68, int oflag=32768, int shflag=64, int pmode=384, int * pfh=0x0fd0d7c8, int bSecure=1)  Line 190 + 0x5 bytes	
 	msvcr90.dll!_sopen_s(int * pfh=0x0fd0d7c8, const char * path=0x0fd0dc68, int oflag=32768, int shflag=64, int pmode=384)  Line 907 + 0x16 bytes	
 	msvcr90.dll!_openfile(const char * filename=0x1e1a53b2, const char * mode=0x1e0097c7, int shflag=265345024, _iobuf * str=0x00000025)  Line 272 + 0x17 bytes	
 	00000025()	
 	python26.dll!1e0094af() 	
 	python26.dll!1e01cf9d() 	
 	msvcr90.dll!__lock_fhandle(int fh=89305032)  Line 468 + 0x5 bytes	
 	NMMediaServer.dll!initMediaHomeWebInterface()  Line 32 + 0x30 bytes	C++
 	python26.dll!1e025c0d() 	
 	python26.dll!1e020bc3() 	
 	python26.dll!1e026cf5() 	
 	python26.dll!1e026d27() 	
 	ntdll.dll!_RtlGetFullPathName_Ustr at 24()  + 0x2f7 bytes	
 	python26.dll!1e00ed6e() 	
 	python26.dll!1e009136() 	
 	python26.dll!1e00fcc6() 	
 	python26.dll!1e00919a() 	
 	python26.dll!1e0157a1() 	
 	ntdll.dll!_RtlAllocateHeapSlowly at 12()  + 0x3da bytes	
 	msvcr90.dll!malloc(unsigned int size=408)  Line 163 + 0x5f bytes	
>	python26.dll!1e01530b() 	
 	python26.dll!1e010317() 	
 	python26.dll!1e01fd3d() 	
 	python26.dll!1e01d91e() 	
 	python26.dll!1e020b31() 	
 	msvcr90.dll!__lock_fhandle(int fh=3)  Line 467	
 	msvcr90.dll!_close(int fh=503378203)  Line 62 + 0x8 bytes	
 	msvcr90.dll!_close(int fh=503378203)  Line 66 + 0x5 bytes	
 	0e439f10()	
 	python26.dll!1e010091() 	
 	python26.dll!1e020b72() 	
 	python26.dll!1e017284() 	
 	python26.dll!1e0172bc() 	
 	NMMediaServer.dll!std::_Iterator_base::~_Iterator_base()  Line 151 + 0x28 bytes	C++
 	NMUPnPServices.dll!CILibWebRequestHeader::CILibWebRequestHeader(packetheader * pHeader=0x00000000)  Line 90 + 0x19 bytes	C++
 	ffffffff()	

The problem is msvcr90.dll? Why this dll for Visual Studio 2008? I thought it should be 2005. :-?

>I'm sorry.
>Here are some facts:
>
>Winodws XP SP3 with newest updates
>Visual Studio 2005
>Microsoft Visual C++ 2005 Redistributable I downloaded Python 2.6 installer for Windows from >python.org I use Python with boost 1.36 for Python (could this be a problem?)
>
>I want to use Python 2.6 because it was (i think so) built with VS2005.
>So I haven't to use msvcr71.dll.
>On monday I can send a stack trace and a screenshot of this crash a with E-Mail.
>
>
>Jack Jansen wrote:
>> This could be one of thousands of things. If it works with 2.5 and no 
>> more with 2.6 some possible candidates are (1) a bug in Python, (2) a 
>> difference in memory layout which caused buggy code to work correct in
>> 2.5 nonetheless or (3) a timing difference, with the same effect.
>>
>> Oh yes, if you're on Windows and using the prebuilt dll it could also 
>> be caused by runtime library differences, I think 2.5 was built with
>> VS2003 and 2.6 with VS2005.
>>
>> You'll need to provide a bit more detail if you want more help (OS and 
>> version, how you built Python and your app, is your code in an 
>> extension module or embedding Python, how does it crash, did you get a 
>> stack trace, etc)
>>
>> --
>>
>> Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack 
>> <http://www.cwi.nl/%7Ejack>
>>
>> If I can't dance I don't want to be part of your revolution -- Emma 
>> Goldman
>>
>>
>>


From Jack.Jansen at cwi.nl  Tue Oct 21 11:46:51 2008
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Tue, 21 Oct 2008 11:46:51 +0200
Subject: [capi-sig] Jack.Jansen@cwi.nl
In-Reply-To: <20081020132410.65060@gmx.net>
References: <20081020132410.65060@gmx.net>
Message-ID: <4E64E3B8-2302-4505-95FB-1B62DBC645C2@cwi.nl>


On 20-Oct-2008, at 15:24 , anti00Zero wrote:
>
> The problem is msvcr90.dll? Why this dll for Visual Studio 2008? I  
> thought it should be 2005. :-?
>>

That could be the problem, indeed. So maybe Python 2.6 was built with  
VS2008?? Does anyone know?


--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



From mal at egenix.com  Tue Oct 21 11:50:23 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 21 Oct 2008 11:50:23 +0200
Subject: [capi-sig] Jack.Jansen@cwi.nl
In-Reply-To: <4E64E3B8-2302-4505-95FB-1B62DBC645C2@cwi.nl>
References: <20081020132410.65060@gmx.net>
	<4E64E3B8-2302-4505-95FB-1B62DBC645C2@cwi.nl>
Message-ID: <48FDA5DF.8000007@egenix.com>

On 2008-10-21 11:46, Jack Jansen wrote:
> 
> On 20-Oct-2008, at 15:24 , anti00Zero wrote:
>>
>> The problem is msvcr90.dll? Why this dll for Visual Studio 2008? I
>> thought it should be 2005. :-?
>>>
> 
> That could be the problem, indeed. So maybe Python 2.6 was built with
> VS2008?? Does anyone know?

Python 2.6 is being build with Visual Studio 2008 Professional Edition.

The marketing name maps to VC9.0 and the code needs the msvcr90.dll
as runtime.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 21 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From ideasman42 at gmail.com  Wed Oct 22 05:34:17 2008
From: ideasman42 at gmail.com (Campbell Barton)
Date: Wed, 22 Oct 2008 14:34:17 +1100
Subject: [capi-sig] Fix random crashes - embedding py/w PyObject pointers to
	app data.
Message-ID: <7c1ab96d0810212034s190c1253ne27d1b15cd00675d@mail.gmail.com>

Hi, just spent a couple of hours looking into a bug that others might also have.
If your app embeds python, and allows scripts to throw exceptions
while the application keeps running you may also have this problem.

sys.last_traceback will store the last exception along with the
namespace dictionary of the script that just ran (with all its
functions etc, variables etc).

In our case this caused crashes because you could load in new data,
making many of the PyObjects referenced from sys.last_traceback, point
to invalid data. Once sys.last_traceback was set again it would free
the existing data sometimes touching pointers with invalid addresses
causing a segfault.

Simple solution is to run this after PyErr_Print();

 PySys_SetObject( "last_traceback", Py_None);

This can also free memory, if large datasets are references from the
traceback. maybe some of your would fine this useful.

-- 
- Campbell

From rhamph at gmail.com  Wed Oct 22 06:03:29 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Tue, 21 Oct 2008 22:03:29 -0600
Subject: [capi-sig] Fix random crashes - embedding py/w PyObject
	pointers to app data.
In-Reply-To: <7c1ab96d0810212034s190c1253ne27d1b15cd00675d@mail.gmail.com>
References: <7c1ab96d0810212034s190c1253ne27d1b15cd00675d@mail.gmail.com>
Message-ID: <aac2c7cb0810212103o3ed580d4g7a1218283c8615dd@mail.gmail.com>

On Tue, Oct 21, 2008 at 9:34 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> Hi, just spent a couple of hours looking into a bug that others might also have.
> If your app embeds python, and allows scripts to throw exceptions
> while the application keeps running you may also have this problem.
>
> sys.last_traceback will store the last exception along with the
> namespace dictionary of the script that just ran (with all its
> functions etc, variables etc).
>
> In our case this caused crashes because you could load in new data,
> making many of the PyObjects referenced from sys.last_traceback, point
> to invalid data. Once sys.last_traceback was set again it would free
> the existing data sometimes touching pointers with invalid addresses
> causing a segfault.
>
> Simple solution is to run this after PyErr_Print();
>
>  PySys_SetObject( "last_traceback", Py_None);
>
> This can also free memory, if large datasets are references from the
> traceback. maybe some of your would fine this useful.

Do you mean you have a PyObject with a pointer to malloc'd memory, and
after the exception is handled (but not cleared) you free the malloc'd
memory, but leave the PyObject with a pointer to it?  If so you should
be keeping track of any PyObjects and clearing them instead (or let
them take care of freeing the malloc'd memory).


-- 
Adam Olsen, aka Rhamphoryncus

From rhamph at gmail.com  Wed Oct 22 08:52:18 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Wed, 22 Oct 2008 00:52:18 -0600
Subject: [capi-sig] Fix random crashes - embedding py/w PyObject
	pointers to app data.
In-Reply-To: <7c1ab96d0810212154t73b80d63o364719befadb08c5@mail.gmail.com>
References: <7c1ab96d0810212034s190c1253ne27d1b15cd00675d@mail.gmail.com>
	<aac2c7cb0810212103o3ed580d4g7a1218283c8615dd@mail.gmail.com>
	<7c1ab96d0810212154t73b80d63o364719befadb08c5@mail.gmail.com>
Message-ID: <aac2c7cb0810212352u3aefea7bt1b97538dcaaee3c3@mail.gmail.com>

On Tue, Oct 21, 2008 at 10:54 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Wed, Oct 22, 2008 at 3:03 PM, Adam Olsen <rhamph at gmail.com> wrote:
>> On Tue, Oct 21, 2008 at 9:34 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>> Hi, just spent a couple of hours looking into a bug that others might also have.
>>> If your app embeds python, and allows scripts to throw exceptions
>>> while the application keeps running you may also have this problem.
>>>
>>> sys.last_traceback will store the last exception along with the
>>> namespace dictionary of the script that just ran (with all its
>>> functions etc, variables etc).
>>>
>>> In our case this caused crashes because you could load in new data,
>>> making many of the PyObjects referenced from sys.last_traceback, point
>>> to invalid data. Once sys.last_traceback was set again it would free
>>> the existing data sometimes touching pointers with invalid addresses
>>> causing a segfault.
>>>
>>> Simple solution is to run this after PyErr_Print();
>>>
>>>  PySys_SetObject( "last_traceback", Py_None);
>>>
>>> This can also free memory, if large datasets are references from the
>>> traceback. maybe some of your would fine this useful.
>>
>> Do you mean you have a PyObject with a pointer to malloc'd memory, and
>> after the exception is handled (but not cleared) you free the malloc'd
>> memory, but leave the PyObject with a pointer to it?  If so you should
>> be keeping track of any PyObjects and clearing them instead (or let
>> them take care of freeing the malloc'd memory).
>
> Yeah, this is the case and you're right, we should be aware of the
> PyObjects existence and invalidate them when the memory is freed, or
> let python do the freeing.
> But our application does not center around python, the PyAPI has its
> own directory and PyObjects are not supposed to be used outside that.
> Id be interested in knowing what other apps do - is this even a common problem?

Common in the sense that other apps probably do it right, yes. ;)

How are you calling into python?  If you call a single python function
(which in turn calls many others), and this is what raises the
exception, this is the obvious point to trigger the clearing.



-- 
Adam Olsen, aka Rhamphoryncus

From sudharsh at gmail.com  Mon Oct 27 13:48:10 2008
From: sudharsh at gmail.com (Sudharshan S)
Date: Mon, 27 Oct 2008 18:18:10 +0530
Subject: [capi-sig] Passing non-PyObjects as args to PyObject_CallObject
Message-ID: <3f97c09d0810270548r62c64ac0p74eb35474d41ade8@mail.gmail.com>

Hi all,
My project uses GLib's GObject and recently I thought of adding support for
executing python scripts by embedding the interpreter within the code.
However there is this need to pass a GOB struct as one of the parameters to
a function in the python script. How exactly do I pass non-PyObject types
with the API?

I tried (to be clever) casting my GOB structure to PyObject and passing it
in the args field of PyObject_CallObject. This of course turned out to be an
EPIC FAIL with
a nasty segfault.  (I also tried Py_BuildValue with 'O&' signature)

It would be wonderful if some points me to some code which does this. From
what I gather, do I need to create some sort of a Type Object which the
Python API can understand? If it matters, I am using the 2.5 API.

Thanks and regards
Sudharshan S
Blog : http://www.sudharsh.wordpress.com
IRC  : Sup3rkiddo @ Freenode, Gimpnet

From hniksic at xemacs.org  Mon Oct 27 14:12:04 2008
From: hniksic at xemacs.org (Hrvoje Niksic)
Date: Mon, 27 Oct 2008 14:12:04 +0100
Subject: [capi-sig] Passing non-PyObjects as args to PyObject_CallObject
In-Reply-To: <3f97c09d0810270548r62c64ac0p74eb35474d41ade8@mail.gmail.com>
	(Sudharshan S.'s message of "Mon\, 27 Oct 2008 18\:18\:10 +0530")
References: <3f97c09d0810270548r62c64ac0p74eb35474d41ade8@mail.gmail.com>
Message-ID: <87skqi89nf.fsf@mulj.homelinux.net>

"Sudharshan S" <sudharsh at gmail.com> writes:

> My project uses GLib's GObject and recently I thought of adding
> support for executing python scripts by embedding the interpreter
> within the code.  However there is this need to pass a GOB struct as
> one of the parameters to a function in the python script. How
> exactly do I pass non-PyObject types with the API?

The gobject wrapper probably supports converting a GObject instance to
a PyGobject visible from Python.  Failing that, you can always create
a PyCObject (an opaque object containing a pointer) and use it to pass
the pointer to your struct.

http://docs.python.org/c-api/cobject.html