#297 15.9 - searching for an undefined symbol causes cscope/vim to freeze

[Adam Incera]

Upgraded to 15.9 a couple of days ago through homebrew, and since then, if I hit <ctrl +="" ]=""> to go to the definition of a symbol, if the symbol is not defined, vim freezes. Also happens if I run ":cs find s <undefined symbol".</ctrl>

Also, I can't seem to figure out how to downgrade to the previous version through homebrew since the only formula is 15.9. Is there some way to do that that I'm missing?

[Hans-Bernhard Broeker]

This does not reproduce here. Neither in Vim, nor in cscope when used on its own.

This makes it likely that the homebrew port you're using is the problem.

[Josh Allmann]

Can confirm that this happens here on macOS with the following steps:

Clone cscope git master at https://git.code.sf.net/p/cscope/cscope
export EDITOR=vim
Run cscope -R to generate an index. Here, I used the root of the ffmpeg git repo.
Open ffmpeg.c file via "Find this file:"
Run ":cs f s <undefined-symbol>" within vim.</undefined-symbol>

Vim freezes / becomes unresponsive and has to be killed.

Was able to bisect and narrow it down to this commit: 6d646e7528f499d6df559cffc43ee11dd424c501

$ git show 6d646e7528f499d6df559cffc43ee11dd424c501
commit 6d646e7528f499d6df559cffc43ee11dd424c501 (refs/bisect/bad)
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Fri Aug 7 13:11:35 2015 +0000

    Adding chek on return code of search() in linemode

    Currently we don't check the return code of search() in line mode.  If search
    fails reffile will be null, resulting in a crash when we call getc on it

diff --git a/src/main.c b/src/main.c
index dd83a77..744f779 100644
--- a/src/main.c
+++ b/src/main.c
@@ -67,7 +67,7 @@
 #define DFLT_INCDIR "/usr/include"
 #endif

-static char const rcsid[] = "$Id: main.c,v 1.56 2012/11/20 15:20:26 nhorman Exp $";
+static char const rcsid[] = "$Id: main.c,v 1.57 2014/11/20 21:12:54 broeker Exp $";

 /* note: these digraph character frequencies were calculated from possible 
    printable digraphs in the cross-reference for the C compiler */
@@ -796,10 +796,13 @@ cscope: cannot read source file name from file %s\n",
            case '9':   /* samuel only */
                field = *buf - '0';
                strcpy(Pattern, buf + 1);
-               search();
-               printf("cscope: %d lines\n", totallines);
-               while ((c = getc(refsfound)) != EOF) {
-                   putchar(c);
+               if (search() == NO) {
+                       printf("Unable to search database\n");
+               } else {
+                       printf("cscope: %d lines\n", totallines);
+                       while ((c = getc(refsfound)) != EOF) {
+                           putchar(c);
+                       }
                }
                break;

Reverting this one commit makes things work OK again with master. Not sure what a proper fix would be, as I'm unfamiliar with the cscope codebase. Also haven't tested Linux yet, so the issue may be macOS specific.

Some more environment specifics that may be relevant:
macOS Mojave
Mac command-line tools installed, so "gcc" == clang/llvm
* Nix package manager

[Hans-Bernhard Broeker]

Reverting that change would be quite obviously the wrong idea. Without that fix, cscope might just crash on the spot, which cannot possibly be correct.

That indicates the actual problem is closer to vim than to cscope, here. I suspect (your version of) the cscope support in vim just don't expect the output "Unable to search database" from its "cscope -l" subprocess.

And indeed, on inspection of the vim sources, they did add code to handle this new response in January of 2018. So: what you really need is a fresher vim.

[Josh Allmann]

what you really need is a fresher vim.

Compiled a vim from git master, and it seems to work now with cscope master. Thanks for the tip.