Andi, great to hear that you could reproduce it. I'm very thankful if you could have a look at it, I've been struggling to understand how the machinery behind this works, but far from it still..
Best Regards /Petrus On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <[email protected]> wrote: > > On Sun, 29 Dec 2013, Petrus Hyvönen wrote: > > 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 :) >> > > I've been able to reproduce the problem. > Thank you for providing an isolated test case ! > > Andi.. > > > >> best Regards >> /Petrus >> >> >> >> >> >> >> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <[email protected]> wrote: >> >> >>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <[email protected]> >>>> >>> 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 <[email protected]> wrote: >>>>> >>>>> >>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <[email protected]> >>>>>>> >>>>>> 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 <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <[email protected] >>>>>>>> > >>>>>>>> >>>>>>> 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 >> > -- _____________________________________________ Petrus Hyvönen, Uppsala, Sweden Mobile Phone/SMS:+46 73 803 19 00
