Bugs item #1665751, was opened at 2007-02-21 17:40
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=1665751&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: inverted index handling
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: cscope-15.5 aborts on startup on fc6
Initial Comment:
Hi,
I have an FC6 machine on which I installed cscope-15.5 binary. Cscope aborts on startup with the following error:
Find this C symbol:
Find this global definition:
Find functions called by this function:
Find functions calling this function:
Find this text string:
Change this text string:
Find this egrep pattern:
Find this file:
Find files #including this file:
Find all function definitions:
Find all symbol assignments:
cscope: invlib.c:563: invopen: Assertion `invcntl->param.sizeblk == sizeof(t_logicalblk)' failed.
Abort
I download 15.6 and the result is same. I compiled 15.6 with the assert commented out. Things seem to work fine with the assert removed. Since I don't know the purpose of I the assert, thought I'd report it. Thanks.
Bhasker.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-07-16 09:25
Message:
Logged In: NO
Perhaps the problem is because the cscope (-bq) database with inverted
index was built on a 32 bit machine & now use (-d) on a 64 bit machine. Or
this could be the other way around as well. I have seen this happen on my
two Linux systems, one of which is 32 bit & other 64 bit.
One simple workaround (not solution because it is compiler, gcc,
specific)may be to put "pragma pack(0)" before all the struct definitions
in "invlib.h" and "global.h" of the cscope sources & use this cscope.
Please do post your results.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-04-06 16:09
Message:
Logged In: NO
If I knew how to get that info, I'd have provided it in my previous post.
Here's the 'uname -a' output for both machines.
bhasker.
> uname -a
FreeBSD tbuild4 4.11-RELEASE-p12 FreeBSD 4.11-RELEASE-p12 #0: Mon Oct 17
12:24:06 PDT 2005 root@... i386
> uname -a
Linux ballam-lnx 2.6.12-1.1447_FC4 #1 Fri Aug 26 20:29:51 EDT 2005 i686
i686 i386 GNU/Linux
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2007-03-29 14:11
Message:
Logged In: YES
user_id=27517
Originator: NO
> Don't know if 64-bit is enable or not.
Then go find out! I've pointed you towards that issue twice before.
This is almost certainly caused exactly by one of those machines running a
64-bit system, the other a 32-bit one. In other words, you've rediscovered
this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=449808&group_id=4664&atid=104664
The assert()s you removed are there exactly to avoid the nastier
consequences #449808 would cause if the program tried to continue running
in such a setup. A clean abort is better than an almost, but not quite
working program.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-28 16:35
Message:
Logged In: NO
Sorry for the delay, here's the info:
Both machines are Xeons and hence little indian. Don't know if 64-bit is
enable or not.
Machine 1 (where the cscope database was built):
arch: i386
CPU: Intel(R) Xeon(TM) CPU 3.80GHz (3800.15-MHz 686-class CPU)
Hyperthreading: 2 logical CPUs
FreeBSD/SMP: Multiprocessor motherboard: 4 CPUs
C compiler: gcc version 2.95.4 20020320 [FreeBSD]
Machine 2: (where I used the database and crashed):
arch: i686
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 0a
C compiler (output of gcc -v):
Target: i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
Hope this helps. Let me know if need any more info. Thanks.
Bhasker.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2007-03-06 13:36
Message:
Logged In: YES
user_id=27517
Originator: NO
Erm, I asked about architecture, not operating system. The key question
is whether they memory layout of C data structures on the two machines is
likely to be the same. Big-endian vs. little-endian, 64-bit vs. 32-bit
system, machines using different compilers, that kind of thing.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-06 13:22
Message:
Logged In: NO
yes, one was bsd and the other a linux FC4.
Bhasker.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2007-03-06 13:01
Message:
Logged In: YES
user_id=27517
Originator: NO
And those two machines, are they of the same architecture? If not, this
is a duplicate of an old bug: inverted index not portable.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-05 15:45
Message:
Logged In: NO
The file supplied for '-i' is clear. It has only source files.
There are two machines involved. Unfortunately I replaced the binary that
was giving me the problem with the one I compiled (removing the assert).
Since I don't have the binary, I am unable to reproduce the problem. All
other available 15.5 binaries (on the web) seem to exhibit different set of
problems when I tried them. For now I am happy with the one I compiled.
Thanks for your time.
Bhasker.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2007-02-28 14:32
Message:
Logged In: YES
user_id=27517
Originator: NO
If you're using the -i listfile option, there's a very good chance the
real error is in that listfile. Make sure it names nothing but actual C
source files. No unreadable files, no directories, no binaries.
Unless there's a second machine in play (built a database on one machine,
read it on an other), the assert() triggered cannot really be close to the
heart of the problem. It's impossible to say more without seeing the
actual file (a small-as-possible example, that is).
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-02-26 16:30
Message:
Logged In: NO
Yes I was using '-k -q -i' options.
I made mistake when I said it was FC6, it's actually an FC4 machine.
Here's the uname output:
Linux ballam-lnx 2.6.12-1.1447_FC4 #1 Fri Aug 26 20:29:51 EDT 2005 i686
i686 i386 GNU/Linux
Hardware: Dell Optiplex GX620
Let me know if there are any other details that I can provide. Thanks.
Bhasker.
----------------------------------------------------------------------
Comment By: Hans-Bernhard Broeker (broeker)
Date: 2007-02-22 11:44
Message:
Logged In: YES
user_id=27517
Originator: NO
The most likely explanation for that assert() to fail is that your
machine's compiler is using some struct layout that invlib didn't expect.
That assert() is an important sanity check of the inverted index file
format. Which means that, as a workaround, you could just leave out the -q
option.
All that set aside: we need more details. I'll venture a guess that your
"FC6 machine" (no further specifications) actually runs the 64-bit edition
of FC6. That still wouldn't explain why I don't remember anything like
that happening on my own 64-bit Linux box, but it'd be a first hint.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=1665751&group_id=4664
|