Description of problem: cscope recomputes some index data at startup, even with up-to-date index files (cscope.*.out) and an unchanged source file tree. Version-Release number of selected component (if applicable): cscope-15.5-15.4.fc7 How reproducible: always Steps to Reproduce: 1. run cscope -R -q on some big source tree 2. quit cscope 3. rerun cscope -R -q Actual results: cscope does some reindexing work again; probably the "-q" part Expected results: cscope should reuse old index files
How are you sure that reindexing is occuring? Are you just observing disk activity? If so, thats expected, as cscope goes through the file list to check file metadata and be sure that no index update is needed. I just tried this version on my system here on a kernel tree, and thats the only filesystem activity I see from a strace.
In my case, strace shows the huge list of lstat/gedent/etc checks, but then we get to this ... lstat("/usr/include", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0 rt_sigaction(SIGTSTP, {SIG_IGN}, {0x3b1b013fe0, [], SA_RESTORER|SA_RESTART, 0x3b0c230f30}, 8) = 0 select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout) write(1, "\33[HBuilding cross-reference...\33["..., 33Building cross-reference...) = 33 rt_sigaction(SIGTSTP, {0x3b1b013fe0, [], SA_RESTORER|SA_RESTART, 0x3b0c230f30}, NULL, 8) = 0 [...] open("ncscope.out", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 open("/var/tmp/cscope.20392/cscope.1", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaabed000 gettimeofday({1205024680, 984453}, NULL) = 0 [...] write(6, "anup_procfs_example !!!G! \nMODUL"..., 4096) = 4096 read(4, "c\n->\n\304_ru\302\232g\n, c->\n\304_\241\335\263d\n, c->\n"..., 8192) = 8192
Created attachment 297483 [details] patch to fix samelist function oops, you're right, I see it now. The samelist function wasn't pulling in newlines during its search properly, and as such was always failing, forcing a db rebuild. Who knows how long thats been there. This is the fix. I'll be pushing this upstream as well. Thanks for the catch Frank!
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It seems like cscope-16.6-1.fc9 running consecutive "cscope -R -q" jobs against an unmodified linux kernel tree cause the same kind of undesired recomputation.
Thats odd, I don't know where this fix wen't. It appears to be missing from the repository. How odd, we'll I'll get it pushed in again. Thanks framk!
Actually, I take that back, I do see the fix in there, but its not always working (not sure why). It only works occasionally for me, looking into why
ahh, found the issue, I'm missing a subsequent patch from upstream that corrected an additional corner case with this. I'll post the fix shortly.
fixed in -2.f10/-2.f9. Thanks Frank!
cscope-15.6-2.fc9 has been submitted as an update for Fedora 9
cscope-15.6-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.