Dear Andi,
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.
Writing this might help me also to get some structure in my thinking :)
The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
static PyObject
*t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDetector
*self, PyObject *arg)
{
::org::orekit::propagation::events::handlers::EventHandler
a0((jobject) NULL);
PyTypeObject **p0;
::org::orekit::propagation::events::EventDetector
result((jobject) NULL);
if (!parseArg(arg, "K",
::org::orekit::propagation::events::handlers::EventHandler::initializeClass,
&a0, &p0,
::org::orekit::propagation::events::handlers::t_EventHandler::parameters_))
{
OBJ_CALL(result = self->object.withHandler(a0));
return self->parameters[0] != NULL ?
wrapType(self->parameters[0], result.this$) :
::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
}
The parameters[0] does not seem to be null, but neither is it a valid
object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
ob_size=??? ...} _typeobject *, wrapType is called and when trying to
access the wrapfn it crashes.
The main python lines are:
tmp1 = ElevationDetector(sta1Frame) # ElevationDetector
is a java public class ElevationDetector extends
AbstractReconfigurableDetector<ElevationDetector>
hand = ContinueOnEvent().of_(ElevationDetector) # a
java ContinueOnEvent<ElevationDetector> object
elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
that is inherited from AbstractReconfigurableDetector to ElevationDetector
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.
Any comments appriciated, I know this is likely very difficult to comment
on as it's not very encapsulated.
Regards
/Petrus
On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
> > On Dec 15, 2013, at 5:43, Petrus Hyvönen <petrus.hyvo...@gmail.com>
> wrote:
> >
> > Hi Andi,
> >
> > I see your point and have now kept in the pure python domain.
> >
> > 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.
> >
> >
> >>>> elDetector =
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
> > #
> > # 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
> > #
> >
> >
> > from the stack it seems like there is somthing happening in "wrapType"
> > Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470,
> free space=509k
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native 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_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
> _object*)+0x1c0
> >
> > First, is the generic class assignment correct as if to write "new
> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use regular
> java objects/types?
> >
> > Any other comments to move forward highly appriciated.. Is it somehow
> possible to get more log what is going wrong?
>
> You could compile the whole thing for debugging, by adding --debug after
> 'build' in the jcc invocation and run it with gdb.
>
> If you can isolate a reproducible crash into a small test case, I can also
> take a look at it.
>
> Andi..
>
> >
> > WIth best regards
> > /Petrus
> >
> >
> >
> >> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
> >>
> >>
> >>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvo...@gmail.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm having a problem with I think might be related to generic types,
> but not sure at all.
> >>>
> >>> 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 problems.
> The script works when executed in plain python, but fails in ipython
> notebook on this last line when executed as a couple of cells.
> >>
> >> What is an 'ipython notebook' ?
> >>
> >> Andi.,
> >>
> >>>
> >>> The section with problem in my script is:
> >>> elDetector =
> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
> >>> elDetector =
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>>
> >>> In Java it would typically look something like:
> >>>
> >>> ElevationDetector detector = new ElevationDetector(topo)
> >>> .withConstantElevation(x)
> >>> .withHandler(new
> ContinueOnEvent<ElevationDetector>());
> >>>
> >>> 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:
> >>>
> >>> " elDetector =
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>> AttributeError: 'str' object has no attribute 'wrapfn_' "
> >>>
> >>> 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 the
> execution could seem to affect the result.
> >>>
> >>> Any comments highly appriciated...
> >>>
> >>> Best Regards
> >>> /Petrus
> >
>
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
