Community
Participate
Working Groups
1. Place the cursor on a method or constructor name that is called from one or more places in the code. 2. Select Open Call Hierarchy from the context menu. At this point the Call Hierarchy view should show all the callers of the selected method. Since I installed 3.1M4 (upgraded from 3.1M3) I have noticed that sometimes only the selected method is shown in the Call Hierarchy view. If I run the operation a second time, all the expected callers show up in the Call Hierarchy view. The same is sometimes true when expanding a caller node. The expanded node may appear empty, but after rerunning the operation, that node will exand to show its callers. As of yet, I have not recognized any pattern to make the problem consistently reproducible.
Move to JDT/UI. Please try to find a scenario to reproduce this issue (I never got it after many tries)... This would help a lot to fix it. Note that I've tried on WinXP... perhaps a platform issue?
Markus, we should try to understand this for 3.1. Could be the fact that we fetch the result in background a problem here. Frederic, this could also be a search bug since all call hierarchy does is searching for references.
I agree, but as far as I know, when there's a JDT/Core problem, search always fails. So, that's why my first assumption was about an UI issue (JDT or Platform) as in this case it sometimes works and sometimes does not. Of course, this assumption might be wrong...
I still haven't been able to determine a consistently reproducable test case. However, the comment about the search being run in the background got me to thinking that I should note that my machine is a dual Xeon with HyperThreading (shows up as four processors to the system). If the cause of the problem is due to thread coordination, it is possible that the problem may only show up on an SMP machine and may not be reproducable on a non-SMP machine. That might explain why you can't reproduce it if you don't happen to have an SMP machine. I will keep trying to find a consistently reproducable case.
I've had some success reproducing the problem if I call Open Call Hierarchy repeatedly in rapid succession. The call is bound to Ctrl+Alt+H. If I hit the hot key a few times quickly, I usually end up reproducing the problem. It doesn't seem to matter what method I'm selecting, as far as I can tell. I don't know for sure that the timing matters, it's just how I have been able to reproduce it fairly consistently.
I can reproduce the problem in I20050126-0800 with steps from comment 5 (rapid succession of Ctrl+Alt+H). I'll look into this.
I'm not positive I am seeing exactly the same cause of this problem but it seems that if I have many files open in my workspace, greater than ~18, the call hierarchy stops working. Searche also fail to provide any results. If I exit eclipse, delete the workspace, and then import the project again, everything works. This has happened many times already but at least I know how to get it working again. I'm running version 3.0.1 on RedHat linux 3.0 EL. I hope this helps.
Mike, your comment 7 does not seem to be related to this bug. If you still see that problem, please open a new bug report for it.
I can only reproduce when I manually collapse the node that currently shows the pending ellipsis. Moving milestone to 3.2 for further investigation.
I've never manipulated the tree while the search was taking place and the problem still occurs in 3.1M7. I just tested with org.apache.regexp.CharacterIterator.substring(int, int). The first call to show the call hierarchy failed, the second succeeded. Nothing other than waiting for the results to show occurred during the processing of the call. Given that there's no way to know that the call failed and that the penalty is incorrect information, it seems problematic to defer this. I for one use this feature heavily to understand how and where a method is being used before altering or deleting a method. The effect of this bug (if I didn't know the feature was broken) is that I might delete or alter in an incompatible way a method that I thought (incorrectly) had no callers.
I could not reproduce on my single-processor WinXP box. I *could* reproduce this about every fifth time on a dual processor Linux-GTK with these steps: 1. open java.math.BigInteger 2. select floatValue() 3. press Ctrl+Alt+H 4. repeat 3. until the call hierarchy does not show any children below the root node. Sometimes, I needed about 20 repetitions, and sometimes, it already failed at every second try. This is a concurrency issue with the TreeViewer and/or the DeferredTreeContentManager. I added printLn statements and verified that the call hierarchy's DeferredMethodWrapper#fetchDeferredChildren(..) returns the right children even when they are not shown afterwards. I set a breakpoint in AbstractTreeViewer#internalRemove(Object[]) inside the third line of: if (!getExpanded(parentItem) && getItemCount(parentItem) == 0) { // append a dummy if necessary if (isExpandable(parentItem.getData())) { newItem(parentItem, SWT.NULL, -1); } else { // XXX: Workaround (PR missing) tree.redraw(); } } The children are exactly then not shown, when this breakpoint is hit. Moving to Platform/UI.
I can reliably reproduce something similar on a freshly installed 3.1 (and also 3.2M2) installation. Open source for org.eclipse.ui.views.properties.PropertySheetViewer Find callers of activateCellEditor(TreeItem item). It does not find any caller, although there is (at least) one, in PropertySheetViewer.handleSelect(). This is on Eclipse 3.1.
Comment 12 is unrelated to this bug. I opened bug 109053.
I got methods like public String getId(), which are often (1049) referenced in workspace, but call hierarchy shows me none. the call hierarchies of other methods do behave normal. Reducing the search scope (in the call hierarchy view menu) from workspace to hierarchy leads to a reasonable call hierarchy. So a hypothesis might be that there are too many callers of a method in a search scope. We are using 3.1 on XP Professional, same reproducable behaviour in two development environments.
I wasn't able to reproduce this without collapsing the root node while the results are being calculated (see comment #9). Moving to M5 to fix at least this issue.
The behaviour described in comment #9 (collapsing a node while its children are being computed) is due to a bug in JDT. If I add another case to the if statement in CallHierarchyContentProvider.hashChildren() as follows, the bug goes away. I am not sure if this causes the original problem as well, but it would not surprise me: else if (element instanceof DeferredMethodWrapper) { // Err on the safe side by returning true even though // we don't know for sure that there are children. return true; } Also, while I was looking at the code, I found that whenever you pressed Ctrl-Alt-H, children were computed two times, once for the old root node of the viewer, and once for the new one. This is due to the fact that you call setSorter() before setting the input to the new input in CallHierarchyViewPart.updateView(). Since calling setSorter() causes a refresh, you should set the input to null before you set the sorter, e.g. like this: String[] args = new String[] { elementName, scopeDescription}; // set input to null so that setSorter does not cause a refresh on the old contents fCallHierarchyViewer.setInput(null); if (fCurrentCallMode == CALL_MODE_CALLERS) { setContentDescription(Messages.format(CallHierarchyMessages.CallHierarchyViewPart_callsToMethod, args)); fCallHierarchyViewer.setSorter(new ViewerSorter()); //bug 111423: sort caller hierarchy alphabetically fCallHierarchyViewer.setMethodWrapper(getCallerRoot()); } else { setContentDescription(Messages.format(CallHierarchyMessages.CallHierarchyViewPart_callsFromMethod, args)); fCallHierarchyViewer.setSorter(null); fCallHierarchyViewer.setMethodWrapper(getCalleeRoot()); }
s/hashChildren/hasChildren/ :-)
Thanks Boris, I'll look into it again.
Boris, I released the fixes you suggested. This solves the problem of missing children, but does not solve the problem that the node is sometimes collapsed on a dual processor machine. However, with the fixes, the user can now expand the node at no additional cost if this happens, so I'll close this bug. Opened bug 133490 for the remaining (minor) problem.
verified in I20060330-0010
