SIGSEGV error using SWIG to create shared java library

To always pass the same function pointer automatically, it's pretty simple in SWIG. For example, given the header file test.h, which fixes the main part of your problem:

struct context; // only used for pointers

void init_context(struct context **ctx) { *ctx=malloc(1); printf("Init: %p\n", *ctx); }
void release_context(struct context *ctx) { printf("Delete: %p\n", ctx); free(ctx); }

void foo(struct context *ctx) { printf("foo: %p\n", ctx); }

      

        
        
        
      

    

We can wrap it up and automatically call the global context to be passed in whatever is expected by doing something like:

%module test

%{
#include "test.h"

// this code gets put in the generated C output from SWIG, but not wrapped:
static struct context *get_global_ctx() {
  static struct context *ctx = NULL;
  if (!ctx) 
    init_context(&ctx);
  return ctx;
}
%}

%typemap(in,numinputs=0) struct context *ctx "$1=get_global_ctx();"

%ignore init_context; // redundant since we call it automatically

%include "test.h"

      

        
        
        
      

    

This sets the typemap for struct context *ctx

, which, instead of typing input from Java, automatically calls get_global_ctx()

wherever it matches.

This is probably enough to create a sane-ish interface for a Java developer, but it is less ideal: it forces the context to be global and means no Java application can ever run multiple contexts at the same time.

A nicer solution, given that Java is an OO language, is to create the context as a first class object. We can also get SWIG to create such an interface for us, although it's a little confusing. Our SWIG module file becomes:

%module test

%{
#include "test.h"
%}

// These get called automatically, no need to expose:
%ignore init_context;
%ignore delete_context;

// Fake struct to convince SWIG it should be an object:
struct context {
  %extend {
    context() {
      // Constructor that gets called when this object is created from Java:
      struct context *ret = NULL;
      init_context(&ret); 
      return ret;
    }
    ~context() {
      release_context($self);
    }
  }
};

%include "test.h"

      

        
        
        
      

    

and we can successfully implement this code:

public class run {
  public static void main(String[] argv) {
    System.loadLibrary("test");
    context ctx = new context();
    // You can't count on the finalizer if it exits:
    ctx.delete();
    ctx = null;
    // System.gc() might also do the trick and in a longer
    // running app it would happen at some point probably.
  }
}

      

        
        
        
      

    

gives:

Init: 0xb66dab40
Delete: 0xb66dab40

      

        
        
        
      

    

In a dynamically typed language, which would be complex, we could use some form of meta-programming to insert member functions as needed. So we could say something kind of new context().foo();

completely as expected. Java is statically typed, so we need something more. We can do this in SWIG in several ways:

• Agree that we can call it test.foo(new context());
  
  pretty happily now - it still looks a lot like C in Java, although I would guess it might be a code smell if you end up writing a lot of Java that looks like C.

• Use %extend
  
  to (manually) add methods to the context class, %extend
  
  in test.i becomes:

  %extend {
      context() {
        // Constructor that gets called when this object is created from Java:
        struct context *ret = NULL;
        init_context(&ret); 
        return ret;
      }
      ~context() {
        release_context($self);
      }
      void foo() {
        foo($self);
      }
    }
  
        
  
          
          
          
        
  
      

• As with %extend
  
  , but write glue on the Java side using the following card:

  %typemap(javacode) struct context %{
    public void foo() {
      $module.foo(this);
    }
  %}
  
        
  
          
          
          
        
  
      

  (Note: this must be early enough in the interface file for it to work)

Note that nowhere have I shown SWIG the real definition of my context structure - it always prefers my "library" for anything where a real definition is required, so the opaque pointer remains fully opaque.

A simpler solution for wrapping with a init_context

double pointer would be to use %inline

to provide an additional function that is only used in the wrapper:

%module test

%{
#include "test.h"
%}

%inline %{
  struct context* make_context() {
    struct context *ctx;
    init_context(&ctx);
    return ctx;
  }
%}

%ignore init_context;

%include "test.h"

      

        
        
        
      

    

It is enough that we can write the following Java:

public class run {
  public static void main(String[] argv) {
    System.loadLibrary("test");
    // This object behaves exactly like an opaque pointer in C:
    SWIGTYPE_p_context ctx = test.make_context();
    test.foo(ctx);
    // Important otherwise it will leak, exactly like C
    test.release_context(ctx);
  }
}

      

        
        
        
      

    

Alternative but similar approaches include using the cpointer.i library :

%module test

%{
#include "test.h"
%}

%include <cpointer.i>

%pointer_functions(struct context *,context_ptr);

%include "test.h"

      

        
        
        
      

    

which can then be used like:

public class run {
  public static void main(String[] argv) {
    System.loadLibrary("test");
    SWIGTYPE_p_p_context ctx_ptr = test.new_context_ptr();
    test.init_context(ctx_ptr);
    SWIGTYPE_p_context ctx = test.context_ptr_value(ctx_ptr);
    // Don't leak the pointer to pointer, the thing it points at is untouched
    test.delete_context_ptr(ctx_ptr);
    test.foo(ctx);
    // Important otherwise it will leak, exactly like C
    test.release_context(ctx);
  }
}

      

        
        
        
      

    

There is also a macro pointer_class

that is a little more OO than that and might be worth using instead. The point is that you provide tools for working with opaque pointer objects that SWIG uses to represent pointers that it knows nothing about, but avoiding calls getCPtr()

that inherently undermine the type system.