Community
Participate
Working Groups
The build of the help indicies for Fedora and Debian was disabled until now, because the build hangs or throw an OutOfMemoryException if it tries to build the help indices. I found the code, which is responsible for this problem in HelpIndexBuilder.java. The builder traverse recursive over the children of the topic elements, which it receives from getElementsByTagName . The problem is that getElementsByTagName returns not only the direct children of the XML elements. Instead it returns all children. It turns out that this results in a massive amount of steps.
Created attachment 28854 [details] Patch against the eclipse 3.1.1 tarball to resolve the problem.
Any movement on this?
Stay tuned, we are focused on finalizing API and new feature work for M5; afterwards there will be lots of bug fixing. I'm setting to major so we look at this one early on, it looks fairly major to me.
Will this make it into 3.2?
I'm afraid I didn't get to this one in time for 3.2. Will you be able to work around it ?
Yeah, we have patch. I was just wondering if I would be able to remove the patch for the 3.2 rpm. Will you be able to get to this in 3.3? Perhaps you could set 3.3M1 as a target. Thanks.
We don't have a 3.3M1 target in the list yet, so setting 3.3 for now.
I have reviewed and tested the patch and it looks fine. While there wasn't a huge impact on the platform user docs which I was testing on, I can see that the memory and time usage would increase very quickly with the size and depth of the topic tree (i.e. something like exponential). The patch has been applied to a branch which will eventually merge with HEAD for 3.3 M1. Thanks for the help on this one guys.
Hi, I know that this is resolved. I just have two small questions about the description and whether this fix might fix something that my team has noticed on AIX. The bug report says "returns not only the direct children of the XML elements. Instead it returns all children." Does that mean that the recursive travel was over all subtopics underneath a topic, as deep as it would go, instead of the immediate direct children? Was it supposed to only get the immediate children? On AIX, when trying to create the pre-built search indexes for 14 or so locales at once, we would get OutOfMemory errors and java heap dump. I suspect that the ToC trees had many depths. Is it likely that the fix for this bug will fix that behavior? Thanks! If you can't tell whether it is the same symptom, that is OK. This one just caught my eye as being similar, so I thought that I would ask. --Lee Anne
It does sound like the same problem. It was indeed only supposed to return the direct children, it was part of a recursive call that was supposed to recurse down one level at a time. Instead, it would call itself on every descendant and each descendant would in turn recurse through all its descendants, and so on which can quickly get out of hand for deep tocs. Note that it depended on the depth and size within a single toc XML file, not the combined depth after all the tocs have been assembled into a larger toc.
Moving to new M1 milestone
Hi Curtis, Can this make it into 3.2.2? Thanks, Andrew
I have released the fix for 3.2.2. Seems safe since it's a very localized change and we've had several 3.3 milestones to test it, and found no problems.
(In reply to comment #13) > I have released the fix for 3.2.2. Awesome, thanks, Curtis!
