trouble setting breakpoints in my jni code with ddd/gdb
Hello, I am in the process of porting a JNI dynamic library to Unix that was developed on wiindows. I have made some errors and would like to debug but am having some troubles using ddd and gdb. The following snippets are from the stderr stream when I run without the debugger and just crash. I get this signal: SIGTRAP 5* trace trap stackpointer=0xb17c I am using: Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, native threads): The main thread stack trace looks like "main" (TID:0x404d41e0, sys_thread_t:0x804c238, state:R, native ID:0x400) prio=5 at fp.platformInterface.EFoo.nInitialize(Native Method) at fp.platformInterface.EFoo.Initialize(Compiled Code) at fp.platformInterface.EFoo.(Compiled Code) at fp.app.MaintApp.main(Compiled Code) This tells me that the dynamic lib was loaded, but that it died in nInitialize(), a method of my JNI lib. This is where I woul like to start debugging. How do I set the breakpoint in the dynamic lib (loaded from EFoo's static initializer block)? The problem I am suffering with is that the file to debug is the java executable. I can set break points in java but I can't seem to get the dynamic library loaded so as to set the breakpoint in the jni lib. Trying gdb command add-symbol-file ./lib/libEFoo.so produces "Don't know how to get text start location for this file" message. I tried to load before "run" and after the "run" command (stopped on breakpoint in java's main) was executed. Same result either way. I have also tried "add-shared-symbol-file" gdb command but the answer back from gdb is that this command is not supported. Using ddd's "open program" menu item allows me to load the jni lib so I can see the symbols and set a break point but changes the target to the lib. Could anyone help guide this tired newbie through this sticking point? Or am I missing the big picture and this is not my problem? Any help would be much appreciated. Thanks for reading this far, Rich Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: trouble setting breakpoints in my jni code with ddd/gdb
On Thu, 30 Dec 1999, Nathan Meyers wrote: > richard johnson wrote: > > > > Hello, > > > > I am in the process of porting a JNI dynamic library to > > Unix that was developed on wiindows. I have made > > some errors and would like to debug but am having > > some troubles using ddd and gdb. > > JNI debugging is a bit tricky, because of the need to set a breakpoint > in code that isn't loaded until after you've been running a while. You > might want to look at > http://www.mail-archive.com/[email protected]/msg10450.html > for an earlier discussion about how to do it. This isn't the only > solution, and it isn't always the best one, but it often works. > Nathan, I want to thank you for your help with the debugging of the my unloaded native lib. The use of the LD_PRELOAD allowed me to set the breakpoint in my native library (after as you suggested, setting the breakpoint in main() and stopping there). I bought your book too! Unfortunately, I am not reaching this breakpoint instead dying during jvm initialization trying to create the SIGQUIT handler. I get the following message in the gdb window of my ddd debugger session: Program received signal ?, Unknown signal. 0x4012eb6e in __sigsuspend (set=0xb2a8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 48 ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory. The call stack looks like this: in __sigsuspend ... at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 in __pthread_create_2_1 ...at restart.h:32 in sysThreadCreate ...at ../../../../../src/linux/hpi/native_threads/src/threads_md.c:403 in threadCreate ... at ../../../../src/share/javavm/runtime/threads.c:167 in createSystemThread "SIGQUIT handler" ...at ../../../../src/share/javavm/runtime/threads.c:506 in InitializeSignals ...at ../../../../src/linux/javavm/runtime/signals_md.c:548 in InitializeJavaVM ...at ../../../../src/linux/javavm/runtime/javai.c:847 in JNI_CreateJavaVM ...at ../../../../../src/share/javavm/runtime/jni.c:3263 in InitializeJVM ...at ../../../../../src/share/bin/java.c:467 in main ...at ../../../../../src/share/bin/java.c:173 It looks like I am missing some file or have a bad path somewhere that causes the "SIGQUIT handler" to abort. Does anyone know what file or directory is being sought? What do I do next? Should I install the debug version? Is there documentation available that describe the jvm initialization? I am using SuSE 6.2 (glibc2.1), blackdown jdk1.2 pre release v2` TIA Rich Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: trouble setting breakpoints in my jni code with ddd/gdb
On Mon, 03 Jan 2000, you wrote: > richard johnson wrote: > > > > Program received signal ?, Unknown signal. > > 0x4012eb6e in __sigsuspend (set=0xb2a8) at >../sysdeps/unix/sysv/linux/sigsuspend.c:48 > > 48 ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory. > > The "no such file or directory" just means that gdb can't find the > source file in order to display source lines. The real problem here is > the unknown signal, which I don't know how to address. Does it only die > this early when running under the debugger? Yes. It appears to only die this early when the debugger is in use. What do you make of the line in the stack trace in sysThreadCreate ...at ../../../../../src/linux/hpi/native_threads/src/threads_md.c:403 I noticed that this is a native threads method, yet I was running green threads when this happened. Does green threads have native threads for the threads beside main (SIGQUIT and ?)? > > Have you tried the Blackdown or Inprise JDK1.2.2 - those will give you > two additional sample points. > First, I am going to re-check my installation to see if I have the right version of the jdk 1.2 pre2 installed. If this checks, I plan to install the debug addendum for 1.2 and see if there is more information about what is happening by running/studying the debug vm. My next attempt will be with the 1.2.2 from Inprise as it will not require a new glib version ... as I recollect. Installing a new glib is somewhat messy from what I have read. Then I might upgrade my kernel to SuSE 6.3 which I believe has the appropriate glibc for Blackdown 1.2.2. If I come up with something I'll post the list so that maybe someone else won't go through this. Thanks again for your help. Rich > > > I want to thank you for your help with the debugging of the my > > unloaded native lib. The use of the LD_PRELOAD allowed me > > to set the breakpoint in my native library (after as you suggested, > > setting the breakpoint in main() and stopping there). I bought > > your book too! > > > > Unfortunately, I am not reaching this breakpoint instead dying > > during jvm initialization trying to create the SIGQUIT handler. I get the >following > > message in the gdb window of my ddd debugger session: > > > > Program received signal ?, Unknown signal. > > 0x4012eb6e in __sigsuspend (set=0xb2a8) at >../sysdeps/unix/sysv/linux/sigsuspend.c:48 > > 48 ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory. > > > > The call stack looks like this: > > > > in __sigsuspend ... at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 > > in __pthread_create_2_1 ...at restart.h:32 > > in sysThreadCreate ...at >../../../../../src/linux/hpi/native_threads/src/threads_md.c:403 > > in threadCreate ... at ../../../../src/share/javavm/runtime/threads.c:167 > > in createSystemThread "SIGQUIT handler" ...at >../../../../src/share/javavm/runtime/threads.c:506 > > in InitializeSignals ...at ../../../../src/linux/javavm/runtime/signals_md.c:548 > > in InitializeJavaVM ...at ../../../../src/linux/javavm/runtime/javai.c:847 > > in JNI_CreateJavaVM ...at ../../../../../src/share/javavm/runtime/jni.c:3263 > > in InitializeJVM ...at ../../../../../src/share/bin/java.c:467 > > in main ...at ../../../../../src/share/bin/java.c:173 > > > > It looks like I am missing some file or have a bad path somewhere that causes the > > "SIGQUIT handler" to abort. Does anyone know what file or directory is being > > sought? What do I do next? Should I install the debug version? Is there >documentation > > available that describe the jvm initialization? > > > > I am using SuSE 6.2 (glibc2.1), blackdown jdk1.2 pre release v2` > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: heap space and performance
On Thu, 06 Jan 2000, Juergen Kreileder wrote: > You should update your glibc first, the LinuxThreads library is still > work in progress. E.g. the original glibc-2.1.2 release didn't pass > sigcontext to user handlers, this was fixed in glibc-2.1.2 CVS tree as > of 1999/10/24 (this is the version Debian potato uses). glibc-2.1.3 > will fix another bunch of thread problems. > Juergen, In your opinion, is there a combination of glibc, jdk, and gdb stable enough to debug my native library? I am getting spurious "Program received signal ?, Unknown signal." in my ddd session's gdb window shortly after the formation of the three jvm threads. That is, I am not getting to the meat of my problem. The debug session becomes unusable before I make my first call to the native lib. A more detailed account of what I have been trying is found at the end of this message. It is a post I have made to the SuSE suse-linux-e thread. I am pretty new to linux devlopment and I know that some of my problems are no doubt self inflicted, but it strikes me that you must face this tool compatibility thing every day trying to put out the new jdk builds. What combination of lib, tool, jdk and os versions would you recommend? Thanks in advance, Richard Johnson ** A more detailed account of my problem: I am trying to debug a dynamic native library I have ported from windows that is used with java 1.2. Unfortunately, I am experiencing "Program received signal ?, Unknown signal" while trying to create one of the threads in the java vm. Searching with google and a search string of "unknown signal gdb linux threads" produces a number of posts that describe this problem exactly. For example, http://www.uwsg.indiana.edu/hypermail/linux/kernel/9909.0/0497.html is a post of this problem and solution by a SuSE 6.2 user posted to the linux-kernel list in early September 1999. It suggests rolling back to gdb-4.17.0.11. There IS a version of 4.17.0.12 on my 6.2 distribution and unfortunately, when i use it, I still get this "unknown signal ?" problem when I use it. It does appear that the linux thread patches have been made to this version, as I see output in the ddd's gdb window announcing the new threads as they are created: Continuing. [New Thread 2906] [New Thread 2905] [New Thread 2907] Unfrontunately for me, this is followed by: Program received signal ?, Unknown signal. [Switching to Thread 2907] Program received signal ?, Unknown signal. 0x4011cb6e in __sigsuspend (set=0xbf7ffc74) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 ../sysdeps/unix/sysv/linux/sigsuspend.c:48: No such file or directory. Trying to continue with a "signal 0" or continue just hangs the ddd/gdb session. I am going to try the .11 version. I think I have it on the 6.1 cdrom. But I guess the question is, shouldn't the .12 version on the 6.2 cd work? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
