| Re: [cdt-dev] Using CDT/GDB coming from VS |
That’s right the JVM would often SIGSEGV and it is my understanding it is by design to catch out of bound array exception. I also had in some cases to disable SIGSEGV but most of the time I don’t and do continue the debugging process. The SIGSEGV kick-in a few time at start-up but after that it is not too noisy (at least with my streaming app). For mixed Java/CDT application it would be a great addition to add a CDT debugging feature that can filter SIGSEGV signals that belong to the JVM or the native add-on and let only SIGSEGV from the add-on kick-in. I think this should be possible with the chained signal libsig.so shared library provided with the JVM. Regarding the struggling I really hesitate to point to a particular issue. As I said it is not an impossible task to debug mixed Java/CDT. When you come from the Visual Studio /Windows OS world I find complex debugging tasks more tedious on Linux. From time to time I run into debugging stability issue with CDT/Java mixed application within a debugging session with Eclipse. When you are into a long debug session having to restart the debug session because of a stability issue is no joy. For example 2 days ago I had to debug an issue with a streaming application. No luck the issue wouldn’t happens on Windows and I had to switch to Linux to debug. In this case the issue was a SIGSEGV exception inside openGL C++ code. In this case I had both the Java/CDT debugger attached to the app. A few time while debugging C++ code a Java breakpoint would kick-in! I would then dismiss the Java breakpoint and switch back to the C++ debugging code. The Eclipse debug view would be refreshed and oup the call stack of the debugging C++ thread wouldn’t be expanded anymore. A this point it what impossible to re-expand the C++ thread stack. Even though the debug view would clearly show that the thread is indeed paused. The issue only happened intermittently while debugging. I would say that most of the issues I have had with mixed Java/CDT app occurred when I would switch between debugging the Java code and debugging the C++ code. I always had the feeling that some internal Java/CDT state would be lost or corrupted in the debug session while going from debugging Java code to debugging C++ code. With time I learned to try to carefully avoid as much as possible debugging both Java and C++ code within the same debug session and this make the debug session a much more enjoyable experience. But something this is not always possible. Hope this help! Guy From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc-André Laperle "Sometime randomly the Java debugging context and the CDT debugger seems to be struggling against each other and you cannot progress much in your debugging." "You have to start the Java JVM application under Eclipse Java debugging context then attach the JVM process to the CDT debugger with the same Eclipse instance." About that, I created this bug to make it easier to attach in this scenario: Marc-Andre From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of guy.bonneau@xxxxxxxxxxxx [guy.bonneau@xxxxxxxxxxxx] I don't want to be misunderstood regarding the CDT debugging experience of Eclipse Debugger tool (under Linux). I don't have much experience with it. I am working with Linux OS and Java since switching job and I have been both pleasantly surprised and also in pain with the OS. I wouldn't say my debugging context is what a normal user would experiment with the CDT package. I am working with an application which is mainly Java based from a management and GUI point of view. It is a complex application using hundred of Java Jar libraries from third parties and Open source. The application uses databases and has near a thousand threads. Below this Java code there is a pure streaming C/C++ real-time software doing media processing and decoding and doing communication through JNI interface. There is also proprietary code written in SIMD assembly and we are using Intel IPP library and IPP samples which itself is written is some case with pure assembly. Imaging injecting corrupted data (purposely) to simulate a customer instable media reception into this environment and experimenting a crash deep in the IPP SIMD assembly code written by Intel. Imagine this code having stolen the EBP register that is used to walk the stack calling context of the C++ code which confuses the debugger! Well this is my debugging context. Under Linux trying to debug this kind of issue with Eclipse Java/CDT is not an easy task. You have to start the Java JVM application under Eclipse Java debugging context then attach the JVM process to the CDT debugger with the same Eclipse instance. Debugging in this context with stability under Linux is possible yet incredibly difficult and in some cases you run into unknown issues that left you puzzled. Sometime randomly the Java debugging context and the CDT debugger seems to be struggling against each other and you cannot progress much in your debugging. Under Windows debugging the same context issue is still difficult yet a lot less painful. You work with both the Eclipse IDE (for Java) and Visual Studio for C++. And both IDE seems to be at joy with each other. I don't remember having had any stability issues while debugging both the C/C++ and Java code into the same process under Windows. It is a great debugging experience under Windows. You also have great CRT debugging tools available to help you with issues like memory leak that integrate almost seamlessly. (Tried Valgrind under Linux with our app without success). You have the Gflags tool that interact at both your process and OS level to provide you with a great debugging context experience with complex issues. And I would say in some cases the assembly integration of VS with C++ is a much smoother experience when going into the compiler assembly code. So although our final deployment is Linux OS based all our debugging context uses Windows and its debugging tools. I am well aware that this wouldn't be possible if the application wouldn't live inside a JVM. Overall I would say that the integration of all the tools you have under Windows for debugging purpose provide you with a context that let you find complex issues with mixed Java/C++ code and mixed Eclipse/Visual Studio where under Linux you would be in pain with Eclipse trying to deal with both Java/C++. It is not an issue with the CDT debugger per se. Guy Le 03/07/13, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> a écrit :
|