Community
Participate
Working Groups
Build ID: I20070625-1500 Hi all, I've got a C application compiled with MinGW on a winXP PC that does not have a GUI. It instead works with text based user interaction in a shell. If I debug the C application by starting it with "Debug As - Local C/C++ Application", I'm not able to interact with the application. Started outside Eclipse the application runs without problems. I further investigated the problem with following code: #include <stdio.h> #include <stdlib.h> int main(void) { printf("Test"); char t = getchar(); printf("%c\n", t); return EXIT_SUCCESS; } and find out that in the Eclipse console it is possible to give answers to getChar(), but the whoule outpout of printf appears when the application quit. The sequence of input output on the console is hence: A TestA Furthermore, If I try to stop(kill) the application from Eclipse an error message "Terminate failed" appears and both the gdb.exe and the application remains alive. It is the possible to kill gdb from the Widows Task Manager, but it is not possible to kill the application. A reboot of the computer is required to stop the application. I Tryed to switch some versions of GDB: - GDB 6.6 (adviced in the CDT DOC) - GDB 6.3-2 - GDB 5.2.1-1 but nothing changes. I tryed to change in the Debugger Types preference page from MinGWGDBDebugger to GDBDebugger. But nothing changes. I then switched to CygwinGDBDebugger (Remark: I have no Cygwin GDB installed and hence the GDB on the path is still the MinGW one) and instead of interaction through console the application starts in an external shell -> it is possible to debug it!!! I Searched for a way to show the external shell, instead of interaction through console, with the MinGWGDBDebugger too, but was not able to undestand how. I then started debugging, but with GDB 6.6 and GDB 6.3-2 my PThreads multithreaded application does not stops at breakpoints in threads. Just the GDB 5.2.1-1 version works but there's the furter list of strange behaviours using the debugger inside Eclipse: - Some times, some breakpoints are skipped, most of the situations arise when resuming the application from a previous breakpoint. - Some times, If I just step over an instruction, the whole application runs to completion as if instead a step over a whole resume where done. - If I step over an instruction with an internal breakpoint, the breakpoint is ignored. - When resuming execution the debugger sometimes stops where there is no breakpoint. - During code stepping, the debugger sometimes performs 2 or 3 steps, then a the further stpep over it gets back (rewind) and it is necessary to step them again. - During code stepping, the debugger sometimes shows lines of code that should not execute, I tested this last with a situation similar to the following one: switch(a) case 1: printf(1) break; case 2: printf(2) break; If a=1 the output on the shell is 1 (as it should be), but the debugger steps into case2 too, like if there where no break at the end of case1. During debugging I further always have strange messages in the Eclipse console like: Warning: E:\Eclipse-Workspaces\Workspace\Test_c/E: No such file or directory. I know that GDB integration for CygWin should be better, but I'm not able to switch there because I use some libraries compiled for Win. Is there a way to use CygWin GDB even with MinGW compiled application (or something similar)? Hope all this could help debugging the GDB integration and hope that someone is able to help me.
Sorry, has to rise this to blocker, but we found no consistent way to use gdb(MinGW) in current version of CDT and this bug is hence a show stopper for us.
I change this again from blocker to major. I had an answer in the forum and with following settings: > Open Debug Config and set > Debugger/Debugger: gdb/mi > Debugger/GDB command set: Standard I'm finally able to run GDB 5.2.1-1 It is important to note that it is necessary to use "Standard" and not "Standard(Windows)" which is the default for gdb/mi. I need now to make some more tests and try to use other versions of GDB. If I found some more issues, I'll add them to this Bug. Using the proposed solution leave following issues open: "gdb/mi" is not the default debugger for MinGW (the whole thing about debugger types is quiet difficult to understand) "Standard" is not the default command set and hence it is not possible to launch the debugger directly from the C/C++ Projects Explorer because it is necessary to change the Debug Configuration (I found no preference to set it as a default). If someone hase some more information, please let me know.
I'll take a look at this. I may have more questions to better understand the problem (or it'll be painfully obvious when I get there...)
*** Bug 173733 has been marked as a duplicate of this bug. ***
To start, I'm going to focus this bug on the first issue you ran into, i.e. the poor I/O with console apps with MinGW. If you'd like the other bugs addressed, please raise separate bug report on them. The root cause of the I/O problem is that we're using Windows pipes to communicate with the underlying process. The pipes are buffered and I haven't found a way to do them unbuffered. So you don't see your text until the buffer is full or the flush() routine is called. For input, the Console does capture the text and send it to the process when you hit a new-line. Now with Cygwin, we ask gdb to create a new console that can handle the I/O. It prints text correctly. But it still buffers the input until a new line is hit. We *can not* use the console with MinGW, since the console kills our attempts at interrupting gdb to do things like set breakpoints and terminate while the app is running. That's the main reason we got rid of that console window for MinGW in CDT 4.0. So until we can find a solution that properly deals with the text out put, I can only recommend you flush() when you want to see the text come out right away. If you want to respond to key presses, then you should be writing a proper Windows application. There aren't too many console applications for Windows where the keyboard handling is archaic. If you need console functionality then I recommend using cygwin. You can still call Windows calls with it and even compile without the cygwin DLL with -mnocygwin. But the cygwin version of gdb will give you the console. And, BTW, don't use the Cygwin setting with MinGW, that's why you're getting weird messages from gdb. They are different. At any rate, I apologize, but I'm moving this off the 4.0.1 list since I won't be able to resolve this before then. I'd accept any suggestion (i.e. patches) that can make this work properly.
Hi Doug, First of all, many thanks for your answer and sorry for the delay of the reply. Before I rise some more bugs by splitting this one, I'd like to ask you if it is possible to have some information about the GDB integration and in particular the integration of MinGW GDB. I'm not an expert, I'd like to partecipate in a deeper way to your project, but it is outside the scope of the Job I'm payed for and the only chance I have to help you is hence to report bugs and ask for feedback. Furthermore this bug is a problem for us because it is difficult to find the right way to test it and hence report accurate bugs to bugzilla. Here my list of questions as a way to make the situation easier to understand: 1) Which version of MinGW GDB is better to use together with CDT? 2) Which is the meaning of all debugger types available in the "debugger types" preference page of CDT? Why is there a generic "GDB Debugger" type together with specific debugger types? 3) Related to heach debugger type, which is the meaning of available debugger options under the Debug Configuration (e.g. "Protocol" which can be of type "Default, mi1, mi2 ,mi3, ..." or "GDB commmand set")? 4) What is the meaning of "Verbose console Mode"? 5) Together with MinGW is the "MinGW GDB" debugger type the only one that has to be used? Is gdb/mi an alternative or not? 6) You wrote that "... with Cygwin, we ask gdb to create a new console that can handle the I/O ...". Is the console you are talking about, the external console that starts when debugging with "Cygwin GDB" as a debugger type? Is it hence not possible to work with such an external console for MinGW too? 7) What do you mean with "If you want to respond to key presses, then you should be writing a proper Windows application". Do you mean that we have to put a Graphical User Interface on top of our application? If we will use such a GUI, will then MinGW GDB work correctly in CDT? Sorry for this confirmation question, but I'd like to be sure that the whole problem with GDB is related to the fact that we use the console for input and output. If I have to start development for GUI suport, I'd like to be sure that it will solve the MinGW GDB related problem. Most of my fear is related to the following problem I reported in the Bug tracking: "Furthermore, If I try to stop(kill) the application from Eclipse an error message "Terminate failed" appears and both the gdb.exe and the application remains alive. It is then possible to kill gdb from the Widows Task Manager, but it is not possible to kill the application. A reboot of the computer is required to stop the application." Finally, regarding the option to flush the console, I tryed it, but I had some further problems and hence is a non working solution for us. If you are interested there's a discussion in the CDT Newsgroup under Debugging MinGW Applications. I'll soon try to use Cygwin as an alternative, we already considered Cygwin as an alternative to compilation and Debugging, but there were some important issues related with the installation process that forced us to use MinGW. I'll do the whole analysis once more to see if there's a possible solution path there (even if I still prefer the possible solution of MinGW with a GUI on top of our application). Many Thanks Tiz
(In reply to comment #6) > Here my list of questions as a way to make the situation easier to understand: > 1) Which version of MinGW GDB is better to use together with CDT? Everything I do for the MinGW integration with the CDT is for the Wascana project (http://wascana.sourceforge.net). The version of gdb I'm using there is the latest 6.6. > 2) Which is the meaning of all debugger types available in the "debugger types" > preference page of CDT? Why is there a generic "GDB Debugger" type together > with specific debugger types? Some of that is historical. There is an older gdb integration implementation and the new one called gdb/mi. Additional types are available to support different versions of gdb that have different behavior. For MinGW gdb, the correct one to use is the MinGW debugger. > 3) Related to heach debugger type, which is the meaning of available debugger > options under the Debug Configuration (e.g. "Protocol" which can be of type > "Default, mi1, mi2 ,mi3, ..." or "GDB commmand set")? The command set is actually a new way of specifying the gdb integration. The command set is directly at the MI level where there are different commands for different gdb versions. The protocol was one attempt gdb made to version the MI protocol so we support that to. It is one big confusing mess. For GDB, though, the default should work fine. > 4) What is the meaning of "Verbose console Mode"? This just shows the MI commands and responses between the CDT and gdb in the debug console. > 5) Together with MinGW is the "MinGW GDB" debugger type the only one that has > to be used? Is gdb/mi an alternative or not? Yes. There are some commands specific to MinGW that we use that you only get with the MinGW debugger type. Don't use gdb/mi. It's more for Linux. > 6) You wrote that "... with Cygwin, we ask gdb to create a new console that can > handle the I/O ...". Is the console you are talking about, the external console > that starts when debugging with "Cygwin GDB" as a debugger type? Is it hence > not possible to work with such an external console for MinGW too? Yes. And yes, we can't do that with MinGW. Cygwin has some special code that handles Unix style signalling. That code is in the cygwin1.dll that every cygwin process loads. We use that to suspend cygwin's gdb. MinGW does not have that since it's native Windows. We use the native Windows console commands to suspend gdb. The external console prevents that from working. > 7) What do you mean with "If you want to respond to key presses, then you > should be writing a proper Windows application". Do you mean that we have to > put a Graphical User Interface on top of our application? If we will use such a > GUI, will then MinGW GDB work correctly in CDT? Yes. Windows is horrible at regular console applications. I have very rarely seen a pure Windows native console application. Almost all applications implement some sort of GUI, no matter how simple. MinGW is designed for native Windows applications and fall into this category. If you want to create a console application for Windows that requires tight interaction with the user, then I recommend Cygwin for that. The guys on the Cygwin project have worked hard to implement proper console handling for Windows by emulating Linux as much as possible. Hope this helps.
Yes this Helps! Many thanks. wascana is cool! we built something similar for our project. We will probably jump to wascana as soon as possible. If it makes common sense and if there will be some specific need, is it possible to make contributions to wascana?
(In reply to comment #8) > is it possible to make contributions to wascana? Of course. It's as open source as the CDT is (maybe even more since we don't have the same licensing restrictions as Eclipse does). Can you summarize the remaining issues for this bug so that we know where to start off next. Thanks.
Hi Doug, we are currently further investigating our problem related to MinGW and GDB, but we first need to develop a GUI on top of our application before further considerations could be done. All other strange behaviours I reported in my first post are probably related to fact that we were using "Cygwin GDB" as a debugger type together with MinGW GDB and MinGW compiled code (in order to have a shell available). You told me that this kind of approach may lead to unexpected behaviours. As soon as a GUI will be available, I'll try to debug our application once more to see if the behaviour is more predictable with "MinGW GDB" as a debugger type. If I made no further misunderstandings, there's only one concrete problem related to our need for a shell to interact with the debugged application, and the fact that this functionality is not available with MinGW. All other problems should be a consequence of this one and our attempt to work-it-around. Just a further quastion: if all other debugger types are not suited for MinGW GDB, why not to force MinGW compiled applications to just "MinGW GDB" debugger type? I'll let you know as soon as possible. many thanks Tiz
(In reply to comment #10) > If I made no further misunderstandings, there's only one concrete problem > related to our need for a shell to interact with the debugged application, and > the fact that this functionality is not available with MinGW. All other > problems should be a consequence of this one and our attempt to work-it-around. O.K. I'll leave this bug open to address that and adjust the title to match. It's a complex problem mainly due to the architecture of Windows and gdb. But hopefully we can figure out something. > Just a further quastion: if all other debugger types are not suited for MinGW > GDB, why not to force MinGW compiled applications to just "MinGW GDB" debugger > type? We have a lot of issues in the whole launcher space that we need to address. Your experience is a great example of how complicated the whole thing is. We will be looking at that for the next CDT release. In the short term, I did manage to get the MinGW debugger set automatically if the project used the MinGW toolchain. The hope is that no one changes it after the launch configuration is created :). Thanks! Doug.
My MinGW GDB problem with CDT 4.0.2 and Eclipse 3.3.1.1 is similar but much simpler. The ToolChain properties supports setting of the GCC tools but not the GDB or Make tools. Unless I have cygwin/bin on the system path to rescue MinGW, use of MinGW 'make' gives a confusing cannot find file, and use of MinGW 'gdb' gives a confusing launcher error. [A novice is further hampered by MinGW not incorporating its gdb as standard.]
Considering stdout flushing, which is a problem which has been discussed a bit here but is not, AFAIU, the core of this bug report, please see bug number 173732 and my comment there. Doug, if you could read and comment it there I'd be glad! Thanks.
Sounds similar to bug 102043.
Is it possible something else has a lock on the stdout which doesn't get released until a flush type operation? Maybe if when building the output gets ahold of something and doesn't release it? Are there any tools within Eclipse that can show open files? Does this problem exists in Ganymede releases?
Returning old defects to pool so I can have an accurate list of what I'm working on.
Hi, I think the refactoring of the debugging console window is a big issue (e.g. switching from buffered pipe to line buffered or unbuffered streams). So I suggest to implement a switch in eclipse to open a extra console. At least for Windows it should be easy to implement, because all you need is to send the command set new-console on to gdb. I added this command to .gdbinit and it works for me, but I always have to modify my "debug configuration" in every project. Of course for the other platforms like linux it would be nice, too. Unfortunately there AFAIK gdb cannot create an extra terminal, but only attach to an existing one. So it is possible, but a little bit more complicated. Just my 2ct Walter
Created attachment 198087 [details] Test case for MinGW GDB console problems
(In reply to comment #17) > At least for Windows it should be easy to implement, because all you need is to > send the command > set new-console on > to gdb. > I added this command to .gdbinit and it works for me, but I always have to > modify my "debug configuration" in every project. I fully agree with Zuc, the current way CDT handles the MinGW console under Windows is horrible. I will add a few of my observations so please let me know if you want me to create separate bug reports for them. Since they are all solved by using "set new-console on" I decided to report them here. Environment: Windows XP SP3, eclipse-SDK-3.7M7-win32.zip + cdt-master-8.0.0-I201106151055, mingw-get-inst-20110530 (installed today) Take the attached test case and place breakpoint where specified. I noticed two wrong behaviors: When "Stop at main" is not activated, the application will quit immediately. This is probably because it interprets the GDB commands as console inputs even without user interaction. Basically this seems to be a race condition between GDB controlling and application launching. Also when debugging the project and when it should be halting in the "work thread", CDT fails to detect the correct thread and does not stop. It is then impossible to further debug because you cannot resume the thread. Both issues go away if I open a separate console by putting "set new-console on" into .gdbinit. On a related note, does anyone know how to keep the new console open after the program has terminated?
(In reply to comment #19) > On a related note, does anyone know how to keep the new console open after the > program has terminated? I didn't try (I don't have a Windows machine) but you may be able to do this by keeping GDB alive after the program terminates. To do this: - Preferences->C/C++->Debug->GDB - uncheck: "Terminate GDB when last process exits"
(In reply to comment #20) > (In reply to comment #19) > > > On a related note, does anyone know how to keep the new console open after the > > program has terminated? > > I didn't try (I don't have a Windows machine) but you may be able to do this by > keeping GDB alive after the program terminates. To do this: > - Preferences->C/C++->Debug->GDB > - uncheck: "Terminate GDB when last process exits" I tried that, unfortunately it doesn't help, the console window closes anyway...
