Version: 3.3 (using KDE KDE 3.4.2) Installed from: Mandriva RPMs OS: Linux I want to debug a application using the ncurses library. But the debugger on kdevelop crashes during the initscr() call. If i'm using the IO Window the program just exit with code 01 on the initscr(); line and if the IO window is off i get "Error opening terminal: unknown" if i change the the "debugging shell" the debugger does not works (IO Window open and close very fast (Unknown option '-fullname')) i found this error marked as resolved on KDevelop 3.1.2, wich the code can "be run and stepped-through fine" but i'm using KDevelop 3.3 and this bug is back. code used: #include <ncurses.h> int main(int argc, char *argv[]) { initscr(); // <- Crash here endwin(); printf("quit\n"); return 0; }
Using KDevelop 3.4 branch, and "external terminal" option, running the program works fine. When running under debugger, though, I see some wierd characters being printed into the "Application" window. So there's a bug indeed. On the other hand, there are almost zero changes to me working on this bug specifically, so if anybody is interested to look, he's very welcome.
I had been running in the crash at initscr() too, this is something different, but related: initscr() from ncurses crashes, if the "TERM" environment variable is not set. Very simple. The workaround for kdevelop is: Set the TERM variable to something useful, e. g. "xterm", in the debugger options. If kdevelop would inherit the environment to the debugger/debugging shell, this crash would not happen.
I don't really understand what's the problem here... Running an ncurses app requires a terminal, which the Application view is not, so running it there cannot work. If it works correctly or not when debugging in a terminal I can't really say, since I know zero about ncurses, but if I debug through it I can step fine through the entire program. One thing is certain, KDevelop doesn't crash, so this isn't a crash report. Reducing severity to 'normal'.
more than one year later, downloaded kdevelop 3.40, and i still have a problem to debug ncurses code but now, when i step over the initscr(); line, instead of crashing the kdevelop, the debugger just exits, like it was the end of the source code i have the enabled the "separate terminal for application IO", and still cant debug after the line initscr(), changed to xterm like someone said, and no changes (only change is that now the konsole was replaced to xterm) when i f10 on the initscr(), the debugger process stops
What GDB version do you have ? KDevelop 3.4 requires GBD 6.4 but works better with GDB 6.6.
using GNU gdb 6.6-1mdv2007.1 (Mandriva Linux release 2007.1) when i create a new n_curses project i get 1 error: autoheader-2.5x: error: AC_CONFIG_HEADERS not found in configure.in when i try to check the link libraries on this default project, i get a kde error, "file or folder not found" the problem described on the last post was on a simple c++ hello world project, added -lcurses to the link libraries
I get the same problem - *if* I start kdevelop from an icon, e.g. menu or launcher. But if I open a terminal window, and type 'kdevelop &' then debugging ncurses appears to work just fine. It's interesting to check kdevelop's environment with both approaches Checking Project/Project Options/Configure Options/ then in the Environment Variables box, hit the Environment button. It seems to have many more env variables when started from a terminal, including $TERM=xterm Since it's sometimes nicer to start kdevelop from the menu, I tried adding TERM to kdevelop's environment by using the 'Configure Options' dialog, but it didn't fix this problem for some reason.
The reason the environments are different is probably because you're using a graphical login manager when logging into your system right? Some of the graphical login managers around don't read certain shell configuration files like $HOME/.bashrc, $HOME/.bash_profile and others. Now for running an application or debugging it you have to set the environment variables under the Run options not under Configure options page. So this bugreport is in fact invalid, we can't do something against broken graphical login manager and everything should work fine if you start your windowmanager from a TTY and not via a graphical login manager