Resolution:
GDB can be used to debug native code in CPPDriver or JNI in Linux. Also, GDB can be useful in identifying unusual problems with the Linux JVM. However, there are some subtle issues when trying to use GDB on a JVM, as is the case with the GridServer Engine.

First, when attaching GDB to the Engine, you must specify the LD_LIBRARY_PATH to both the Engine components and the JVM components. You must also obtain the process ID of a running invoke (or invokeGCC3) process from the ps command. It's also easier if you run GDB from the base directory of the Engine install (typically DSEngine) . The GDB command used is similar to this:

LD_LIBRARY_PATH=lib:jre/lib/i386:jre/lib/i386/native_threads:jre/lib/i386/server:resources/linux/lib

gdb bin/invoke $INVOKEPID

bin/invoke should be replaced with bin/invokeGCC3 when using GCC3.

This method of running GDB works well for troubleshooting rare JVM problems. However when you are troubleshooting CPPDriver code, a different method should be used. The issue is that CPPDriver loads your application shared objects only when the Tasklet or Service is instantiated, so it becomes difficult to set a breakpoint in the application shared object. Further, attaching GDB to a running JVM often has undesired side effects, including halting the JVM depending on the versions of JVM, pthreads, and GDB being used.

The following procedure details how to use GDB with CPPDriver code:

   1. Create a GDB initialization file with two commands, one to set the breakpoint and the other to continue - if you take the time to set the breakpoint manually, you risk exceeding some timeouts which will cause the Engine instance to exit. For example, create a file called yourtest.gdb containing the following:

      break YourTest.cpp:42

      cont

   2. Have your Service client call a no-op or initialization method to get the service library (.so) loaded. You can call any Service method that doesn't affect the code being debugged. For instance, you could call a method that retrieves the version of the library being debugged, like getVersion(). If such a method doesn't exist, you can add something similar to your Service.
   3. Attach GDB to the process using the initialization file created in the first step above:

      gdb -x yourtest.gdb bin/invoke $ENGINEPID

   4. Run the client code used to call the Service method you want to debug.

Attaching GDB to Engine native code on Linux