Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Using CDT/GDB coming from VS



… signal shared library provided with  the JVM.



From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Guy Bonneau
Sent: Friday, July 12, 2013 9:57 AM
To: 'CDT General developers list.'
Subject: 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 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!






From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc-André Laperle
Sent: Wednesday, July 10, 2013 11:57 AM
To: CDT General developers list.
Subject: [cdt-dev] Using CDT/GDB coming from VS


"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."

Could you expand on that?
I had a problem with debugging Eclipse with both java and CDT debugger. It would often SIGSEGV and stop gdb. But it turns out, the SIGSEGV is expected in the jvm and I had to set gdb to ignore that signal.


"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:




From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of guy.bonneau@xxxxxxxxxxxx [guy.bonneau@xxxxxxxxxxxx]
Sent: Wednesday, July 03 2013 9:41 PM
To: CDT General developers list.
Subject: [cdt-dev] Re : Re: Re : Re: Adding a profile tool to a standard CDT toolchain

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.





Le 03/07/13, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> a écrit :

Yes, as Java programmers, we don't get to use the CDT debugger very much.  Even less get exposed to the other debuggers such VS.

It would be great to get user feedback on what is missing in the CDT debugger.

Marc-Andre had mentioned that we are missing the ability to show the return value of a method automatically.  That would be

a great feature to have.


Are there other things that an experienced VS user misses from CDT debug?







From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc-André Laperle
Sent: Wednesday, July 03, 2013 1:36 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Re : Re: Adding a profile tool to a standard CDT toolchain

Hi Guy,

That's good to hear! I find this comment intriguing: "(At least for writing code not debugging)". Are you saying that because you feel some features are missing when debugging? I'm sure the debug guys would appreciate feedback from someone coming from Visual Studio (perhaps in a new thread).


On 13-07-03 11:56 AM, guy.bonneau@xxxxxxxxxxxx wrote:



Yet I have to say that I really love Eclipse and all its capabilities and architecture...


For 25 years I have worked only with Visual Studio IDE. From 4.0 up to 2012 and C++. I couldn't believe there was a better IDE than Visual Studio or C++ language. Until I switched job and had to work with Eclipse and Java..! After 20 years with almost the same IDE I struggled a lot and couldn't find the IDE tools I wanted! It took me a year...Helped by 25 years younger developers than me to patiently bring me to a point were I was wowed by all the capabilities of Eclipse! I Learned a lot both at the coding and architecture level. And once I mastered Eclipse IDE I wouldn't want to go back with VS (At least for writing code not debugging)! I became a more proficient coder with Eclipse and really enjoyed the coding experience with it.


Since Microsoft released Visual 2012 I really hated what they did with the IDE. Thousand of developers are crying to Microsoft telling tell how they hate what they did to their beloved IDE.


So I hope that Eclipse CDT IDE will grow in architecture and coding stability. Its a great IDE. Thought that I believe much work is left to do for that they seems to be very close to bring the CDT to maturity.


Thanks guys for the great CDT plugin.


Keep the good work.





Le 03/07/13, Joseph Henry <Joseph.Henry@xxxxxxx> a écrit :

I feel your pain Guy!!

I too have struggled through the tooling mess and custom command lines just to get a few simple outputs.

It does seem like it should be much simpler to go from initial input to final output(s).

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of guy.bonneau@xxxxxxxxxxxx
Sent: Tuesday, July 02, 2013 5:33 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Adding a profile tool to a standard CDT toolchain


After much digging in the CDT code I have progressed and I am now able to have the profiler tool kick-in with the appropriate inputs type and output target. However I am left with a feeling of something unfinished regarding how the output types (Primary or secondary) can be defined and are processed up to the command step building. For example I don't see how you can really produce many outputs (primary and secondaries) from a single tool since the command line pattern have only one ${OUTPUT} dedicated to the primary output.

I have nonetheless be able to bypass this problem by custom command line generation and using option definition. However I feel it shouldn't be that hard.

To have my profiler step builder created and executed I have had to solve an issue for which I have created a bug: The calculateOutput method of build description wrongly uses the tool outputs file extension attribute to create the resource outputs of any outputType associated to the tool. This prevent the build manager to resolve the appropriate build steps.




cdt-dev mailing list


Back to the top