If you found a bug post here your report.
Unhandled Exception of SPS package manager
|
chef Posts: 47
27/06/2019
|
After three times using SyMenu resp. SPS package manager update mechanism for the tools included locally, I get the following unhandled exception error of SPS package manager to process on index beyond range!: See enclosed attachement.
I don't remember if I encountered it after finishing these updates or if it was after I asked SPS package manager to refresh its processing list with the unchanged criterie (updates). Updateing succeeded for 59 out of 60 installed packages with one timeout error for update.
I still didn't get notified about a fix or solution to that timeout error. Gians recommended work around though did work well.
I choose to proceed anyway with the unhandled error as shown in the attached screenshot  .
|
|
|
link
|
|
chef Posts: 47
30/06/2019
|
chef wrote:
I don't remember if I encountered it after finishing these updates or if it was after I asked SPS package manager to refresh its processing list with the unchanged criterie (updates). Updateing succeeded for 59 out of 60 installed packages with one timeout error for update.
This bug is still present and reappeared today. And I can report that it wasn't on finishing the update but afterwards when asking SPS package manager to update its list of still not yet successfully processed SPS packages.
Here you'll find that what looks like a trace stack, if this helps for analysis. It further sounds that the index would have a value either too low or negative. Do you want me to follow the instructions to enable JIT-Debugging in preparation for the next occurance?
And do you also want the used assembly list? If yes, I prefer sending by PM instead of post, just in case of need and interest.
************** Ausnahmetext **************
System.ArgumentOutOfRangeException: Der Index lag außerhalb des Bereichs. Er darf nicht negativ und kleiner als die Sammlung sein.
Parametername: index
bei System.Collections.ArrayList.get_Item(Int32 index)
bei System.Windows.Forms.DataGridViewRowCollection.SharedRow(Int32 rowIndex)
bei System.Windows.Forms.DataGridViewRowCollection.get_Item(Int32 index)
bei SyMenu.FormSPSMain.(DataGridViewRowCollection , Int32 )
bei SyMenu.FormSPSMain.GetSPSElementFromDataRow(Int32 index)
bei SyMenu.FormSPSMain.gridSPSPrograms_SelectionChanged(Object sender, EventArgs e)
bei System.Windows.Forms.DataGridView.OnSelectionChanged(EventArgs e)
bei System.Windows.Forms.DataGridView.FlushSelectionChanged()
bei System.Windows.Forms.DataGridView.ClearSelection()
bei SyMenu.FormSPSMain.(DataGridView )
bei SyMenu.FormSPSMain.ResetForm()
bei SyMenu.FormSPSMain.TabControlResize(Boolean expand)
bei SyMenu.FormSPSMain.SearchWithFilter()
bei SyMenu.FormSPSMain.btnFilterSearch_Click(Object sender, EventArgs e)
bei System.Windows.Forms.Control.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
bei System.Windows.Forms.Button.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
|
|
|
link
|
|
chef Posts: 47
30/06/2019
|
As far as I understood, I still don't have the source of this project nor did I ask for. I only report what I observe that SyMenu resp. its SPS package manager report. This SPS package manager reporting gives some hints about internal code but doesn't mean I have it as could be a possible misunderstanding by Gian. It's still up to him to analyse and request what kind of context information might be helpful for identifying what happened, what the reasons and the root cause are and how to fix it unto when he may find time. Just my note after using SyMenu just a few times within a week and still progressing slowly on customization.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
01/07/2019
|
chef wrote:
This bug is still present and reappeared today. And I can report that it wasn't on finishing the update but afterwards when asking SPS package manager to update its list of still not yet successfully processed SPS packages.
Who did ask to the SPS Manager to update the list? Was it you? Because the SPS Manager updates by itself whenever it finishes the update/installation/delete process.
If you force the update you are forcing the update of the programs definitions not only the list update.
So does this bug appear after the automatic (local) refresh or your forced (online) refresh?
Does it always appear or occasionally?
edited by Gianluca on 01/07/2019
|
|
|
link
|
|
chef Posts: 47
01/07/2019
|
Gianluca wrote:
chef wrote:
This bug is still present and reappeared today. And I can report that it wasn't on finishing the update but afterwards when asking SPS package manager to update its list of still not yet successfully processed SPS packages.
Who did ask to the SPS Manager to update the list? Was it you? Because the SPS Manager updates by itself whenever it finishes the update/installation/delete process.
If you force the update you are forcing the update of the programs definitions not only the list update.
So does this bug appear after the automatic (local) refresh or your forced (online) refresh?
Does it always appear or occasionally?
edited by Gianluca on 01/07/2019
Sorry that I wasn't precise enough. What I meant and did was not to request an update (in the sense of reload) of SPS definitions. It was just an update of that list to process instead. The corresponding action button carries the localized label for search. As far as I can see, the action of this button is as expected, not to update the SPS definitions but to reapply the filter criteria to the displayed list as the automatic update of that list kept the processed element on that list although no longer complying to the specified filter criteria. The manual is a bit short on this feature in the section filter.
The automatic update of the list by SPS package manager seems inconsequent. It doesn't change the size of the list. It just changes the state of that package although with changed state it no longer complies with the search criteria defined on the right column called filter in the manual. This choice also allows some post processing of the just processed element resp. tool to be initiated by myself without any intermediate steps. So this inconsequence is meaningful.
I don't like the default search criteria. And I didn't look up if that default may be reconfigured to one of my preferences. And the manual doesn't explain one difference letting me assume what is meant. The terms in my language don't correspond to the terms in the manual! It might even be that the localized terms are even better than those in the manual. The localized version of SPS package manager doesn't tell which term is used for updated tool version and which term for updates SPS definition, assuming the term update meaning the first case (updated tool version). (According to the figure in the manual, the international non-localized version seems to use the term added where the localized one uses update and the international version seems to use the term update where the localized one us something like refreshed. Is this an error in the manual? The comparison between localized version and manual confuses at this point of the manual.)
This inconsequence is fine. It gives me the choice when I want which kind of update of the list. Such a post processing might be some customization, some configuration or immediate execution. Without this inconsequence, post processing would require to search again for the already processed element with different filter or search criteria which would take longer.
So the automatic local refresh happened before the described symptom. And I don't know if this symptom would also appear with forced online refresh. I didn't try. What may be possible is that the internal data structures handle this inconsequence differently, being more consequent on internal data structure then on display and perhaps not providing a field for that difference between display and internal data structure. That would explain the debugger output probably meaning off by 1 corresponding to the list one field longer then the filter criteria would expect. So I don't expect that symptom to appear in the context of forced update of SPS definitions after automatic local refresh list.
So yes, it was me who decided and requested an update of that list to process in order to recomply with the filter criteria as I decided that I finished the update of the just processed tool (resp. former list element still being displayed as part of that list although no longer complying to the filter criteria) so wanting to have a again the list with still unprocessed tools (resp.list elements). This has nothing to do with an update resp. refresh of the SPS package definitions.
And as reported initially, this symptom comes irregularly. Common context criteria are that there are several tools available for update and updating doesn't succeed for all of them. Usually, there remain more than one tool not updated when the described symptom appears. But if I remember right, this doesn't forcibly lead to the described symptom, only sometimes. I still have no clue what triggers it or what additional constraints like race conditions have to be reached as constraints to make it reproducable. (Race conditions are difficult to identify.) That's why I asked if you ask me to prepare to follow the instructions of the debugger to get not just symbolic trace but also the corresponding parameters. That's at least as I understood the debuuger annex with instructions not posted as it is reported in localized language.
|
|
|
link
|