From: SourceForge.net <no...@so...> - 2007-05-12 21:49:13
|
Support Requests item #1717363, was opened at 2007-05-11 19:29 Message generated for change (Comment added) made by broeker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=204664&aid=1717363&group_id=4664 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jack Goldstein (jackg_tor) Assigned to: Nobody/Anonymous (nobody) Summary: Match lines pointing to wrong files in large database Initial Comment: Hi, We've been successfully using cscope for a long time without major problems but recently, the size of our code base must have passed some threshold and the results of searches are no longer correct. Specifically, the number of matches, function names, line numbers and code snippets are all right but the file names are wrong, seeming to be almost random choices from within the code tree. The problem occurs in versions 15.5 and 15.6 on both Linux and AIX. In case it helps, here are the sizes of some of the files, in bytes: 596061077 all 32665600 all.in 429231828 all.po 4246958 filelist The filelist contains 68,576 files. I'm hoping that this problem is not too hard to fix once the cause is found but finding the cause when I don't know the code is a bit of a challenge. Does anyone have any hints on which data structures or functions are likely culprits? Thanks, Jack ---------------------------------------------------------------------- >Comment By: Hans-Bernhard Broeker (broeker) Date: 2007-05-12 23:49 Message: Logged In: YES user_id=27517 Originator: NO The sheer size of the database shouldn't matter. Not so far below the first 'natural' boundary of 2^31 (LONG_MAX), anyway. So we'll need more detailed input: which was the exact straw that broke this camel's back? Important, likely boundary values might be 2^16 files, or 2^29 bytes in file 'all' --- even though the invlib data structures actually allow for 2^24 and 2^31, respectively. But be sure to follow Neil's remark, too: make 101% positively sure that all files you name in your namelist are actually readable, C source files. In a nutshell: if xargs file < filelist prints anything else but "C source text" or variations thereof, consider yourself in trouble. ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2007-05-12 23:48 Message: Logged In: YES user_id=27517 Originator: NO The sheer size of the database shouldn't matter. Not so far below the first 'natural' boundary of 2^31 (LONG_MAX), anyway. So we'll need more detailed input: which was the exact straw that broke this camel's back? Important, likely boundary values might be 2^16 files, or 2^29 bytes in file 'all' --- even though the invlib data structures actually allow for 2^24 and 2^31, respectively. But be sure to follow Neil's remark, too: make 101% positively sure that all files you name in your namelist are actually readable, C source files. In a nutshell: if xargs file < filelist prints anything else but "C source text" or variations thereof, consider yourself in trouble. ---------------------------------------------------------------------- Comment By: Neil Horman (nhorman) Date: 2007-05-11 21:24 Message: Logged In: YES user_id=827328 Originator: NO Those file sizes shouldn't be relevant. can you check to make sure that all the file in your input list are C files, and that they are all readable. Non readable files have resulted in misconstructed indicies previously. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=204664&aid=1717363&group_id=4664 |