Bugzilla – Full Text Bug Listing
| Summary: | AIOOB exception during build | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Tim deBoer <deboer> | ||||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | curtis.windatt.public, daniel_megert, darin.eclipse, michschn, mober.at+eclipse, pascal, remy.suen, steffen.pingel, zina | ||||||
| Version: | 3.6 | ||||||||
| Target Milestone: | 3.7 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 191094, 266972, 302122 | ||||||||
| Attachments: |
|
||||||||
|
Description
Tim deBoer
See bug 308313. (In reply to comment #1) > See bug 308313. Actually, it seems the trace is slightly different here. :O Is it possible to get line numbers in the stack trace, or attach a problematic manifest to reproduce the problem? Created attachment 164736 [details]
Manifest
Sorry, adopter product strips line numbers for the minimal performance gain that provides.
I've attached the manifest, but as you can see it's pretty minimal. I had seen the problem after a restart, but do not see it again this morning.
Any update on this defect ? Seems it is a duplicate of bug317237. *** Bug 317237 has been marked as a duplicate of this bug. *** I think we'll need a better test case or line numbers to figure this out. In the example manifest provided, there is no require bundle header. The method from the stack trace returns almost immediately if the header is not found, there are no array accesses before then. Even if the header is present, but contains broken data, I never get an AIOOBE because all of the loops consider the array size. The only place I could see an AIOOBE happening would be if there was a require bundle header, but the bundle description object didn't have the same data (somehow they get out of synch at startup?). In that case, it is possible that there will be an entry in the header array, but there could be no matching entry from the bundle description. This would cause an AIOOBE as the same index is used. If we can't get a reproducible test case, we can guard against this case. Removing the 3.6.1 milestone since we don't have a reproduceable test case for this. Is this continuing to be a problem? Or can a test case be provided? There is clearly a bug here (since two of us hit it in different circumstances, plus several bugs on the blocks/related list), but the frequency is low and I do not have a reproduceable testcase. I didn't see any obvious problems in the UI related to this. In this sort of situation, my advice would be to go ahead with the guard Curtis found via scanning the code and close the bug(s); it's goodness either way, and it's not worth leaving bugs open if we don't have a clear testcase or fix. Time will tell whether the problem goes away after the change, and we can always reopen if we have a reproduceable testcase or more information. Fixed in HEAD. We now check that the length of the required bundles in the bundle description matches the entries in the manifest header. If the counts don't match up, we assume that the bundle description has stale data and do not compare the two. See BundleErrorReporter.java *** Bug 191094 has been marked as a duplicate of this bug. *** *** Bug 266972 has been marked as a duplicate of this bug. *** *** Bug 302122 has been marked as a duplicate of this bug. *** Created attachment 191693 [details]
Patch for 3.6.2+
|