Community
Participate
Working Groups
When starting a local debugging session with a local Open MPI Resource Manager, the debugging session failed to start and the following error message is reported: Unable to determine gdb version Eclipse edition: Eclipse IDE for Parallel Application Developers Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 mpirun (Open MPI) 1.4.3
Also with the same version of Eclipse and GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 mpiexec (mpich2 1.0.5p2)
I checked the version matching code and it should parse your version ok. The only other code I can see is the actual version check. Can you try running the command "gdb -q -i mi". When you see the "(gdb)" prompt, type "-gdb-version" and hit return. Let me know what output you get.
(In reply to comment #2) > I checked the version matching code and it should parse your version ok. The > only other code I can see is the actual version check. Can you try running the > command "gdb -q -i mi". When you see the "(gdb)" prompt, type "-gdb-version" > and hit return. Let me know what output you get. In my case the output is: -gdb-version ~"GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08\n" ~"Copyright (C) 2011 Free Software Foundation, Inc.\n" ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n" ~"This GDB was configured as \"x86_64-linux-gnu\".\nFor bug reporting instructions, please see:\n" ~"<http://bugs.launchpad.net/gdb-linaro/>.\n" ^done In Eclipse I see the following output in red (in its console): gdb: invalid option -- 'q' sdm [--debugger=value] [--debugger_path=path] [--proxy=proxy] [--host=host_name] [--port=port] [--master] [--server=rank] [--debug[=level]]
I tried some debugging on the SDM itself. The error is generated after calling function MICommandResultOK() in function GetGDBVersion(). The returned value of MICommandResultOK is not 1(TRUE) and that takes the code path to generate error message "Unable to determine gdb version". Taking one step closer, I found that the completed field of the MICommand structure, cmd, is not 1(TRUE) when it is passed into function MICommandResultOK() and it leads function MOCommandResultOK() to return 0. I stopped my investigation at this point. Hopefully what I found is useful to others.
(In reply to comment #4) > I tried some debugging on the SDM itself. > > The error is generated after calling function MICommandResultOK() in function > GetGDBVersion(). The returned value of MICommandResultOK is not 1(TRUE) and > that takes the code path to generate error message "Unable to determine gdb > version". Taking one step closer, I found that the completed field of the > MICommand structure, cmd, is not 1(TRUE) when it is passed into function > MICommandResultOK() and it leads function MOCommandResultOK() to return 0. > > I stopped my investigation at this point. Hopefully what I found is useful to > others. Thanks! I believe the problem is that the gdb version being used does not understand the '-q' option, which is preventing gdb from starting. The MISessionStartLocal function does not detect that gdb is unable to start. The debugger then continues to try to determine the version, and ultimately fails. Hence the misleading message. I've verified this happens if you change '-q' to and invalid option for gdb. A workaround for now is to remove the '-q' option at lines 160 and 162 of MISession.c (in org.eclipse.ptp.debug.sdm/libmi). I wasn't aware of any versions of gdb that do not support '-q'. The correct way to deal with this would be to write an autoconf test to check that gdb supports '-q' and set a config.h option if it doesn't.
Hi Greg, As it turn out, there is nothing wrong with the code. Such an error was caused by in incorrect configuration in my Eclipse's preference set up. When I set up SDM, Windows->Preferences->Parallel Tools->Debug->SDM, I populate "Path to backend debugger" with the path to the SDM binary rather than the path to gdb. Therefore, an incorrect path is sent to SDM, so SDM was failing to start gdb. Apologies for wasting your time.
No problem, I'm glad we got it sorted out. See bug 360139 for a description of the paths. These need to be made clearer in the next release.
