From: Hans-Bernhard B. <br...@ph...> - 2005-02-04 11:21:25
|
Vincent Rubiolo wrote: > I'm having segfaults while generating the cscope database. Basically, I > do : > 1. Run 'find' on my source tree to find *.[ch] files Make sure that at the very least, do find -type f -name '*.[ch]' > cscope.files. to make sure you get no non-files in the list. Some other possible hiccups include silly names with blanks in them and dead symlinks. I've fixed some of these in the CVS version since 15.5, but there may still be some strange case missing. > 2. Run cscope -R -b -k -q to generate That doesn't make complete sense. '-R' is only useful if you don't have a cscope.files list. > Note that my cscope.files is quite large (wc -l gives me a 16207 total > count). Its sheer size is still well in the known-working range. People have been known to be running cscope -q on the entire Linux kernel tree for years. > Here is some crash info when run under gdb : > (gdb) run > Starting program: /folk/vrubiolo/bin/cscope -R -b -k -q > > Program received signal SIGSEGV, Segmentation fault. > 0x0804dfcd in build () at build.c:364 > 364 for (fileindex = firstfile; fileindex < lastfile; ++fileindex) { > (gdb) bt > #0 0x0804dfcd in build () at build.c:364 > #1 0x00000000 in ?? () This crash info is quite certainly bogus. There's *nothing* in that line of source that could possibly trigger a SIGSEGV. I'll need at least the output of 'info locals' to investigate this further, from remote, and possibly the main variables used in the vicinity of this line (srcfiles, nsrcfiles, lastfile, ...). You should also check what srcfile[fileindex] is, and make sure that file exists and is well. > I'm using the latest CVS tree (updated this morning). I thought the > problem was solved when going from 15.5 to CVS. Thought --- on what basis? > Finally, I cannot reproduce it with no DB present meaning there is > something wrong but only when incremental regeneration is done. This > make is really hard to pinpoint... Especially without knowing which of the files was changed. I.e. if it's a regeneration problem, you'll have to demonstrate a sequence of three steps to recreate it: cscope -bkuq # to build a fresh database from scratch something # or maybe nothing to do in this step cscope -bkq # rebuild the database |