Dear Andi,
I have distilled the library that I have some trouble with and I think I
have an example that is failing due to same problem I think. I am not good
in java, but have tried to follow the logic from the library I'm wrapping.
The function of the example does not make sense in itself.
public class SimpleClass<T> {
public SimpleClass() {
System.out.println("Created SimpleClass");
}
public T return_null() {
return null;
}
}
public class SimpleClass2 extends SimpleClass<Integer>{
public SimpleClass2(){}
public void testInJava(){
System.out.println(this.return_null());
}
}
It seems to me that there is some problem with methods inherited that
returns a generic type, failing in wrapType when this is to be wrapped.
The python script that fails:
a= SimpleClass()
print a.return_null()
b = SimpleClass2()
b.testInJava()
print b.return_null() #Fails in wrapType
I don't know if the return null is a bad thing to do in java, but the error
seems very similar to what I experience in the larger library. I have a
skeleton of that this is slightly larger, but not returning null, but
trying to keep the lenght of example low :)
Any comments highly appriciated :)
best Regards
/Petrus
On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>
> > On Dec 27, 2013, at 17:36, Petrus Hyvönen <petrus.hyvo...@gmail.com>
> wrote:
> >
> > 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.
>
> Right, so unless you can isolate this into something I can reproduce, I'm
> afraid there isn't much I can comment.
> It is quite likely that by the time you have that reproducible test case
> ready, you also have the solution to the problem. Or I might be able to
> help then...
>
> Andi..
>
> >
> > 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
>
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
