Larry,
I doubt that your problems are related to the size of the project.
(However, I really have no facts to base this opinion).
If you want a problem fixed, you need to describe the problem -- a
generic
"It is broken for me" is most likely ignored; Or as the case with the
only
defect mentioned in this chain, it is twisted into whatever the reader
wants
it to be.
When I have a problem, Say in file.c the symbol xyz does not code
complete, I take that file and all the ones that it includes, and remove
pieces of it until I have a small sample that fails -- then submit a bug.
You say that there are no symbols indexed -- so take a single file,
create
a project for it and see if it works. There are lots of failures in the
CDT, if you want the failures that affect you to be fixed, you will
need to
do something like this.
- Dave
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Larry Streepy
Sent: Thursday, January 25, 2007 2:23 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Problems with indexing/searching
Unfortunately, that would be impossible since the code base is strictly
confidential. But, I assumed that I wasn't the only on experiencing
this on
a medium size project (~250K LOC).
Thanks anyway.
Larry.
Daoust, Dave wrote:
> Larry,
>
> If you have a reproducable problem, I would suggest that you create a
new bug. I would strongly recommend that you reproduce your problem
on a
project that you can attach to the defect (this will greatly increase the
chances of it being fixed).
>
> - Dave
>
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Larry Streepy
> Sent: Thursday, January 25, 2007 12:40 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Problems with indexing/searching
>
> Hi Markus,
>
> Sorry for the improper use of this channel. However, I did read
through
that bug and the discussion seemed to morph from "the indexer takes
too long
and gets wrong results" into "we need to add better tracing to the
indexer." The latter is what seems to have been done when the bug was
closed. The underlying issue (broken/long running indexer) seems to have
been left behind. Has it been moved to a new bug? If so, I'll use that
forum to comment further.
>
> Thanks,
> Larry.
>
> Schorn, Markus wrote:
>> Hi Larry,
>> in general bugs are not discussed on this mailing list. You can find
>> the discussion in bugzilla. The bug you are referring to has been
>> fixed:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=155324
>>
>> Markus.
>>
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx
>> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Larry Streepy
>> Sent: Mittwoch, 24. Jänner 2007 21:39
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] Problems with indexing/searching
>>
>> I haven't seen any discussionon this for a while, so I'll ask: has
>> this been addressed in the new 4.0 RC? It would really be nice to
>> have a functional indexer to use on my code base. Right now, eclipse
>> for C++ is not much better than vi because it has none of the
>> navigational or reference searching available due to a busted indexer.
>>
>> Sorry to vent, but it's been very frustrating.
>>
>> If it's been addressed and I missed the message (I've been watching
>> cdt-dev ever since I posted this), I apologize.
>>
>> Thanks,
>> Larry.
>>
>> Sergey Prigogin wrote:
>>> Exactly my experience. See bugzilla 155324
>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=155324>.
>>>
>>> -sergey
>>>
>>> On 10/12/06, *James Hawkins*
<truiken@xxxxxxxxx
>>> <mailto:truiken@xxxxxxxxx>> wrote:
>>>
>>> On 10/12/06, Larry Streepy
<larry@xxxxxxxxxxxxxx
>>> <mailto:larry@xxxxxxxxxxxxxx>> wrote:
>>> > I've updated to the latest versions of the CDT and I'm still
having
>>> > trouble with the indexer.
>>> >
>>> > Here's some environmental data:
>>> > Running on CentOs (Linux variant)
>>> >
>>> > Eclipse version 3.2.1
>>> > CDT version 3.1.1.2006092708
>>> >
>>> > My project is big, but not massive (roughly 250,000 lines of
C++
>>> code).
>>> >
>>> > First, I just couldn't seem to get it to index my code
properly
>>> at all.
>>> > The indexer would run for less than a minute and emit no
>>> messages, so
>>> > I thought things were just fine.
>>> >
>>> > Then I would try to do a navigate to a type (Navigate->Open
Type) and
>>> > I'd start typing in the name of *any* of the classes
defined in
>>> my code
>>> > and none of them are present. The only things present seemed
to be
>>> > coming from some of my system includes, but nothing from my
code
>>> base.
>>> > I tweaked a lot of settings and then told the indexer to run
and
>>> off it
>>> > went (and has been going for more than an hour now).
>>> >
>>> > I looked in the eclipse .log file and I'm seeing several
>>> > StackOverflowError messages being emitted, so something is
definitely
>>> > off with the indexer. Here's a portion of one of the stack
traces:
>>> >
>>> > java.lang.StackOverflowError
>>> >
>>> org.eclipse.cdt.internal.core.pdom.db.ShortString.compare(
ShortString.java:202)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.PDOMNamedNode$NodeFinder.compare(
PDOMNamedNode.java
>>> :85)
>>> > org.eclipse.cdt.internal.core.pdom.db.BTree.accept(BTree.java
:226)
>>> > org.eclipse.cdt.internal.core.pdom.db.BTree.accept(BTree.java
:229)
>>> >
org.eclipse.cdt.internal.core.pdom.db.BTree.accept(BTree.java:229)
>>> > org.eclipse.cdt.internal.core.pdom.db.BTree.accept(BTree.java
:195)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPLinkage.adaptBinding(
PDOMCPPLinkage.java:292)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPLinkage.resolveBinding
>>> (PDOMCPPLinkage.java:316)
>>> > org.eclipse.cdt.internal.core.pdom.PDOM.resolveBinding(
PDOM.java:248)
>>> >
>>> org.eclipse.cdt.internal.core.dom.parser.cpp.CPPScope.getBinding(
CPPScope.java:134)
>>> >
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPSemantics.lookup
>>> (CPPSemantics.java:1019)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPSemantics.resolveBinding(
CPPSemantics.java:613)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java
>>> :164)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding(
CPPASTName.java:52)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPNamespace.getBinding(
PDOMCPPNamespace.java:146)
>>> >
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPScope.getBinding
>>> (CPPScope.java:136)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:350)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:191)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding(
CPPASTName.java:52)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPNamespace.getBinding(
PDOMCPPNamespace.java:146)
>>> >
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPScope.getBinding
>>> (CPPScope.java:136)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:350)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:191)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding(
CPPASTName.java:52)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPNamespace.getBinding(
PDOMCPPNamespace.java:146)
>>> >
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPScope.getBinding
>>> (CPPScope.java:136)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:350)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:191)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding(
CPPASTName.java:52)
>>> > ...
>>> >
>>> >
>>> > There are two basic forms of stack overflow that have been
occuring,
>>> > here's a sample of the other:
>>> >
>>> > java.lang.StackOverflowError
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.ASTNode.getTranslationUnit(
ASTNode.java:108)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.ASTNode.getTranslationUnit(
ASTNode.java
>>> :108)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.ASTNode.getTranslationUnit(
ASTNode.java:108)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.ASTNode.getTranslationUnit(
ASTNode.java:108)
>>> >
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPScope.getBinding
>>> (CPPScope.java:128)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPClassScope.getBinding(
CPPClassScope.java:238)
>>> >
>>> org.eclipse.cdt.internal.core.dom.parser.cpp.CPPSemantics.lookup(
CPPSemantics.java:1019)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPSemantics.postResolution(
CPPSemantics.java:665)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPSemantics.resolveBinding(
CPPSemantics.java:629)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding
>>> (CPPVisitor.java:297)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:191)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding(
CPPASTName.java:52)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPNamespace.getBinding(
PDOMCPPNamespace.java:146)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:350)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding
>>> (CPPVisitor.java:191)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding(
CPPASTName.java:52)
>>> >
>>>
org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPNamespace.getBinding(
PDOMCPPNamespace.java
>>> :146)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:350)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPVisitor.createBinding(
CPPVisitor.java:191)
>>> >
>>>
org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.resolveBinding
>>> (CPPASTName.java:52)
>>> > ...
>>> >
>>> >
>>> > I have increased the heap size and thread stack size
considerably
>>> (with
>>> > -vmargs -Xmx2048M -Xss512M) so I don't think it's mu
configuration.
>>> >
>>> > Any ideas on what might be wrong? Has this behavior been seen
>>> before?
>>> > I did search the archives and other blogs, but I didn't find
anything
>>> > directly relevant.
>>> >
>>>
>>> I run into this problem when trying to index the source of the
Wine
>>> code base. The indexer either doesn't run at all, runs but stops
>>> because of stack overflow, or it runs to completion (or so it
says)
>>> but only recognizes some (a very limited amount) of my
information.
>>>
>>> --
>>> James Hawkins
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
<mailto:cdt-dev@xxxxxxxxxxx>
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> ---
>>>
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
