From: Ats V. <ats...@gm...> - 2014-01-17 09:38:38
|
Hello, I'm trying to generate Java wrappers for a c++ project and I need to mark a class as a director and as a shared_ptr at the same time, which seems to be unsupported right now. I can fix compiler errors from the generated code by using directorin and javadirectorout typemaps in my module and by changing swigCMemOwn visibility from private to protected in the generated file. Everything seems to work until it crashes with a "null upcast object" exception thrown from a completely unrelated place. I'm also having issues with some of the members of the director class getting corrupted or garbage collected. Can you give me any hints how to fix these issues? Thanks in advance, Ats |
From: Marvin G. <pub...@gm...> - 2014-01-17 14:48:39
|
Ats Vendik wrote: > Hello, I'm trying to generate Java wrappers for a c++ project and I > need to mark a class as a director and as a shared_ptr at the same > time, which seems to be unsupported right now. I can fix compiler > errors from the generated code by using directorin and javadirectorout > typemaps in my module and by changing swigCMemOwn visibility from > private to protected in the generated file. Everything seems to work > until it crashes with a "null upcast object" exception thrown from a > completely unrelated place. I'm also having issues with some of the > members of the director class getting corrupted or garbage collected. > > Can you give me any hints how to fix these issues? > If you are passing director objects in to a C++ library that holds references you have to ensure that the lifecycle of your Java implementation objects matches. If a java director implementation is garbage collected, the underlying C++ proxy will generate the null upcast message. To get more specific help from the community, you probably will need to post some example code, preferably something that simplifies the problem. You can also add print statements and debugging code in to the generated wrapper code to try to understand yourself what is going on. Marvin |
From: Ats V. <ats...@gm...> - 2014-01-18 22:05:10
|
I made public static references to all the director objects for testing purposes and the null pointer exception disappear, but it turns out it was not the only problem. The program keeps crashing at random places and times hinting some sort of heap corruption or a threading issue. I'm currently creating the java director objects in one thread and calling director's callbacks from another thread in c++, could this be a problem? Removing c++ callback calls fixes the issue so perhaps I need to add AttachCurrentThread/DetachCurrentThread around the java calls in the JNI wrapper? On Fri, Jan 17, 2014 at 4:48 PM, Marvin Greenberg <pub...@gm...> wrote: > Ats Vendik wrote: >> >> Hello, I'm trying to generate Java wrappers for a c++ project and I >> need to mark a class as a director and as a shared_ptr at the same >> time, which seems to be unsupported right now. I can fix compiler >> errors from the generated code by using directorin and javadirectorout >> typemaps in my module and by changing swigCMemOwn visibility from >> private to protected in the generated file. Everything seems to work >> until it crashes with a "null upcast object" exception thrown from a >> completely unrelated place. I'm also having issues with some of the >> members of the director class getting corrupted or garbage collected. >> >> Can you give me any hints how to fix these issues? >> > > If you are passing director objects in to a C++ library that holds > references you have to ensure that the lifecycle of your Java implementation > objects matches. If a java director implementation is garbage collected, > the underlying C++ proxy will generate the null upcast message. > > To get more specific help from the community, you probably will need to post > some example code, preferably something that simplifies the problem. You > can also add print statements and debugging code in to the generated wrapper > code to try to understand yourself what is going on. > > Marvin |
From: Ats V. <ats...@gm...> - 2014-01-20 00:18:58
|
Turns out I had used a reference instead of shared_pointer in one of my exposed interfaces, changing it to shared_ptr fixed the problem. On Sun, Jan 19, 2014 at 12:05 AM, Ats Vendik <ats...@gm...> wrote: > I made public static references to all the director objects for > testing purposes and the null pointer exception disappear, but it > turns out it was not the only problem. The program keeps crashing at > random places and times hinting some sort of heap corruption or a > threading issue. I'm currently creating the java director objects in > one thread and calling director's callbacks from another thread in > c++, could this be a problem? Removing c++ callback calls fixes the > issue so perhaps I need to add AttachCurrentThread/DetachCurrentThread > around the java calls in the JNI wrapper? > > On Fri, Jan 17, 2014 at 4:48 PM, Marvin Greenberg > <pub...@gm...> wrote: >> Ats Vendik wrote: >>> >>> Hello, I'm trying to generate Java wrappers for a c++ project and I >>> need to mark a class as a director and as a shared_ptr at the same >>> time, which seems to be unsupported right now. I can fix compiler >>> errors from the generated code by using directorin and javadirectorout >>> typemaps in my module and by changing swigCMemOwn visibility from >>> private to protected in the generated file. Everything seems to work >>> until it crashes with a "null upcast object" exception thrown from a >>> completely unrelated place. I'm also having issues with some of the >>> members of the director class getting corrupted or garbage collected. >>> >>> Can you give me any hints how to fix these issues? >>> >> >> If you are passing director objects in to a C++ library that holds >> references you have to ensure that the lifecycle of your Java implementation >> objects matches. If a java director implementation is garbage collected, >> the underlying C++ proxy will generate the null upcast message. >> >> To get more specific help from the community, you probably will need to post >> some example code, preferably something that simplifies the problem. You >> can also add print statements and debugging code in to the generated wrapper >> code to try to understand yourself what is going on. >> >> Marvin |