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
|
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"
Works now. Magic? Maybe it was related to one of the ebuilds that got updated
meanwhile...
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...).
Bjorn is this still an issue with the updated -r3 ebuild?
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?
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
Please sync and remerge -r3.
Works now, did a good number of tests this time ;)