This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 168763 - [indexer] Incomplete discovery using compilation output
Summary: [indexer] Incomplete discovery using compilation output
Status: RESOLVED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: Code Model (show other bugs)
Version: 6.x
Hardware: All Linux
: P3 blocker (vote)
Assignee: Alexander Simon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-18 00:23 UTC by rmartins
Modified: 2011-04-27 17:11 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Compilation output (copied from the output window) (7.89 MB, text/plain)
2009-07-25 23:23 UTC, rmartins
Details
ACE_TAO project with gcc4.4 (128.27 KB, application/octet-stream)
2009-07-25 23:24 UTC, rmartins
Details
ACE_TAO project with gcc4.3.2 (124.66 KB, application/octet-stream)
2009-07-25 23:40 UTC, rmartins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rmartins 2009-07-18 00:23:43 UTC
Hi,
When we enable "code assistance" using the compilation output (by compiling using clean&build and then configuring the
code assistance using the icon on the output window) the discovery is not complete, leading to parsing failures.
(to speed up tests I used only ACE: http://download.dre.vanderbilt.edu/previous_versions/ACE-5.7.1.tar.bz2
and not ACE+TAO).
I tested it on Ubuntu 8.10 (that works using the dwarf approach).

Since I think it's a core and a must (because it's a fall-back when the dwarf approach fails), I assigned it P2.

Thanks,
Rolando
Comment 1 rmartins 2009-07-19 21:55:11 UTC
Hi,
I also tested with ACE+TAO; the result has a with a very large set of failed includes.

Thanks,
Rolando
Comment 2 rmartins 2009-07-20 11:03:25 UTC
Hi,
I have tried 2 approaches.
1) Configure the project without dwarf support (outside netbeans), then create the netbeans project using the previous
configure and set to clean&build automatically , adding VERBOSE=1 into "make" command
2) Configure inside netbeans, then clean&build, after this running code assistance from the compilation output box.

What I have found:
a) I get less errors from this approach.
b) Netbeans scans and parses the project, but since we don't have enough information, we will have tons of failed
includes, because we need to compile the project (clean&build) and then run code assistance. Could be avoid the first
parsing?

Thanks,
Rolando
Comment 3 Quality Engineering 2009-07-23 07:47:34 UTC
Integrated into 'main-golden', will be available in build *200907230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/5fc431ae3b45
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixing IZ#168763:[indexer] Incomplete discovery using compilation output
Comment 4 rmartins 2009-07-23 19:35:05 UTC
Hi Alexander,
I tried with a small project (that uses cmake as the primary build system, that in turn creates the Makefile) without
any errors.
I realized one major; ACE+TAO uses several (dozens) Makefiles that have dependencies between themselves; the small
project only has one Makefile.

Could this factor be causing all the problems?

Thanks,
Rolando

Comment 5 rmartins 2009-07-23 20:06:04 UTC
Hi Alexander,
I found a way to get the parsing properly done.
In ACE, 
1)I create a log from the make (make > make.log)
2)created the project using existing makefile
3) cancel initial parsing
4)configured code assistance to use make log => starts parsing
result: no errors!

I will do the same for ACE+TAO, and post my findings....

Thanks,
Rolando
Comment 6 rmartins 2009-07-23 23:39:05 UTC
Hi,
the ACE+TAO project failed with the make log approach, but I think this might be linked to the exception I got when I am
configuring code assistance:
http://statistics.netbeans.org/analytics/exception.do?id=232352
org.openide.util.RequestProcessor$FastItem: task failed due to: java.lang.AssertionError
java.lang.AssertionError
        at org.netbeans.modules.cnd.modelimpl.csm.NamespaceImpl.removeNestedNamespace(NamespaceImpl.java:357)
        at org.netbeans.modules.cnd.modelimpl.csm.NamespaceImpl.addRemoveInParentNamespace(NamespaceImpl.java:522)
        at org.netbeans.modules.cnd.modelimpl.csm.NamespaceImpl.removeNamespaceDefinition(NamespaceImpl.java:546)
        at org.netbeans.modules.cnd.modelimpl.csm.NamespaceDefinitionImpl.dispose(NamespaceDefinitionImpl.java:253)
        at org.netbeans.modules.cnd.modelimpl.csm.core.Utils.disposeAll(Utils.java:118)
        at org.netbeans.modules.cnd.modelimpl.csm.core.FileImpl.disposeAll(FileImpl.java:742)
        at org.netbeans.modules.cnd.modelimpl.csm.core.FileImpl.dispose(FileImpl.java:692)
        at org.netbeans.modules.cnd.modelimpl.csm.core.ProjectImpl.onFileRemovedImpl(ProjectImpl.java:209)
        at org.netbeans.modules.cnd.modelimpl.csm.core.ProjectImpl.onFileRemoved(ProjectImpl.java:228)
        at
org.netbeans.modules.cnd.modelimpl.csm.core.NativeProjectListenerImpl.onProjectItemRemoved(NativeProjectListenerImpl.java:208)
        at
org.netbeans.modules.cnd.modelimpl.csm.core.NativeProjectListenerImpl.filesRemoved(NativeProjectListenerImpl.java:91)
        at org.netbeans.modules.cnd.makeproject.NativeProjectProvider.fireFilesRemoved(NativeProjectProvider.java:295)
        at org.netbeans.modules.cnd.makeproject.NativeProjectProvider.firePropertiesChanged(NativeProjectProvider.java:612)
        at
org.netbeans.modules.cnd.makeproject.NativeProjectProvider.checkForChangedItemsWorker(NativeProjectProvider.java:591)
        at org.netbeans.modules.cnd.makeproject.NativeProjectProvider.access$100(NativeProjectProvider.java:80)
        at org.netbeans.modules.cnd.makeproject.NativeProjectProvider$2.run(NativeProjectProvider.java:472)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:602)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1070)

Thanks,
Rolando
Comment 7 rmartins 2009-07-25 23:23:15 UTC
Created attachment 85216 [details]
Compilation output (copied from the output window)
Comment 8 rmartins 2009-07-25 23:24:38 UTC
Created attachment 85217 [details]
ACE_TAO project with gcc4.4
Comment 9 rmartins 2009-07-25 23:40:47 UTC
Created attachment 85218 [details]
ACE_TAO project with gcc4.3.2
Comment 10 rmartins 2009-07-27 10:51:26 UTC
hi,
in consequence of issue http://www.netbeans.org/issues/show_bug.cgi?id=169205, I have found that the problem resides in
the handling of Autoconf's Makefile type (although in my example it was created using CMake) . If you use the CND
makefiles (.mk), this problem doesn't exist.

Thanks,
Rolando
Comment 11 Quality Engineering 2011-04-13 08:41:58 UTC
Integrated into 'main-golden', will be available in build *201104130401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/00d65c32c478
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixing Bug #168763 [indexer] Incomplete discovery using compilation output
Comment 12 Quality Engineering 2011-04-14 08:36:29 UTC
Integrated into 'main-golden', will be available in build *201104140401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3e0cfe5bf32f
User: Alexander Simon <alexvsimon@netbeans.org>
Log: fixing Bug #168763 [indexer] Incomplete discovery using compilation output
- fix "excluded from build" status for header files
Comment 13 Alexander Simon 2011-04-27 17:11:23 UTC
Discovery prefers log of exec system calls now.
It is more reliable information about user include paths and macros.