Crash when WritingSystemStore has any .ldml files in it

[bbryson]

Presumably because of a change in the WS library for FLEx, it is now the case that we can't start Solid if there are any .ldml files in the folder:

C:\ProgramData\SIL\WritingSystemRepository\3

Well, for some users the crash only happens if there are writing systems with names that are too long, or have variant modifier tags that are too long. For me, it happens if there are any .ldml files. The workaround is that we make sure FLEx is closed, and we delete all the files in this folder, and then start Solid.

If we try to start it we get a crash. I'll paste the crash report into a comment.

I don't know if anyone uses the writing system capability in Solid at the moment.

[bbryson]

Please e-mail this to solid@projects.palaso.org Msg: The given key was not present in the dictionary. Source: mscorlib Assembly: mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Stack: at System.Collections.Generic.Dictionary2.get_Item(TKey key) at SIL.WritingSystems.LdmlDataMapper.ReadKeyboardElement(XElement externalResourcesElem, WritingSystemDefinition ws) at SIL.WritingSystems.LdmlDataMapper.ReadTopLevelSpecialElement(XElement specialElem, WritingSystemDefinition ws) at SIL.WritingSystems.LdmlDataMapper.ReadLdml(XElement element, WritingSystemDefinition ws) at SIL.WritingSystems.LdmlDataMapper.Read(String filePath, WritingSystemDefinition ws) at SIL.WritingSystems.GlobalWritingSystemRepository1.UpdateDefinitions() at SIL.WritingSystems.GlobalWritingSystemRepository1.Save() at SIL.WritingSystems.Migration.LdmlInFolderWritingSystemRepositoryMigrator.ResetRemovedProperties(IWritingSystemRepository repo) at SIL.WritingSystems.GlobalWritingSystemRepository.InitializeWithBasePath(String basePath, Action2 migrationHandler) at SolidGui.AppWritingSystems.get_WritingSystems() at SolidGui.MarkerSettings.MarkerSettingsListView.MakeWritingSystemLinkLabel(String writingSystemId) at SolidGui.MarkerSettings.MarkerSettingsListView.FillListItem(KeyValuePair`2 pair, GLItem item) at SolidGui.MarkerSettings.MarkerSettingsListView.UpdateDisplay(Boolean fullRefresh) at SolidGui.MainWindowView.UpdateDisplay(Boolean fullRefresh) at SolidGui.MainWindowView.OnFileLoaded(String filename) at SolidGui.Program.TryToOpen(String fileName, MainWindowPM model, MainWindowView form) at SolidGui.Program.Main(String[] args) Thread: Thread UI culture: en-US Exception: System.Collections.Generic.KeyNotFoundException

--Error Reporting Properties-- Version: Version 0.21.3 (apparent build date: 21-Feb-2018) CommandLine: "C:\Program Files (x86)\Solid\Solid.exe" "C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid" CurrentDirectory: C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus MachineName: ILS-BRYSONB OSVersion: Windows 10 DotNetVersion: 4.0.30319.42000 WorkingSet: 29188096 UserDomainName: ILS-BRYSONB UserName: Beth Bryson Culture: en-US KeyboardAdaptors: WinKeyboardAdaptor

--Log-- Friday, March 22, 2024 9:33:29 PM App Launched with ["C:\Program Files (x86)\Solid\Solid.exe" "C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid"] 9:33:29 PM Keyboard adaptors in use: WinKeyboardAdaptor 9:33:29 PM Loading Solid file from C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid 9:33:30 PM Loading Solid file from C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid 9:33:30 PM Opening C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.txt 9:33:32 PM Done Opening. 9:33:33 PM Exception: The given key was not present in the dictionary. Details of most recent events: 9:33:29 PM App Launched with ["C:\Program Files (x86)\Solid\Solid.exe" "C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid"] 9:33:29 PM Keyboard adaptors in use: WinKeyboardAdaptor 9:33:29 PM Loading Solid file from C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid 9:33:30 PM Loading Solid file from C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.solid 9:33:30 PM Opening C:\Users\Beth Bryson\Documents\Info\Data\LgData\Tetun Dili\Test-2024.03.20-CheckStatus\TD37.txt 9:33:32 PM Done Opening. 9:33:33 PM Exception: The given key was not present in the dictionary.

To Reproduce:

[megahirt]

I don't know if anyone uses the writing system capability in Solid at the moment.

Can you say more about what the "writing system capability" is in Solid? I don't know myself.

[bbryson]

When I said, "I don't know if anyone uses the Writing Systems capabilities in Solid", I was referring to a couple things:

1. There is the option in the settings dialog for each field to indicate what WS that field is in (see graphic). Solid also tries to detect (or asks) if it is in UTF-8 or some other encoding.
2. This information can be helpful to the person working on the file, as an indication of what kind of field it is, or a clue about where it might fit in FLEx.
3. It also definitely comes into play if anyone does "File/Export as LIFT". However, that functionality does not currently output well-formed LIFT, and it is deprecated. That is, we recommend that people not use it.
4. Although the WS info in the settings could be useful to someone preparing for import to FLEx, for my own work, I find it busy work to fill it all in, especially since I have to do exactly the same settings in the FLEx import wizard. I don't want to have to do it twice. We could maybe survey other users, but this is my take.

On one hand, I feel like we don't need this stuff, but on the other hand, ripping it out could in fact be far more work than expected.... It may be the case that simply recompiling with the latest libraries will be sufficient to stop the crash. I really don't think an extended amount of dev effort is warranted at this time; I'm looking for a "quick fix".

[megahirt]

Thank you Beth for the explanation, this is helpful. Unfortunately in this situation, there is no quick fix. The dependencies in Solid are over 10 years old, which is an eternity in software-years. We have found the locations of the crashes and the internal models within Solid have writing systems all over the place. We've decided to update the dependences to the latest Palaso libraries / dependences and that will take some time. This is the cost of not keeping a code base and dependencies updated. Since Solid is still useful to you and a few others, we think it's worth keeping Solid around by updating it so that we can at least maintain it.

[josephmyers]

Hi, @bbryson, I've been upgrading the Solid dependencies since you last talked with Chris, and I've gotten to a point where I can run something. It's enough to where I can investigate the issue you're seeing.

I see that in this crash scenario Solid is being opened with the TD37.solid file. So it's trying to open that on launching Solid. Would it be possible to send me that? Or any file that's causing this crash is fine, too. I'm not historically familiar with Solid, so if there are other files you think might be relevant or required, it'd be helpful to send those, too, if possible. Thank you!

[bbryson]

Thanks for looking at it!

Here is a different SFM file and the associated Solid settings file.

For me, it happens no matter what file I try to open. The determining factor for me is: Have I run FLEx recently? And as a result, are there .ldml files in the folder:

C:\ProgramData\SIL\WritingSystemRepository\3

If there are any files there, it crashes. If that folder is empty, it runs. So the workaround for us is:

• Close FLEx.
• Delete all files from that folder.
• Then run Solid.
• Remember to do that again if we run FLEx again before we next run Solid.

For other colleagues on my team, it is not "any LDML files". It is only "any LDML file for a writing system with a Variant label that is longer than 4 digits", or some other criteria that wasn't allowed in the version of the Palaso Library that Solid was compiled with, but is currently allowed by FLEx.

I'm attaching a FieldWorks project with such a writing system. If you restore this project in FLEx, then that folder will get populated with some LDML files, including one called las-x-phonological.ldml. The existence of this LDML file reliably causes Solid to crash on startup. Note that this LDML file is for the Lama language, but the SFM file I'm trying to open in Solid is for the Aruamu language--they have nothing to do with each other.

-Beth

On Fri, Jun 7, 2024 at 3:02 AM josephmyers @.***> wrote:

Hi, @bbryson https://github.com/bbryson, I've been upgrading the Solid dependencies since you last talked with Chris, and I've gotten to a point where I can run something. It's enough to where I can investigate the issue you're seeing.

I see that in this crash scenario Solid is being opened with the TD37.solid file. So it's trying to open that on launching Solid. Would it be possible to send me that? Or any file that's causing this crash is fine, too. I'm not historically familiar with Solid, so if there are other files you think might be relevant or required, it'd be helpful to send those, too, if possible. Thank you!

— Reply to this email directly, view it on GitHub https://github.com/sillsdev/solid/issues/5#issuecomment-2154306709, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA62JLGFMHOG6COT7C76UZLZGFSJLAVCNFSM6AAAAABFEIYQP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJUGMYDMNZQHE . You are receiving this because you were mentioned.Message ID: @.***>

[josephmyers]

@bbryson, it looks like you responded via email, and either you forgot to attach the files, or there's a bug in Github where the attachments didn't make it over here. I'm guessing the latter. Regardless, I can't see the files. Can you resend? Sorry for the inconvenience.

[josephmyers]

In contrast to your particular situation, I have numerous ldml files in my folder and am able to launch Solid with no issue. So I'm betting I fall into the second group of users. I am able to get "writing system"-related crashes other ways, but I want to be able to recreate your exact scenario.

Edit: I believe, according to your stack trace, yours crashes on startup in part because it's trying to open a file on launch. I'm wondering if you can get it to launch by just double-clicking on your Solid.exe? It shouldn't try to open a file in that case. That will help me isolate the issue scenario to either one or two bugs.

[bbryson]

I'll try attaching them here. I had to fake the extensions. Please delete .txt and .zip from these filenames before you try to use them.
AruStems.sfm.txt AruStems.solid.txt Lama complex subentry of sense 12-BB 2021-10-29 2203 Test Subentries of Subentry Senses.fwbackup.zip

Yes, the way I usually start Solid is to double click on the .solid file. That is supposed to launch Solid and open the associated .sfm file. It has been a while since I tried to (a) start Solid on its own and then (b) use File/Open to open the SFM file. I can't remember if that also crashes, and I'm not on the right computer to test that right now.

[josephmyers]

Ah, very smart. I actually just opened an issue with GH for this, as well.

I am able to recreate the crash by double-clicking an example .solid file I found on my machine. However, I can launch Solid successfully by double-clicking Solid.exe (no file on launch). I can then get the same crash by opening the .db file that corresponds to the crash-causing .solid file.

Edit: This happens for the installed version you mentioned, not for the dev version I've been working with. Which may be good news!

[josephmyers]

@bbryson, this bug is fixed, and we're working on getting a new version built now 👍

[megahirt]

This is fixed in release v1.0