Community
Participate
Working Groups
This is a HUGE issue. I ran into this bug after using what was my own Module Type. It would not load the resource, which had JUST been saved. I have *no* idea how this actually is functional code for the rest of WTP, but it is, and this baffles the hell out of me. Summary: saveResource(etc) is writing 0 as the size EVERY time. It is still WRITING all of the resources, but declaring size to be 0. Then upon loading the resource, it finds size = 0, and doesn't read the next batch of bytes. How did this ever make it into releases, and how does this actually work?! protected void saveResource(DataOutput out, IModuleResource[] resources2) throws IOException { if (resources2 == null) return; int size = resources2.length; /* NOTICE it writes a zero? The first byte saveResource writes out is a 0. */ out.writeInt(0); /* BUT it still LOOPS THROUGH to save the module files */ for (int i = 0; i < size; i++) { if (resources2[i] instanceof IModuleFile) { IModuleFile file = (IModuleFile) resources2[i]; out.writeByte(0); out.writeUTF(file.getName()); out.writeLong(file.getModificationStamp()); } else { IModuleFolder folder = (IModuleFolder) resources2[i]; out.writeByte(1); out.writeUTF(folder.getName()); IModuleResource[] resources3 = folder.members(); saveResource(out, resources3); } } } /* NOW comes loading the resource */ private IModuleResource[] loadResource(DataInput in, IPath path) throws IOException { /* It reads the first byte AS A SIZE... and 0 is the size. */ int size = in.readInt(); IModuleResource[] resources2 = new IModuleResource[size]; /* Because the first byte is 0, it does NOT loop through and read the rest of the resources!!! */ for (int i = 0; i < size; i++) { byte b = in.readByte(); if (b == 0) { String name2 = in.readUTF(); long stamp = in.readLong(); resources2[i] = new ModuleFile(name2, path, stamp); } else if (b == 1) { String name2 = in.readUTF(); ModuleFolder folder = new ModuleFolder(null, name2, path); folder.setMembers(loadResource(in, path.append(name2))); resources2[i] = folder; } } return resources2; }
Created attachment 90430 [details] Patch to fix this egregious error write size instead of 0
Created attachment 90648 [details] Proposed patch This bug was caught in the 3.0 stream via bug 212075 in December, but wasn't backported to 2.0.2. The previous patch fixed the root problem, but the bug can also cause OutOfMemoryErrors when reading data from existing 2.0 and 2.0.1 workspaces. I am backporting the full patch that will handle this initial 'migration' as well, and once we've done a successful publish the file is saved correctly.
Raising hotbug for WTP 2.0.2 PMC approval. This bug causes the 'publish history' to be saved incorrectly in WTP 2.0 and 2.0.1. This causes a couple problems: * Publish history is not saved, so the first publish after restarting WTP is always effectively a full publish. At best this is just a performance impact (the first publish is slow even though the user hasn't changed any files), but there is a message to the .log and it could be worse for some server adapters. * In rare cases, reading the corrupt history file can cause an OutOfMemoryError. It was caught and fixed for 3.0 in December but missed backporting. The attached patch is the full fix from 3.0 that has passed testing for 2 milestones.
I'm afraid I must be negative on this one. TODAY is our delivery day, and we can't change the code on the same day we are delivering. I think only option, if we found a "burn down the computer" bug is to ask Europa maintenance to be delayed. The schedule has been well known for quite a while, so afraid we'll have to do something else for this late reported bug. See http://wiki.eclipse.org/Europa#Coordinated_Maintenance
not to be overly dramatic, but I do kinda consider allocating 1.6 billion objects when trying to load module publish states to be critical ;) What is the process to ask for Europa maintainence to be delayed?
(In reply to comment #5) > > What is the process to ask for Europa maintainence to be delayed? > To convince a project lead to convince their Eclipse planning representative to discuss with the Eclipse Planning Council.
Hi Rob, It would probably help if you can explain the significance of this bug to you - why you raised it as a hot bug in the first place. This bug causes a full publish the first time after opening a new workspace (which is poor, but we've had no complaints about poor initial performance), and it has the chance of causing an OOME (but we've only had one report in over a year). Can you explain why these symptoms are more severe for you, or if you're seeing other bad behaviour?
Hi Tim: The behavior I'm seeing has to do with the loadResource method, and the issue *is* very severe. Specifically, because it's reading in a "0" as a size when what was should have been written (in my case) was a 1, the load loop is skipping over the resources which WERE written. Meaning, when reading the second module, it is *actually* reading data from the first module's resource info. This leads to size having a wildly incorrect value: int size = in.readInt(); In my case, size is 1.6 billion, which invariably causes a heap error. In my workspace, it's happening very very often, which makes it impossible for me to test functionality in our downstream product (not to mention makes the product itself fairly unusable ;) ) If this was only regarding the full publish upon startup, I would not have raised this as a hotbug. Instead, I was forced to raise it because of the heap errors being thrown every startup. Hope this clarifies the issue.
Yes, thank you. It wasn't entirely clear to me if you were hitting an OOME related issue or if this was just an initial publish issue. I've had an offline discussion with David and Helen, and I think the general opinion is that the 2.0.2 train has already left the building; we've simply missed the chance to safely get this into 2.0.2 and it is extremely unlikely we'd get agreement to move the coordinated Europa maintenance dates. If there is still a chance we'll take it, but otherwise we hope to provide an official patch shortly after 2.0.2.
Moving to 'fixed'. In patch builds >= P20080313153530. Plan to put on official update site on Friday, if no issues found with smoke testing. If applicable, please be sure code is updated in 3.0 stream.
Closing bugs that have been fixed for several months without owner verification. Bugs that did not involve external user/adopter scenarios have been verified in WTP. We are about to release WTP 3.0, please feel free to reopen if you have any further problems.
The patch was included in 2.0.3 release.
