3

I run vim with cscope in my C development environment. I start vim within a GNU screen window on a freebsd 6.3 server and establish the cscope db connection with cs add .... At this stage everything works flawlessly.

If I detach the screen session and reattach it, any attempts to use cscope causes cscope to dump core. This is all I have from the core dump since my cscope is not compiled with debug symbols:

(gdb)
#0  0x480f45dc in ungetch () from /lib/libncurses.so.6
(gdb)

AFAIK there is no need to re-establish the cscope connection on vim when I reattach to screen. That would defeat the purpose of using screen. Anyone knows whats going on and if there is a workaround? If everything fails, I'm going to find time to compile cscope with symbols and figure out whats going on.

If it helps, my cscope DB is generated with:

cscope -bkq -P`pwd` -i cscope.files
jman
  • 11,334
  • 5
  • 39
  • 61

2 Answers2

3

Turns out that this is an issue fixed in cscope 15.7a. Posting an answer here in case someone else has the same issue (it bothered me for a couple of years before I decided to post here).

jman
  • 11,334
  • 5
  • 39
  • 61
2

Given that it's crashing in curses even though vim is going to invoke cscope -l (line mode) I think it is reasonable to guess that TERM=screen is related to your problem. I'd try making a wrapper (for example in $HOME/bin, assuming that's before /usr/local/bin in your path) to change it:

#!/bin/sh

if ! test -t 0
then
    TERM=vt100
fi

exec /usr/local/bin/cscope "$@"

Which says "if not running from a tty, fake TERM". The tty test is to try and avoid breaking interactive use. You could try TERM=none or other values as well.

Ben Jackson
  • 90,079
  • 9
  • 98
  • 150