Re: seg fault using Linux/Alpha JDK 1.1.5 for JNI

[Eric Ding]

Hi George,

My program consists entirely of this:

 #include 

 int main(int argc, char **argv)
 {
 JDK1_1InitArgs vm_args;
 vm_args.version = 0x00010001;
 JNI_GetDefaultJavaVMInitArgs(&vm_args);
 }

This should work.  I'm compiling with the following line:

 cc -o jnitest -I/include -I/include/genunix \
   jnitest.c -L/lib/alpha/green_threads -ljava

where  is the location of the JDK on my Linux/Alpha box.

Thanks,
Eric

> Uncle George <[EMAIL PROTECTED]> writes:

> interesting the things people do. i myself have not tried what ur doing,
> but i suppose it is suppose to work. i'll have a look see. i suspect that
> it is mainly a prob trying to find where the root dir to the lib.so are,
> there is no libdl function that will do it . ( i suspect ). a hack was
> made, and it appears u got caught. u got more of main() code before
> InitArgs() ??

> i'd be curious as to how u linked - last time i tried i got link probs ( as
> i remem )

> gat

jre and libc5?

[Eric Ding]

Hi all,

are there any minimum libc5 requirements for jre 1.1.5 v7 as there are for
the JDK?  I'm getting a segmentation violation running the JRE, and wnat to
be sure it's not just cuz I've got the wrong libc.  I'm running on a RedHat
4.1 system with libc.so.5.3.12.

Thanks,
Eric

free/malloc (re)defined in libjava.so?

[Eric Ding]

Hi,

I'm working on a project (Applixware for Linux) that uses the JDK
libjava.so internally.  We've stumbled on some sort of bug that I think
has to do with free() being redefined in libjava.so (it's not, for
example, in Solaris, so we don't encounter this problem).

I'm not sure much more what's going on, except that it'd be nice if
there were a workaround such that we could make sure to be using the
correct system functions (i.e., free, malloc, etc.), or an
implementation that didn't step on system calls.  Forgive me if I'm
asking the impossible, I don't know much of libjava internals.  As a
note, on our glibc port, we see this message:

> OUCH: nested memory code, to 1 levels.

while on the libc5 port, we're more apt to see either a massive core
dump or "Trying to free bogus memory" messages.

Any help you can give would be appreciated.

Thanks,
Eric