Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 360015

Summary: [flex-hierarchy] NPE when column presentation changes its supported list of column IDs
Product: [Eclipse Project] Platform Reporter: Winnie Lai <wlai>
Component: DebugAssignee: Platform-Debug-Inbox <platform-debug-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: cdtdoug, daniel_megert, Michael_Rennie, pawel.1.piech
Version: 3.7.1Flags: Michael_Rennie: review+
Target Milestone: 3.8 M4   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch for 3.7.x (R3_7_maintenance branch)
pawel.1.piech: iplog-
Patch for master branch
pawel.1.piech: iplog-
Patch with alternative fix (against master). none

Description Winnie Lai CLA 2011-10-05 12:51:48 EDT
Build Identifier: 3.7.1

Expression view throws a null pointer exception after getting updates to 3.7.1 from 3.7.0. This is due to a change of column id. Also, this change also makes plugins compiled against 3.7.0 no longer works in 3.7.1 (see explanation below).

In 3.7.0, the id for expression column (COLUMN_ID_EXPRESSION) was given a literal value of org.eclipse.cdt.dsf.ui.COLUMN_ID__EXPRESSION when 3.7.0 code was compiled. In 3.7.1, the id for the same expression column (COLUMN_ID_EXPRESISION) was given a value of org.eclipse.debug.ui.VARIALBE_COLUMN_PRESENTATION.COL_VAR_NAME when 3.7.1 code was compiled.

Since the value of the column id is bound to a literal value in compile-time, the 3.7.1 code will not treat 'the expression column id compiled from 3.7.0 code' same as 'the expression columnd id compiled from 3.7.1 code', and vice versa. 

There are two impacts I found so far.
1.  The workspace persists data using the literal value of column id as a key. When the expression view layout data (columns, their visibiliteis and widths) is restored from workspace, I get null pointer exception.

2. Even I made my plugin compiled against 3.7.0 code to avoid the null pointer above, I cannot make my plugin automatically work in 3.7.1 environment without recompiling my code and re-delivering my plugin.
This is because some other code in dsf are using the new literal value instead of old literal value. One of the many problems is that the value cells under the column become blank because label providers are registered based on column id.


I would not suggest to revert the id back to the old literal value because it will repeat the same story -- break code upgrading from 3.7.1 to 3.8. Plus, the change is inteneded to take good re-use of many other platform code that uses org.eclipse.debug.ui.VARIALBE_COLUMN_PRESENTATION.COL_VAR_NAME as expression column to implement F2 functionality, new expression dialog, etc.

I would suggest to fix something in InteralTreeModelViewer. One idea is that when viewer cannot configure and build columns from fVisibleColumns, the viewer falls back to use the presentation's initial columns. I think a minor loss of persistence data is better than null pointer and other loss of functionality. 

A better idea is to make viewer know what old id value is equivalent to what new id value.


If this bug is not getting fixed, people will encounter the same issues when they upgrade from 3.7.0 to 3.8.0 final release and so on.


Reproducible: Always

Steps to Reproduce:
1. In 3.7.0, launch dsf debug session.  Open exrpession view, make all columns visible and resize columns so that this layout get stored.

2. Upgrade to 3.7.1. Using the same workspace, open the debug session. Exprssion view will throw a null pointer exception when its layout is being restored for the dsf debugger.
Comment 1 Winnie Lai CLA 2011-10-24 12:53:44 EDT
Created attachment 205848 [details]
Patch for 3.7.x (R3_7_maintenance branch)
Comment 2 Winnie Lai CLA 2011-10-24 15:19:24 EDT
Created attachment 205862 [details]
Patch for master branch
Comment 3 Winnie Lai CLA 2011-10-24 15:23:24 EDT
I submit two patches here, one for 3.7x and the other is for master.
Please review and commit them to the streams. Thanks.
Comment 4 Pawel Piech CLA 2011-10-24 18:34:47 EDT
Created attachment 205871 [details]
Patch with alternative fix (against master).

I thought that the supplied patch was a little bit risky because effectively setVisibleColumns() would be called recursively.  With a badly behaved column presentation this could lead to a stack overflow.

I came up with the patch attached.  Winnie, please let me know if it still addresses the NPE.
Comment 5 Winnie Lai CLA 2011-10-25 12:32:51 EDT
(In reply to comment #4)

Yes, your patch addresses the NPE. Please also merge your fix for 3.7.2.
Thanks.
Comment 6 Pawel Piech CLA 2011-11-04 17:47:00 EDT
I committed the fix with the alternative patch. Mike please take a look at the change.
Comment 8 Michael Rennie CLA 2011-11-14 14:08:15 EST
-1 for this fix.

The code in InternalTreeModelViewer line 1427:

if (header == null) header = id;

could end up setting the name (visible to the user) of the column to be the internal id for the column (i.e. org.eclipse.myproject.column1)

It would be better if we either ignored the bogus column completely (more work required to fix) or any exception in presenting columns simply causes a reset to the initial columns from the presentation. I am leaning more towards opinion 2, that way if the currently cached column infos have any other inconsistencies they are also replaced with the new infos from the column presentation. Either way the user will have to re-configure the columns, so I think we are safe there.
Comment 9 Winnie Lai CLA 2011-11-14 16:13:46 EST
(In reply to comment #8)
> -1 for this fix.
> The code in InternalTreeModelViewer line 1427:
> if (header == null) header = id;
> could end up setting the name (visible to the user) of the column to be the
> internal id for the column (i.e. org.eclipse.myproject.column1)
> It would be better if we either ignored the bogus column completely (more work
> required to fix) or any exception in presenting columns simply causes a reset
> to the initial columns from the presentation. I am leaning more towards opinion
> 2, that way if the currently cached column infos have any other inconsistencies
> they are also replaced with the new infos from the column presentation. Either
> way the user will have to re-configure the columns, so I think we are safe
> there.

Michael,
I am not sure which fix(es) will finally be accepted and get delivered in 3.8 and 3.7.2.

What I want to iterate is, 
1) We want this issue to be fixed in 3.7.2 and 3.8.2. It is ok that they employ two different fixes or the same fix.

2) We want a fix such that it does not require the user manually re-configure the columns of the view. This is the reason the initial proposal/idea is to have the viewer automatically flips to the intital columns, rather than keeping the 'broken' persistent columns.

If the final fix is to require the user to manually re-configure the columns, it defeats the purpose. The reason I say that is, a few customers already hit this NPE in 3.7.1. We expect more and more customers will hit the same problem once they update to 3.7.2 from 3.7.0. Their feedback is they want a solution better than 'asking customers to do something extra'.  Honestly, not many people know they can configure the columns from the view tool bar's pull-down menu.
That also means 'ignoring the bad column' is not acceptable.


Since 3.7.2 will not accept new APIs or so, I submitted a patch for 3.7.x that purely takes the approach of 'flipping to initial columns.' And, Pawel rewrote the patch to avoid any potential trap of infinite call-stack. Pawel's patch at least addresses our main concern.
Comment 10 Pawel Piech CLA 2011-11-15 01:32:17 EST
(In reply to comment #8)
> -1 for this fix.
I updated the getVislbleColumns() call to check for a missing header text, I also added the unit test.  

The only possible down side of this change that I can think of is that a programming error in an IColumnPresentation.getHeader() could cause the view to reset its columns for no apparent user from the end user's POV.  An NPE in the log would actually be healthy in that respect, but it's a minor point.  Thanks for the review and let me know what you think of the update when you get a chance.

http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=183d75523e8723fe50fae8e9a3301aef668dcce8
Comment 11 Michael Rennie CLA 2011-11-15 10:08:49 EST
(In reply to comment #9)
> 
> 2) We want a fix such that it does not require the user manually re-configure
> the columns of the view. This is the reason the initial proposal/idea is to
> have the viewer automatically flips to the intital columns, rather than keeping
> the 'broken' persistent columns.

I agree, and stated that I preferred to default to the initial columns from the presentation in comment #8. Either way though, if a user has customized the set of columns and an exception causes their set of columns to be changed, they will be required to reconfigure them back to the way they had them.
Comment 12 Michael Rennie CLA 2011-12-06 12:46:31 EST
+1 for Pawel's update in comment #10