tachyon-II has asked for the wisdom of the Perl Monks concerning the following question:

Using Inline::Java and the JVM everything is fine. If JNI is invoked then it works, but on exit segfaults tyring to invalidate a non existant pointer.

Anyone got a pointer to how to avoid/fix this?

[root@w32 JNI]# cat Hello.java JNICrash.pm jni.pl public class Hello { String Message; public Hello( String Message ) { this.Message = Message; } public int speak() { System.out.println( this.Message ); return 0; } } package JNICrash; use strict; use warnings; BEGIN { $ENV{CLASSPATH} = '.'; $ENV{PERL_INLINE_JAVA_JNI} = 1; #$ENV{LD_PRELOAD} = "/lib/i686/nosegneg/libpthread.so.0"; #$ENV{LD_LIBRARY_PATH} = "/usr/java/jdk1.7.0/jre/lib/i386/server:/us +r/java/jdk1.7.0/jre/lib/i386/jli:/usr/java/jdk1.7.0/jre/lib/i386"; }; sub CrashNBurn { my ($msg) = @_; use Inline ( Java => 'STUDY', STUDY => [ 'Hello' ], DEBUG => 1, #5, DIRECTORY => '/tmp/', PACKAGE => 'main', ); my $java = new Hello( $msg ); $java->speak(); #undef $java; } 1; #!/bin/env perl use strict; use lib '.'; use JNICrash; JNICrash::CrashNBurn( "Hello, world!" );

Which runs fine when $ENV{PERL_INLINE_JAVA_JNI} = 0 but produces this when PERL_INLINE_JAVA_JNI = 1

[root@w32 JNI]# ./jni.pl [perl][1] validate done. [perl][1] Starting load. [perl][1] starting JVM... [perl][1] JNI mode [perl][1] using jdat cache [perl][1] load done. [java][1] loading InlineJavaUserClassLink via InlineJavaUserClassLoade +r Hello, world! [perl][1] killed by natural death. [perl][1] JVM owner exiting... [perl][1] exiting with 0 *** glibc detected *** perl: munmap_chunk(): invalid pointer: 0x00c044 +6c *** ======= Backtrace: ========= /lib/libc.so.6[0xa10e31] perl(Perl_safesysfree+0x21)[0x80cde41] perl(perl_destruct+0x200)[0x807a690] perl(main+0xf3)[0x805fff3] /lib/libc.so.6(__libc_start_main+0xe6)[0x9b6d26] perl[0x805fe61] ======= Memory map: ======== [snip]

This happens on CentOS 5 & 6 with versions of Perl 5.10, 5,12, 5,18. Inline is 0.53

Replies are listed 'Best First'.
Re: Inline::Java JNI Crashing
by syphilis (Archbishop) on Jul 19, 2014 at 14:20 UTC
    If the Inline::Java author can't help you out with this, then it's likely that no-one can.
    That doesn't mean that there's no-one here who can help you ... but if you don't get help here, then try to contact him.

    Unfortunately, I can't even offer good advice on how to get hold of the author.
    He used to be subscribed to the Inline mailing list (which you can find via http::/lists.cpan.org, should it ever come back to life) but I can't even guarantee that he's *still* subscribed there.

    I've a vague notion that this issue has been raised previously on the Inline mailing list - so you might also be able to find the solution by perusing the archives of that list. (Search for posts from Patrick LeBoutillier.)
    Again, I can't even provide a link to those archives - and won't be able to do so while lists.cpan.org is not reachable.

    Update: Fixed above link (thanks soonix). Inline mailing list archive is at http://www.mail-archive.com/inline@perl.org/

    Cheers,
    Rob
Re: Inline::Java JNI Crashing
by BrowserUk (Patriarch) on Jul 19, 2014 at 15:37 UTC
    Anyone got a pointer to how to avoid/fix this?

    Depends when the error is occurring.

    If you get back to the main program after calling CrashNBurn, then it must be happening during global cleanup, which you can bypass by calling POSIX::exit().

    It's a bit crude, but as you're exiting anyway ...


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Inline::Java JNI Crashing
by basiliscos (Pilgrim) on Jul 20, 2014 at 10:17 UTC
    ======= Backtrace: =========
    /lib/libc.so.60xa10e31
    perl(Perl_safesysfree+0x21)0x80cde41
    

    I may guess that the problem is located in JVM termination. May be just keep $java reference somewhere?

    While this does not solves the problem, I may suppose, that some wrong pattern is been used: launching everytime new JVM instance, could lead to huge overheads.