Bug 72160 - cscope becomes zombie after doing a search from within vim
Bug#: 72160 Product:  Gentoo Linux Version: unspecified Platform: x86
OS/Version: Linux Status: RESOLVED Severity: major Priority: P2
Resolution: FIXED Assigned To: vim@gentoo.org Reported By: B.Steinbrink@gmx.de
Component: Development
URL: 
Summary: cscope becomes zombie after doing a search from within vim
Keywords:  
Status Whiteboard: 
Opened: 2004-11-22 18:04 0000
Description:   Opened: 2004-11-22 18:04 0000
After upgrading cscope from 15.5 to 15.5-r1 cscope becomes a zombie after
performing a search from within vim and makes following searches from within
the same vim session fail. Downgrading to 15.5 makes the problem disappear.

Reproducible: Always
Steps to Reproduce:
1. Start vim
2. Add a cscope database (f.e. :cs add cscope.out)
3. Do a search (f.e. :cs f s main)
4. Do another search (f.e. :cs f s main)

Actual Results:  
After step 3 cscope became a zombie
23776 pts/5    00:00:00 vi
23777 pts/5    00:00:00 cscope <defunct>

After step 4 i got:
E262: error reading cscope connection 0
E259: no matches found for cscope query s of main


Expected Results:  
After step 3 cscope should not have terminated.
After step 4 i should have seen the search results.

Portage 2.0.51-r3 (default-linux/x86/2004.2, gcc-3.3.4,
glibc-2.3.4.20040808-r1,
 2.6.10-rc2 i686)
=================================================================
System uname: 2.6.10-rc2 i686 AMD Athlon(tm) XP 2600+
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3
Headers:  sys-kernel/linux26-headers-2.6.8.1
Libtools: sys-devel/libtool-1.5.2-r7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -pipe -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse
-fomit-frame
-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/s
hare/config /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/
dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/c
onfig/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse
-fomit-fra
me-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="ftp://cs.ubishops.ca/pub/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X alsa apache2 avi bash-completition berkdb bitmap-fonts bzlib caps
c
dr crypt cscope cups divx4linux dvd encode f77 flac foomaticdb fortran ftp gdbm 
gif gpm gtk gtk2 icq imagemagick imap imlib innodb java jikes jpeg junit
lesstif
f libg++ libwww mad maildir mbox mikmod mime mmap mmx mpeg mysql mysqli ncurses 
nls nocardbus nocd nptl offensive oggvorbis opengl oscar pam pcntl pcre pdflib
p
erl php png posix python quicktime readline samba sasl sdl session sharedmem
sla
ng sockets spell spl sse ssl svga sysvipc tcpd tetex tiff truetype unicode usb
v
hosts videos x86 xine xml2 xmms xv xvid zlib"

------- Comment #1 From Björn Steinbrink 2004-12-06 17:40:38 0000 -------
Works now. Magic? Maybe it was related to one of the ebuilds that got updated
meanwhile...

------- Comment #2 From Björn Steinbrink 2004-12-09 03:30:02 0000 -------
ok, seems it was just coincidence... But i tracked it down now.
In 15.5-noclobber-tempfile-rexotec.patch we have this code for reopening the temporary file:
                (void) fclose(refsfound);
-               if ( (refsfound = myfopen(temp1, "wb")) == NULL) {
+               if ( (refsfound = myfopen(temp1, "w+xb")) == NULL) {

This obviously fails since we just closed the file temp1, but it's still there, thus the O_EXCL flag prevents us from reopening the file.
As a quickfix I put a call to unlink() after fclose(), but i guess it would make more sense to replace the fclose()/myfopen() sequence with a ftruncate()/frewind() sequence (I didn't look at myfopen(), so I may be talking nonsense here...).

------- Comment #3 From Ryan Phillips (RETIRED) 2004-12-11 21:44:45 0000 -------
Bjorn is this still an issue with the updated -r3 ebuild?

------- Comment #4 From Björn Steinbrink 2004-12-11 22:20:33 0000 -------
Yes, it is. I also noticed that it is not only vim, but consecutive searches
within the same cscope session in general. When executing more than one query
in the ncurses interface, only the first one shows any results.
I'll attach a strace of the cscope process, any other information wanted?

------- Comment #5 From Björn Steinbrink 2004-12-11 22:26:21 0000 -------
Created an attachment (id=45804) [details]
strace of failing cscope

$ strace -o cscope.strace -fF cscope -l
>> 0main
cscope: 1 lines
test.c main 1 int main() {
>> 0main
Cannot reopen temporary file
cscope: 1 lines

------- Comment #6 From Ryan Phillips (RETIRED) 2004-12-12 11:39:50 0000 -------
Please sync and remerge -r3.

------- Comment #7 From Björn Steinbrink 2004-12-14 03:23:06 0000 -------
Works now, did a good number of tests this time ;)