I'm encountering a rather serious problem using the jni with Blackdown-1.3.0-FCS (kernel 2.2.14, SuSE 6.4) . The problem is actually causing problems in my system as a whole. I suspect it has to do with memory allocation , and it would help to have some information about how memory for jni is allocated. I'd very much appreciate hearing from someone who knows about these matters. I've been using jni calls to C functions (which use malloc/free) for several months without problems. However, I just added another one and it's wreaking havoc. I'm fairly certain that the problem is not the function itself. When I call it from a test simple test program, is seems fine. I can run it on a loop (changing the data passed to it) for hundreds of thousands of iterations without problems. However, when I call it from a larger Java program, all kinds of things get corrupted (the larger Java program without this jni call can run for hours without problems). If I run it from an Xterminal under X, it causes X to crash. If I don't have X running at all (the larger java program doesn't need it), getty gets interfered with and I can't login under through virtual terminals. I assume that memory is being corrupted. A few questions: - Where does the memory for a jni called function come from? Is, is space allocated in the JVM heap (or stack)? - When a jni invoked function makes a malloc call, is memory allocated from the JVM's memory, or directly from the operating system? - What is the default stack size for the jvm? I've tried making this larger (no effect), but have no idea what would be a 'large' amount of memory for the stack. - Is there anyway to get a core dump when a problem like this occurs? Unfortuntely, I haven't been able to generate an isolated case of the problem, which makes debugging difficult. So any comments or suggestions would be appreciated. Thanks, Barnet Wagman ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]