MySQL Bugs: #55996: System.IndexOutOfRangeException = Index was outside the bounds of the array.

Bug #55996	System.IndexOutOfRangeException = Index was outside the bounds of the array.
Submitted:	16 Aug 2010 2:40	Modified:	16 Aug 2010 4:11
Reporter:	Roel Van de Paar	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S1 (Critical)
Version:	5.2.26	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Found while testing for bug #55776 and bug #55304. Crash happens in same location, just with a different message. I think quite some bugs here are connected/related/may have the same source.

----
Exception = System.IndexOutOfRangeException
Message = Index was outside the bounds of the array.

FullText = System.IndexOutOfRange
Exception: Index was outside the bounds of the array.
   at Aga.Controls.Tree.TreeViewAdv.CreateRowMap()
   at Aga.Controls.Tree.TreeViewAdv.UnsafeFullUpdate()
   at Aga.Controls.Tree.TreeViewAdv.FullUpdate()
[...]
----

How to repeat:
See video: https://steam.mysql.com/~rvandepaar/BUG55776_and_BUG55304/55776.html - the exact same test/action lead to this error message.

Yet another crash at the exact same point, but from a slightly different test case (swap back to home tab first, re-do part of the testcase):

-----
Exception = System.Argument
Exception Message = Value does not fall within the expected range.

FullText = System.ArgumentException: Value does not fall within the expected range.
   at Aga.Controls.Tree.TreeViewAdv.ScrollTo(TreeNodeAdv node)
   at MySQL.GUI.Workbench.UndoHistoryForm.UpdateHistoryTree()
   at MySQL.GUI.Workbench.UndoHistoryForm.invokeRefresh(NodeId node, Int32 oldCount)
[...]
-----

Workbench trace of first crash

Attachment: wb trace.txt (text/plain), 2.23 KiB.

Workbench trace of second crash

Attachment: wb trace 2.txt (text/plain), 2.04 KiB.

Windows trace of first crashs. Same "An invalid HANDLE was specified." issue.

Attachment: windows trace.txt (text/plain), 33.24 KiB.

Windows trace of second crash. Same "An invalid HANDLE was specified." issue.

Attachment: windows trace2.txt (text/plain), 0 bytes.

Verified based on the fact that the issue seems well-defined now ("An invalid HANDLE was specified.") and repeatable in a sense that the crash almost always happens, and almost always in the same place, albeit with different errors, the two above just being two examples of the same. When the issue is thought fixed, I can re-test using automatic test script now.

I think the issue is Workbench-initiated but possibly Windows-discovered leading then again to a Workbench-error (ref below).

From looking at this issue, having seen the different crashes, here's my attempt at writing what I think is happening:

1. Define a new tab ("EER model 1"), this updates some sort of tab/window handle array (handle being the handle to that window or tab)
2. Delete this new tab ("EER model 1"), this updates the same array
3. Create a new tab using Model > "Create diagram from catalog objects", this would create a new tab/window, so updates the same array again
4. Some sort of "windows/tab handle" array failure happens (are the handles to tabs stored in an array?) inside Windows. I think it's related to Windows because of the following (from my note on bug 55776):

------------
0:000:x86> !gle -all
Last error for thread 0:
LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
LastStatusValue: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.
[...]
Last error for thread 6:
LastErrorValue: (Win32) 0x578 (1400) - Invalid window handle.
LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
[...]
Last error for thread 7:
LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
LastStatusValue: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.
------------

And also since the Windows traces seem to specify mostly Windows call stacks.

Note that threads 0 and 7 seem to have a Windows problem while thread 7 seems to have a in-application error.

So it looks like somewhere there is an issue in the tab/window "handle" handling.

Though, this issue seems related to the "description editor" issue also: why does it mark "multiple items" in the description editor when swapping back to the MySQL model tab before an action is finished - this should not be the case. I may do some more testing to see if I can exclude one from the other.

I am quite convinced that the following bugs:

bug #55304 | bug #55776 | bug #55904 | bug #55774 | bug #55828 | bug #55996

all have the same cause: some sort of issue with window/tab handles (note the "An invalid HANDLE was specified."). 

For more information, see the "[16 Aug 5:30] Roel Van de Paar" comment in bug #55996.

I am marking this bug as a duplicate of bug #55304 as that was the main one in which this issue was handled.