Mailing-List: contact pylucene-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pylucene-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Subject: Re: Problem using generic types?
References: <alpine.OSX.2.01.1308220245570.19200@yuzu.home>
 <0A6B8501-78AF-449D-B0DE-F8C5C246A8C9@gmail.com>
 <alpine.OSX.2.01.1308221056210.19504@yuzu.local>
 <44D35D89-EE36-47EE-A333-E0FEF273CB8E@gmail.com>
 <510160A1-CBEB-4FC1-826F-5074410EF2F9@apache.org>
 <71323F49-7C8E-4E4A-957D-C4FA178B6855@gmail.com>
 <21EBE0F5-06CE-4969-978D-D773DED75B03@apache.org>
 <288ABD0F-E844-4491-A16A-A42B03E9CB62@gmail.com>
 <5AB48BB3-FF7E-4154-B6EB-BF5D1BB9B3B9@apache.org>
 <CAP9QEefCXYz6C4inrfWNuo0Wn6A6ZieBBfXGqUxeSUTyYYw7xA@mail.gmail.com>
From: Andi Vajda <vajda@apache.org>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: 
 <CAP9QEefCXYz6C4inrfWNuo0Wn6A6ZieBBfXGqUxeSUTyYYw7xA@mail.gmail.com>
Message-Id: <6A1EE011-889C-4F45-A68C-7363B2DD239B@apache.org>
Date: Fri, 27 Dec 2013 18:25:49 +0100
To: "pylucene-dev@lucene.apache.org" <pylucene-dev@lucene.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)


> On Dec 27, 2013, at 17:36, Petrus Hyv=C3=B6nen <petrus.hyvonen@gmail.com> w=
rote:
>=20
> Dear Andi,
>=20
> I am working on debugging the failure and try to understand a bit how JCC
> works internally. I haven't gone very far but in case you have some
> pointers from these early debugging sessions I would be very thankful. I
> know it's complex, and I should try to make some smaller test cases, but I=

> don't really have a grasp yet where the problem might be.
>=20
> Writing this might help me also to get some structure in my thinking :)
>=20
>=20
>=20
> The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
>=20
>      static PyObject
> *t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDete=
ctor
> *self, PyObject *arg)
>        {
>          ::org::orekit::propagation::events::handlers::EventHandler
> a0((jobject) NULL);
>          PyTypeObject **p0;
>          ::org::orekit::propagation::events::EventDetector
> result((jobject) NULL);
>=20
>          if (!parseArg(arg, "K",
> ::org::orekit::propagation::events::handlers::EventHandler::initializeClas=
s,
> &a0, &p0,
> ::org::orekit::propagation::events::handlers::t_EventHandler::parameters_)=
)
>          {
>            OBJ_CALL(result =3D self->object.withHandler(a0));
>            return self->parameters[0] !=3D NULL ?
> wrapType(self->parameters[0], result.this$) :
> ::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
>          }
>=20
> The parameters[0] does not seem to be null, but neither is it a valid
> object, in my debugger it says 0xbaadf00d {ob_refcnt=3D??? ob_type=3D???
> ob_size=3D??? ...}     _typeobject *, wrapType is called and when trying t=
o
> access the wrapfn it crashes.
>=20
> The main python lines are:
> tmp1 =3D ElevationDetector(sta1Frame)                    # ElevationDetect=
or
> is a java public class ElevationDetector extends
> AbstractReconfigurableDetector<ElevationDetector>
> hand =3D ContinueOnEvent().of_(ElevationDetector)   # a
> java ContinueOnEvent<ElevationDetector> object
> elDetector =3D tmp1.withHandler(hand)     #Crash. withHandler is a method
> that is inherited from AbstractReconfigurableDetector to ElevationDetector=

>=20
> This crashes when interactively entered on the python prompt (or in other
> interactive consoles), but seems to work if executed directly without
> interactivity. This difference makes me think that it might be something
> with garbage collection, but don't know.
>=20
> Any comments appriciated, I know this is likely very difficult to comment
> on as it's not very encapsulated.

Right, so unless you can isolate this into something I can reproduce, I'm af=
raid there isn't much I can comment.
It is quite likely that by the time you have that reproducible test case rea=
dy, you also have the solution to the problem. Or I might be able to help th=
en...

Andi..

>=20
> Regards
> /Petrus
>=20
>=20
>=20
>=20
>=20
>=20
>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <vajda@apache.org> wrote:
>>=20
>>=20
>>>> On Dec 15, 2013, at 5:43, Petrus Hyv=C3=B6nen <petrus.hyvonen@gmail.com=
>
>>> wrote:
>>>=20
>>> Hi Andi,
>>>=20
>>> I see your point and have now kept in the pure python domain.
>>>=20
>>> If I run my script from the shell by "python script.py" it does not
>> crash. However if I execute it line-by-line in python it crashes (or in
>> other tools such as ipython notebook).
>>> All classes used are non-wrapped java classes, but I get the same effect=

>> with classes made for python subclassing.
>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>> python.
>>>=20
>>>=20
>>>>>> elDetector =3D
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGSEGV (0xb) at pc=3D0x000000010005da1a, pid=3D3318, tid=3D1287
>>> #
>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>> 1.7.0_45-b18)
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>> bsd-amd64 compressed oops)
>>> # Problematic frame:
>>> # C  [libpython2.7.dylib+0x5aa1a]  PyObject_GetAttr+0x1a
>>> #
>>>=20
>>>=20
>>> from the stack it seems like there is somthing happening in "wrapType"
>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],  sp=3D0x00007fff5fbff470=
,
>> free space=3D509k
>>> Native frames: (J=3Dcompiled Java code, j=3Dinterpreted, Vv=3DVM code,
>> C=3Dnative code)
>>> C  [libpython2.7.dylib+0x5aa1a]  PyObject_GetAttr+0x1a
>>> C  [_orekit.so+0xa80878]  wrapType(_typeobject*, _jobject* const&)+0x58
>>> C  [_orekit.so+0x554400]
>> org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHa=
ndler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
>> _object*)+0x1c0
>>>=20
>>> First, is the generic class assignment correct as if to write "new
>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use regula=
r
>> java objects/types?
>>>=20
>>> Any other comments to move forward highly appriciated.. Is it somehow
>> possible to get more log what is going wrong?
>>=20
>> You could compile the whole thing for debugging, by adding --debug after
>> 'build' in the jcc invocation and run it with gdb.
>>=20
>> If you can isolate a reproducible crash into a small test case, I can als=
o
>> take a look at it.
>>=20
>> Andi..
>>=20
>>>=20
>>> WIth best regards
>>> /Petrus
>>>=20
>>>=20
>>>=20
>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <vajda@apache.org> wrote:
>>>>=20
>>>>=20
>>>>> On Dec 14, 2013, at 19:14, Petrus Hyv=C3=B6nen <petrus.hyvonen@gmail.c=
om>
>> wrote:
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I'm having a problem with I think might be related to generic types,
>> but not sure at all.
>>>>>=20
>>>>> I'm wrapping a orbit calculation library, which has been working well
>> but in latest version is using generic types and I'm getting some problem=
s.
>> The script works when executed in plain python, but fails in ipython
>> notebook on this last line when executed as a couple of cells.
>>>>=20
>>>> What is an 'ipython notebook' ?
>>>>=20
>>>> Andi.,
>>>>=20
>>>>>=20
>>>>> The section with problem in my script is:
>>>>> elDetector =3D
>> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
>>>>> elDetector =3D
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>=20
>>>>> In Java it would typically look something like:
>>>>>=20
>>>>> ElevationDetector detector =3D new ElevationDetector(topo)
>>>>>                                         .withConstantElevation(x)
>>>>>                                         .withHandler(new
>> ContinueOnEvent<ElevationDetector>());
>>>>>=20
>>>>> It produces correct results in plain python, but crashes the kernel in=

>> ipython if executed as cells, and in exection from spyder I get an error
>> message:
>>>>>=20
>>>>> " elDetector =3D
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>=20
>>>>> As I have been using this setup stabely with lots of other functions
>> it feels like there is something with the generic type line, but I don't
>> really know how to get any further? I'm confused by that the pauses in th=
e
>> execution could seem to affect the result.
>>>>>=20
>>>>> Any comments highly appriciated...
>>>>>=20
>>>>> Best Regards
>>>>> /Petrus
>=20
>=20
>=20
> --=20
> _____________________________________________
> Petrus Hyv=C3=B6nen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00