Crash when deleting character (incorrect record of number of characters)

[weevil-see]

Hard facts:
Mesquite version 4.01 (build 1092) 9 July 2025
Running under Java 21.0.8; virtual machine by Arch Linux on Linux 6.12.48-1-MANJARO (architecture: amd64)

While working on a morphological matrix, I tried to color characters by assigning groups. Probably (!) I tried to delete a character. Suddenly a window opened announcing a crash (I forgot to screenshot that).
I dismissed the window and tried to save the file as a new file ("Basiprionotini.nex.2025_08_22.bak" in the log). The process took forever, so I had to restart my computer eventually (Mesquite wouldn't close otherwise). The GUI was not responsive as well, and scrolling through the matrix very slow with graphical glitches. I made a screenshot (graphical glitches not visible in the screenshot):

Log file:
Mesquite_Log_(Previous#3).txt
The file I tried to save ("Basiprionotini.nex.2025_08_22.bak" in the log):
Basiprionotini2025_08_22.txt
I am not sure if the file is corrupted or not. Apparently it was saved successfully even though the process was terminated. At least it opens in Mesquite.
I then tried to delete a character to see if it will reproduce the crash. I think it did:
Deleting the character from the menu (marked in red):

Deleting the character is producing the crash:

I clicked "report crash and continue", apparently that worked:

This is a screenshot from the nexus file. I think what caused the problem is that the number of characters NCHAR and the actual number of characters do not match, for whatever reason.

Question: Can I safely adjust NCHAR to match the number of existing characters, or would the file then still be corrupted as the Numbers of the characters are not continuous from 1 to 31?

[weevil-see]

Even though there is no character 16 in the matrix, character 16 is visible in Mesquite with some character states.

[wmaddisn]

Hi Jakob, Could you try the patch "forV4.01-CrashCharDelWStateNames (2025-09-09)” here: https://drive.google.com/drive/folders/199cyAIkeD2-6tmhd7gsyXhpKY-EqWrnY?usp=drive_link I’m not sure the state the file would have been in, but probably not good. My apologies if you lost work. You might want to choose the Automatic NEXUS backups item in the File>Defaults submenu. Does that fix it? Best wishes, Wayne

…

On Oct 22, 2025, at 10:28, Jakob Jilg ***@***.***> wrote: [CAUTION: Non-UBC Email] weevil-see created an issue (MesquiteProject/MesquiteCore#128) Hard facts: Mesquite version 4.01 (build 1092) 9 July 2025 Running under Java 21.0.8; virtual machine by Arch Linux on Linux 6.12.48-1-MANJARO (architecture: amd64) While working on a morphological matrix, I tried to color characters by assigning groups. Probably (!) I tried to delete a character. Suddenly a window opened announcing a crash (I forgot to screenshot that). I dismissed the window and tried to save the file as a new file ("Basiprionotini.nex.2025_08_22.bak" in the log). The process took forever, so I had to restart my computer eventually (Mesquite wouldn't close otherwise). The GUI was not responsive as well, and scrolling through the matrix very slow with graphical glitches. I made a screenshot (graphical glitches not visible in the screenshot): Screenshot_20251022_171013.png (view on web) Log file: Mesquite_Log_(Previous#3).txt The file I tried to save ("Basiprionotini.nex.2025_08_22.bak" in the log): Basiprionotini2025_08_22.txt I am not sure if the file is corrupted or not. Apparently it was saved successfully even though the process was terminated. At least it opens in Mesquite. I then tried to delete a character to see if it will reproduce the crash. I think it did: Deleting the character from the menu (marked in red): grafik.png (view on web) Deleting the character is producing the crash: grafik.png (view on web) I clicked "report crash and continue", apparently that worked: grafik.png (view on web) This is a screenshot from the nexus file. I think what caused the problem is that the number of characters NCHAR and the actual number of characters do not match, for whatever reason. grafik.png (view on web) Question: Can I safely adjust NCHAR to match the number of existing characters, or would the file then still be corrupted as the Numbers of the characters are not continuous from 1 to 31? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[weevil-see]

Thanks for the quick response!
The patch fixed the crash when deleting characters. From the instructions, the patch is fixing a "crash when deleting characters whose states have names".

1. when creating a new file in the unpatched Mesquite 4.01, I can delete characters without state names, but I get the crash whenever the character has state names (as expected from the title/instructions for the patch).
2. when working on my corrupted file in the unpatched Mesquite 4.01, I also get the crash when deleting an empty character without state names
3. with the patch, I can delete any characters without a crash or error, even on the corrupted file.

Of course I am interested to find out how I corrupted my file in the first place (also to prevent such things in the future).
The number of characters as in "DIMENSIONS NCHAR=", that is matching the number of columns in the matrix, is not matching the number of characters in the "CHARSTATELABELS" list.
CHARSTATELABELS are also not numbered continuously, 16 and 30 are missing.
I noticed that my backup already had problems, I just didn't notice until the crash happened. Perhaps a future version of Mesquite could include a check for this while opening a file and alert the user if inconsistencies occur.
In Mesquite, the result of this is that the columns are not matching the characters anymore. This is only noticed upon close examination, as the state names are of course still matching the character name, its just the values that are misplaced (like a frameshift mutation in the matrix).

I cannot exclude that those problems arose earlier from the bug that has been fixed by the patch you provided, but I'm also curious: Could something like this happen when inserting, deleting or reordering (sorting) characters?
I guess whenever a character is deleted or a new character is inserted, Mesquite will assign new numbers to every character behind the one that was edited?

I'll add a control-character to the end of my matrix, where every taxon has character state 5 or something like that. That way, I can quickly see if a "frameshift" occured, as the column and the header will not match anymore if that happened.

[wmaddisn]

Hi Jakob, If you had the crash while deleting, and then saved the file, that probably led to the corruption. This is the first time we’ve had a problem like this reported in 20 years, so hopefully it won’t happen again for you now that you have the patch! We are going to release 4.02 very soon. Thank you for all of your feedback! Wayne

…

On Oct 23, 2025, at 01:34, Jakob Jilg ***@***.***> wrote: [CAUTION: Non-UBC Email] weevil-see left a comment (MesquiteProject/MesquiteCore#128) Thanks for the quick response! The patch fixed the crash when deleting characters. From the instructions, the patch is fixing a "crash when deleting characters whose states have names". • when creating a new file in the unpatched Mesquite 4.01, I can delete characters without state names, but I get the crash whenever the character has state names (as expected from the title/instructions for the patch). • when working on my corrupted file in the unpatched Mesquite 4.01, I also get the crash when deleting an empty character without state names • with the patch, I can delete any characters without a crash or error, even on the corrupted file. Of course I am interested to find out how I corrupted my file in the first place (also to prevent such things in the future). The number of characters as in "DIMENSIONS NCHAR=", that is matching the number of columns in the matrix, is not matching the number of characters in the "CHARSTATELABELS" list. CHARSTATELABELS are also not numbered continuously, 16 and 30 are missing. I noticed that my backup already had problems, I just didn't notice until the crash happened. Perhaps a future version of Mesquite could include a check for this while opening a file and alert the user if inconsistencies occur. In Mesquite, the result of this is that the columns are not matching the characters anymore. This is only noticed upon close examination, as the state names are of course still matching the character name, its just the values that are misplaced (like a frameshift mutation in the matrix). I cannot exclude that those problems arose earlier from the bug that has been fixed by the patch you provided, but I'm also curious: Could something like this happen when inserting, deleting or reordering (sorting) characters? I guess whenever a character is deleted or a new character is inserted, Mesquite will assign new numbers to every character behind the one that was edited? I'll add a control-character to the end of my matrix, where every taxon has character state 5 or something like that. That way, I can quickly see if a "frameshift" occured, as the column and the header will not match anymore if that happened. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>