This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 187460 - Sessions view Name column jumps to position 1
Summary: Sessions view Name column jumps to position 1
Status: VERIFIED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: -S1S-
Hardware: All All
: P2 normal (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks: 178859
  Show dependency tree
 
Reported: 2010-06-11 03:02 UTC by ivan
Modified: 2010-07-09 06:58 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2010-06-11 03:02:59 UTC
This is a distillation of causes for bug #178859 which 
impacts solstudio testing (hence the p2).

Because of the complexity of debugger spi it's impossible for me to
come up with a simple reproducible testcase. If the following
description of my findings doesn't help, you can get the solstudio IDE
repository from within the swan and build it yourself (send me email directly).

setting:
- add additional columns to the sessions view of a debugger.
  Implement these:

    public void setCurrentOrderNumber(int newOrderNumber) {
	properties.setInt (getID () + ".currentOrderNumber",newOrderNumber);
    }
    public int getCurrentOrderNumber () {
	return properties.getInt (getID () + ".currentOrderNumber",-1);
    }
-scenario:
- start IDE with a clear userdir.
- open a project 
- put a breakpoint
- -POINT1- open the sessions view 
- start debugging
- -POINT2- bring the session view to the front again .
  Notice that the (default) Name column is not the first column.
  It's order in the visible columns panel is not at location 0 either!

Now debugging the IDE here's what I found:
Put a bpt in OutlineTable.createColumns().
Skip it until it's called during -POINT2-.
Here 'cs' contains something like this:
    0        PID
    1        SessionState/process State
    2        Debug Engine SESSION_DEBUGGER_COLUMN_ID
    3        SESSION_LOCATION/Executable
    4        SESSION_MODE/Mode
    5        SESSION_CORE/Corefile
    6        SESSION_HOST/Host
    7        DefaultSessionColumn/Name       defaultColumnIndex
Note how DefaultSessionColumn/Name is the last item.
All of these but the last one have a "type" so they get added to
columnList. The last one doesn't so we take the else where 'addDefaultColumn'
is set to false. I.e. we discovered the default column.
Stepping further it turns out its getCurrentOrderNumber() is already
0 and not -1. This is probably because it was assigned earlier at -POINT1-.

And because of that the columnVisibleMap shift doesn't happen!

We end up with a columnVisibleMap that looks like this:
    0: 0        <- this one is set because it's order number is still -1
                   so get's assigned linearly (using 'i').
    1: 1        <- same thing here
    ...
    6: 6
    7: 0        <- here orderNumber is 0 so it stays as 0 as opposed
                   to getting assigned from 'i'.
I.e. two columns are assigned to the same location: 0

Then checkOrder() gets called and it tries it's best but 
mangles columnVisibleMap into this:
    0: 0
    1: 2
    2: 3
    ...
    6: 7
    7: 1
which says the default column, 7, is at position 1 and not 0 as is 
expected.

I would summarize the problem as follows:
OutlineTable.createColumns() assumes that orderNumbers are assigned all
at the same time. But in our scenario at -POINT1- order numbers 
get assigned to the Name column, then at -POINT2- order numbers
get assigned to engine-specific models and things get confused.

I tried the same scenario with some other views/models that we have, which
have additional columns, but it's only the sessions view that seems to 
suffer from this. 
I also checked the ordering of the items in the 'cs' parameter to 
createColumns() for some other models. I figured maybe if the
default column is at cs[0] then createColumns() doesn't get confused ...
but there were some models with the default column not at cs[0] but
they _didn't_ get jumbled up.

Happy fixing :-)
Comment 1 Martin Entlicher 2010-06-17 07:15:12 UTC
This is a problem in spi.viewmodel module, which is historically tracked under debugger component.

When we switched from TTV to Outline, the column order management had to become much more complex. I'll try to simulate this use-case in NetBeans, I should be able to do it following your description, if I could not reproduce it, I'll let you know.
Comment 2 Egor Ushakov 2010-06-17 12:44:33 UTC
I've seen this once or twice in Netbeans
Comment 3 Martin Entlicher 2010-06-21 13:54:23 UTC
I did not reproduced this in NetBeans. But thanks to the detailed description I hope that I've fixed it.
changeset:   173311:ea51e8d46833
http://hg.netbeans.org/main/rev/ea51e8d46833

Please verify if it solves the problem for S1S. I suppose that you need the fix in NB 6.9.1?
Comment 4 Alexander Pepin 2010-06-21 14:21:26 UTC
I will verify the fix as soon as it appears in trunk.
Comment 5 Quality Engineering 2010-06-22 03:19:48 UTC
Integrated into 'main-golden', will be available in build *201006220001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ea51e8d46833
User: mentlicher@netbeans.org
Log: #187460 Prefer order of columns that had it set explicitly.
Comment 6 ivan 2010-06-22 04:23:26 UTC
It seems to work for me.
But I'd like a second set of eyes to look at it before marking it as verified.
Comment 7 ivan 2010-06-22 20:08:24 UTC
I'd like to nominate this for 6.9.1.
It impacts primary functionality of solstudio debugger.
Comment 8 Martin Entlicher 2010-06-23 12:54:15 UTC
O.K. Marking as 6.9.1_CANDIDATE. Ivan, please mark this issue as verified and we can merge it into release691 then. Thanks.
Comment 9 rbalada 2010-06-24 09:54:43 UTC
main #ea51e8d46833 transplanted to release691 #e2dc03ff0b81
Comment 10 Marian Mirilovic 2010-07-09 06:58:37 UTC
The changeset is available in 691 repository http://hg.netbeans.org/release691/rev/e2dc03ff0b81, I am not able to reproduce original issue, neither simulate in NB 6.9 ... so verified by applying patch.