#274 Update: Internal error: cannot get source line from database

open
5
2012-12-29
2012-07-24
barcaroller
No

I was unable to update the original bug report (#3545160) so I had to create this bug report.

Basically, I applied the patch mentioned in bug report #3528987. That worked (i.e. 'cscope -d -L0 <mysymbol>' returned the proper references) but it only worked temporarily and there's was one exception (see below). After a few days, the same command returned the original error ("Internal error: cannot get source line from database") and the only way to get rid of it was to remove all cscope files and rebuild the database.

The exception mentioned above is that cscope would now find references of the symbol inside CMakeList.txt files, when there were none. I suspect that cmake files somehow confuse cscope after the patch is applied (the symbol in question is identical in name to one of the source files; e.g. 'int foo' and foo.cpp)

I thought I should let you know in case this will help to fix the bug.

Discussion

  • This is getting us back to something that a lot of people do, and to this day I could never understand why, nor did any of the people in question seem to be willing to even try and come up with a sensible explanation: what on earth are you hoping to achieve by including CMake files in the list of files to be searched by a browser intended for C source --- which CMake files clearly are not? What's CMakeList.txt doing in your cscope.files?

    I mean, OK, some C preprocessor macros might well be defined in the Makefile file and passed into the C compiler from there, but since there's zero chance cscope would recognize them in that syntax, what could possibly, even remotely be the point? There's nothing in those files for cscope to find. I'll grant you that CMake or Make files are not the most absurd kind of files people have tried to feed to cscope by a wide margin (that honour belongs to the fellow who complained that jpeg images failed to scan...), but still: why?

    As to the error itself, that would suggest there's another bug (or another instance of the same bug fixed by the patch #3528987) hidden in the incremental database update routines this time. That's the only kind of bug a run of cscope -b -u would fix after a plain cscope -b didn't.

     
  • barcaroller
    barcaroller
    2012-07-26

    Sure, I can give you a explanantion (sensible or not). Not only do I include Makefiles, but also C++ source files, Java source files, HTML files, XML files, and other text-based configuration files that are part of my source code tree. That way, I can find/grep any pattern (not necessarily reference/definition) in my project, without having to go outside my editor (KScope/Kate in this instance). I've done this for years and cscope does a great job of handling these files even though they are not C files.

    In fact, cscope is so good at handling C/C++/Java files that I don't need to use other tools like CodeBlocks or Anjuta or KDevelop which generally handle multi-language projects but are much slower than cscope in finding patterns.

    I don't know whether this causes the error I had orginally described. Those are C++ symbols. I am detecting a pattern though. The error seems to occur only if the C++ symbol has the same name as a source file (which is then mentioned in a Makefile). For example, 'Foo foo and foo.cpp', where Foo is a C++ class. I have not been able to prove this conclusively, though.

     
  • > That way, I can find/grep any pattern (not
    > necessarily reference/definition) in my project, without having to go
    > outside my editor

    Hmm... so you're saying find-/replace-in-files is so bad in today's programmers' editors that it can be outperformed/outfeatured by integrating cscope? That bodes ill for the future of programs which came to yank Emacs and vi off their shared throne...

    > I am detecting a pattern though. The error seems
    > to occur only if the C++ symbol has the same name as a source file (which
    > is then mentioned in a Makefile). For example, 'Foo foo and foo.cpp',
    > where Foo is a C++ class. I have not been able to prove this conclusively,
    > though.

    That pattern, if it holds, should make it a whole lot easer to extract a small, yet useful example case. Without that, I fear it'll be hard, if not impossible to help you.

     
  • barcaroller
    barcaroller
    2012-07-30

    > Hmm... so you're saying find-/replace-in-files is so bad in today's
    > programmers' editors that it can be outperformed/outfeatured by integrating
    > cscope? That bodes ill for the future of programs which came to yank Emacs
    > and vi off their shared throne...

    Indeed. However, if you (or anybody in this forum) know of a tool that is faster than cscope/ctags/<editor>, let me know.

    > That pattern, if it holds, should make it a whole lot easer to extract a
    > small, yet useful example case. Without that, I fear it'll be hard, if not
    > impossible to help you.

    I can now confirm that this patterns holds. All the C++ symbols that were causing the error had names that were identical to file names that were then included in a makefile (which was included in the cscope file list).

    I used cscope outside its intended purpose, so I cannot expect help. I will simply remove makefiles from the cscope file list, or I will rename some of the symbols or files. Please feel free to close this bug report.

    Thanks for taking the time to maintain and improve cscope.