Bug 237200

Comment 1 Jerome Lanneluc 2008-06-16 07:59:27 EDT

It looks like search is returning an invalid Java element (i.e. the parent of the field should be ZipFile$1 instead of ZipFile)

Comment 2 Frederic Fusier 2009-03-05 06:28:42 EST

Sorry, it took me a long time before commenting this bug, but I was busy on other fronts last year at that time and after, this bug got forgotten in the depth of my inbox... :-(

Saying that, I cannot reproduce using 3.4.0...

I got the following correct match while searching for 'eof' field in the JDK 1.6 library:

Parsing ZipFile$1.class [in java.util.zip [in C:\JDKs\sun\6.0\jre\lib\rt.jar]]
Report matching:
        - node set: accurate=1, possible=0
        - must resolve: false (locator: false, nodeSet: false)
        - fine grain flags=none
Reporting match
        Resource: P/b237200
        Positions: [offset=8129, length=3]
        Java element: eof [in <anonymous> [in ZipFile$1.class [in java.util.zip [in C:\JDKs\sun\6.0\jre\lib\rt.jar]]]]
        Accuracy: EXACT_MATCH
        Rule: EXACT
        Raw: false

If you still encounter this problem, then please provide a complete test case to help me to reproduce, thanks

Comment 3 Andrey Loskutov 2009-03-06 02:34:42 EST

Created attachment 127779 [details]
Sample plugin and data projects

Hi,

I still see this issue (running with both 3.4.2 and 3.5M5).

1) Please import the attached plugin project "Bug237200" into the workspace 
2) launch Eclipse in debuger. 
3) In the second Eclipse, please import the attached data project "Bug237200_data"
4) Right click on the ContainsZipFileField.java from Bug237200_data in Package Explorer
5) Run "Search Fields" action
6) It will run the search for all the fields in given java class and then for each field declared in each Java type found by the first search.
7) In the console you will see search status and also error stack traces while trying to resolve type signatures for *some* fields.

Comment 4 Frederic Fusier 2009-03-06 05:08:32 EST

(In reply to comment #3)
> 
Ok, I got it thanks for the test case.

The problem comes from the scope you chose to perform the search:
                searchScope = createSearchScope(fieldType);

When searching for fields declaration of ZipFile, you restrict the search only to the binary type. That means that matches found in local types of this type should not be reported. Currently there's a bug while locating the match which tries to report some of them but with an invalid element type, hence the Java Model Exception you got...

Note that I'm thinking about a fix which will remove these invalid matches, but when it will be released, you still miss the fields declaration of the local types due to the restrictive scope you set for your search request...

Comment 5 Andrey Loskutov 2009-03-06 05:16:18 EST

Sorry for offtopic, how I can include type "A" AND it's local/member types (not accessible without the "A" context) to the search?

Comment 6 Frederic Fusier 2009-03-06 05:37:17 EST

(In reply to comment #5)
> Sorry for offtopic, how I can include type "A" AND it's local/member types (not
> accessible without the "A" context) to the search?
> 
It's easy for member types: just get them from the IType using getTypes() and add them to the scope. The problem is for local or anonymous types, you can't get them without parsing the source, so I would say there's no real solution for them...

But do you really want to get fields declaration of anonymous or local types?

Comment 7 Andrey Loskutov 2009-03-06 06:11:29 EST

Created attachment 127797 [details]
Data Hierarchy Plugin

Ok, let's explain why I've started this:

my goal was to answer a "simple" question by statically inspecting given Java type:

which references to which objects *can* hang around in memory after I create an instance of given type? More specific: if there are static fields in a type, which memory *can* never be released if these fields would be assigned?

This mean: creating a tree of types by searching recursively all the related types referenced by fields of given type. Of course such search will never give a *complete* answer (if you have Collection<?> fields you can have references to any number of types which can't be analysed statically, or if the field has an interface/not the most specific type). But it helps to quick review the code and to understand the "data hierarhy" of a given type.

Please try attached plugin (work in progress) which I've written to better understand where we can have memory leaks in FindBugs :-)

So doing this I guess I have also look into the local/anonymous types. There is a high probability that they can be stored internally to fields and keep some additional references to additional types.

Comment 8 Frederic Fusier 2009-03-06 07:11:47 EST

(In reply to comment #7)
> Created an attachment (id=127797) [details]
> Data Hierarchy Plugin
> 
> Ok, let's explain why I've started this:
> 
> my goal was to answer a "simple" question by statically inspecting given Java
> type:
> 
> which references to which objects *can* hang around in memory after I create an
> instance of given type? More specific: if there are static fields in a type,
> which memory *can* never be released if these fields would be assigned?
> 
>...
> So doing this I guess I have also look into the local/anonymous types. There is
> a high probability that they can be stored internally to fields and keep some
> additional references to additional types.
> 
I would say no, as local or anonymous types cannot declare static fields...

Comment 9 Eclipse Genie 2020-02-04 07:41:10 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.