BUG: Logos crashing (on occasions) when using series and linked sets
[Reposted from another thread as it may be a different issue to that thread]
I have had a few crashes (logs for one attached) which seem to be related to a linking and series issue. I have BHS SESB 2.0 and UBS5 in a series and then linkset them to the NIV. What should happen (and it works most of the time) is that when I move from verse to verse in the NIV, the linkset tracks with the NIV. If I change from OT to NT or vice-versa, then the linked resource will switch to the relevant resource for the testament I am in. Not always, but a couple of times when I have switched from one testament to the other in the NIV (expecting the linked resource to switch from BHS to UBS or vice versa), Logos doesn't do so and then if I go into the tabbed pane, Logos crashes with the attached error:
Error detail: ArgumentException: Resource instances for LLS:UBS5 (2017-03-29T17:53:46Z) and LLS:1.0.204 (2017-10-26T20:42:40Z) do not match. Parameter name: range.
Logos is NOT always crashing but it has done so at least three times with this same error.
Comments
-
Here is another set of crash logs for this problem. I can also give a little more information about the circumstances.
I am running on Windows 10 with Logos 8.0 SR1. There are multiple tabs open in each of 2 panes. In one of the panes I have the NIV linked to the UBS5 text via linkset B (i.e. 2 of the tabs in the same pane - there are other tabs in the pane but the NIV and UBS are the only 2 linked in linkset . The UBS5 text is in a custom series with BHS (using a custom series name of BHS&UBS for both resources). As indicated in the previous email, what should happen is that when I switch between testaments in the NIV, the relevant resource (UBS5 for NT and BHS for OT) will track in parallel with the NIV.
When I start Logos neither the NIV or UBS tab is active. If I switch to the NIV tab and then switch to the UBS tab, making each one active in turn, then switch back to the NIV and put in an OT reference, I can see the UBS tab header changes to BHS and if I then go to that tab, it is showing the right verse in the BHS - this I what I expect to happen.
HOWEVER, If I start Logos and DO NOT switch at all to the UBS tab, but just switch to the NIV and put in an OT reference, I see no change in the header of the UBS. If I then switch to that tab, Logos crashes with the attached log being an example. It does this every time. Something has prevented Logos from 'updating' the UBS tab to BHS and when I switch to it, Logos crashes with the 'resources do not match error' which is probably right because they don't actually match at this point as the custom series link did not 'activate'.
So far, no response from Faithlife to the previously logged BUG (which never occurred in Logos 7).
0 -
I wasn't able to reproduce the crash by following your steps, but I've created a bug report for the problem and let the team know.
0 -
Thanks Bradley
I tried to reproduce the problem by creating a brand new layout but with only 3 tabs in each pane and I could not reproduce the problem.
However, if I go back to my already existing layout which has 16 resources open in the left hand pane (13 in Link set A, and 2 in link set B - The NIV and NHS/UBS5) and 12 resources in the right hand pane (with 8 of them part of link set A), then I can reproduce the problem at will.
Out of interest, I deleted the two resources in link set B and then re-added them then made sure I was located in another tab before restarting Logos. Upon restart, and going to the NIV tab and switching testaments, the linked tab did not switch resources and consequently when I went into that original language resource, once again Logos crashed with the same error.
I wondered if the problem was related to the number of resources open and linked, so I closed all tabs in the right hand pane. Then when I went to the NIV in the left hand pane and changed testaments, I saw the original language resource tab icon change and when I then went into it - no crash. However, if I loaded my saved layout, went to the NIV and changed testaments, then the original language icon did not change (as previously reported) BUT before going into the original language pane, I closed all the tabs on the right. The original language tab icon did not change - without going into it (which I know will cause the crash) I tried changing the NIV reference back and for the between the testaments but the icon in the original language tab never changed. Once I did go into the original languages tab, Logos crashed with the usual error. Conclusion: The number of tabs linked in the original layout WHEN IT IS FIRST OPENED prevents the original language tab switching when the NIV reference changes testaments, BUT if the number of linked resources is reduced BEFORE changing the verse reference, the crash no longer occurs.
To further test this hypothesis I repeated the above scenario of reducing the number of link set A resources, but this time I closed all of the link set A resources in the left hand pane. Having done so, when the verse reference was changed in the NIV, the original language tab changed resources as it should and NO CRASH occurred.
I repeated the test by only closing some of the tabs in link set A in the LH pane. Closing 1, 2, 3 or 4 tabs still caused Logos to crash, but closing 5 or more stops the crash from occurring.
I can also confirm that if I load Logos with my saved layout, do nothing with it, load another saved layout, and then reload the layout causing me problems, I can recreate the crash as outlined above. I can also confirm that once I have deleted sufficient link set A resources to cause the original languages tab to switch resources (and work as it should) a reload of the layout which causes problems (without restarting Logos) no longer causes Logos to crash. Somehow, once the resource starts changing (by reducing the number of linked resources) the problem goes away.
On further testing, it seems that the problem is also related to the fact that the link set B tabs are so far to the right of the pane that they run into the scroll right icon. If the two tabs are moved further left in the pane then the problem does not occur - closing some of the tabs in the earlier test would seem to have stopped the crash by causing the link set B tabs to move to the left and the scroll bar to disappear. It may be that when the tab is partially hidden by the scroll bar, the original language tab fails to switch resources after an initial load. But this behaviour doesn't explain why closing all the tabs in the RH pane and not touching the LH pane also stops the problem from happening!
Bottom Line: The problem is related to the number of linked tabs, the position of the tabs in the pane, the presence of the scroll bar (caused by too many tabs to fit in the pane).
0 -
I roughly re-created your layout with 2 stacked panes on the LHS and 2 stacked on the RHS. My B link set was ESV + (SBLGNT/LHB). Couldn't get it to crash.
You might try creating your layout from scratch.
Dave
===Windows 11 & Android 13
0 -
Thanks for the suggestion Dave - so I recreated the layout from scratch and I can reproduce the problem at will.
To enable Logos personnel to more easily track this problem down the attached zip file contains the details of the layout with the resources I have in each pane and how they are linked along with the Logos.log file and the crash files. I sincerely hope that is enough for them to be able to reproduce the problem and find the cause. I save the layout with the NIV in Link Set B as the 'active' window and the default passage is set to 1 John 1:1.
The problem occurs when you change to an OT reference in the link set B NIV and then try to make the adjacent link set B UBS5 the active panel.
I am running on a Dell Inspiron 15 7000 series with a SSD and a screen resolution of 1920x1080. Content scaling is set to 120% and Program scaling is set to 100%. This means that in the LH pane all the tabs do not fit in the pane with the scroll arrow hard up against the UBS5 link set B tab.
0 -
Bump!
Any response from Faithlife on this issue and the last lot of logs which also provide a detailed scenario on how to reproduce the problem?
0 -
I've passed the bug report on to the team.
0 -
Thanks Bradley - just wanted to make sure that the latest 'report' got looked at as it may help them to reproduce the problem.
0 -
This problem still occurs with 8.1.0.0016. See attached logs for yesterday and today.
0