Bug 169402 - ncurses test program crashes during debug
Summary: ncurses test program crashes during debug
Status: RESOLVED DUPLICATE of bug 204638
Alias: None
Product: kdevelop
Classification: Applications
Component: CPP Debugger (show other bugs)
Version: 3.5.1
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-18 22:14 UTC by Adam Vollmer
Modified: 2011-12-30 20:07 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Vollmer 2008-08-18 22:14:39 UTC
Unfortunately, I'm running into the exact same problem. Konsole isn't crashing, it is terminating normally. "Error opening terminal: unknown." is printed to the console, and then exit is called.

I first ran into this bug attempting to fix an unrelated bug on another project (which I had not run with Kdevelop before). Due to unloading issues, the program segfaulted instead of closing cleanly, so I am unable to see the error given.

When I created the "hello world" ncurses program in an attempt to debug this problem, konsole immediately closed after stepping past initscr.

I am using the separate I/O terminal. It is Konsole. The bug occurs when using KDE, as well as xfce and Gnome. Konsole works normally aside from this bug.

+++ This bug was initially created as a clone of Bug #59276 +++

Version:           3.0.0a4 (using KDE KDE 3.1.2)
Installed from:    Debian testing/unstable Packages
Compiler:          gcc 3.3 linux 2.4.21-rc1
OS:          Linux

I want to debug a application using the ncurses library.
But the debugger crashes during the initscr() call.

For example...

#include <iostream>
#include <cstdlib>

#include <ncurses.h>

int main(int argc, char *argv[])
{
  initscr();
  endwin();
  printf("quit\n");
  return EXIT_SUCCESS;
}


I set a breakpoint at initscr() and when i step over this line the debugged terminal crashes immediately.
I'm using the seperate IO Terminal.

When i call the whole thing from the shell with the same gdb-calls it works fine.

Debugging Shell is /usr/bin/libtool.

Debbugger output:

/bin/sh -c /usr/bin/libtool gdb /home/huedi/test/test/src/test -fullname -nx -quiet
(gdb) set edit off 
(gdb) set confirm off 
(gdb) (gdb) 
(gdb) set print static-members off 
(gdb) tty /dev/pts/1 
(gdb) set width 0 
(gdb) set height 0 
(gdb) set stop-on 1 
(gdb) handle SIG32 pass nostop noprint 
(gdb) handle SIG43 pass nostop noprint 
(gdb) set print asm-demangle on 
(gdb) cd /home/huedi/test/test/src 
(gdb) break test.cpp:12 
Breakpoint 1 at 0x80486a9: file test.cpp, line 12.
(gdb) run 
Stopped due to shared library event
(gdb) continue 
Stopped due to shared library event
(gdb) continue 
Stopped due to shared library event
(gdb) continue 

Breakpoint 1, main (argc=1, argv=0xbffffca4) at test.cpp:12
/home/huedi/test/test/src/test.cpp:12:146:beg:0x80486a9
(gdb) backtrace 
#0  main (argc=1, argv=0xbffffca4) at test.cpp:12
(gdb) info breakpoints 
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x080486a9 in main at test.cpp:12
	breakpoint already hit 1 time

... and here i hit step over and my test-app crashes.

cu Huedi
Comment 1 Adam Vollmer 2008-08-18 23:11:02 UTC
I've upgraded to 3.5.2-4, and the debugger no longer stops on initscr.
Comment 2 Adam Vollmer 2008-08-18 23:49:20 UTC
Ok, the upgrade isn't the kicker.

Running "kdevelop &" from the console allows me to correctly debug curses programs.
Running kdevelop via the programs menu will not work correctly.

I suspect curses is getting its cues as to the terminal type based on how kdevelop is launched.
Comment 3 Andreas Pakulat 2008-08-18 23:55:12 UTC
I can confirm that running kdevelop from anything but a terminal causes the stepping to end when initializing the curses interface. A little test shows that in fact the problem is that the TERM variable is not set when launching inside konsole. I'm re-assigning this to konsole, as AFAIK its supposed to set that variable even if just running an application.
Comment 4 Andreas Pakulat 2008-08-18 23:56:29 UTC
I can confirm that running kdevelop from anything but a terminal causes the stepping to end when initializing the curses interface. A little test shows that in fact the problem is that the TERM variable is not set when launching inside konsole. I'm re-assigning this to konsole, as AFAIK its supposed to set that variable even if just running an application.
Comment 5 FiNeX 2008-11-19 20:25:32 UTC
Changed severity to "crash". I hope to have selected only the right bugs (>100) :-)
Comment 6 Kurt Hindenburg 2011-03-05 22:49:48 UTC
Has anyone tried a recent Konsole version?  If I understand #3, the issue is running KDevelop from the KDE menu and upon using gdb causes it to crash?  The suspect is that Konsole Part is not setting TERM?
Comment 7 Jekyll Wu 2011-08-28 10:28:51 UTC
I tried to reproduce this problem but was blocked by another issue. KDevelop kept telling me "GDB cannot use the tty* or pty* devices."

I am a little confused by the relationship between gdb, konsole and the target executable. The basic problem is : who starts the target executable? I thought it was konsole, but running 'ps aux|grep konsole' returned this :

konsole -caption kdevelop: Debug application console -e sh -c tty>/tmp/debug_tty.9YX3BR;trap "" INT QUIT TSTP;exec<&-;exec>&-;while :;do sleep 3600;done

My rough understanding is konsole is simply used to display the I/O. The target executable is not started by konsole, but by gdb. Am I right? If that is the truth, then of course $TERM is not set, because konsole is only responsible for and capable of setting $TERM for executable/process started by it. Starting kdevelop from terminal won't have this problem, because $TERM is already set and will be inherited by child processes.

Just my 2 cents. Hope some kdevelop developer can clarify my confusion.
Comment 8 Jekyll Wu 2011-08-29 16:07:35 UTC
Assign it to kdevelop. See comment #3 and #7.
Comment 9 Niko Sams 2011-12-30 20:07:27 UTC
I think this would be solved if gdb could use an external console, thus marking as duplicate of that bug.
Correct me if I'm wrong.

*** This bug has been marked as a duplicate of bug 204638 ***