GIMP-compressed .tif file from uncompressed crashes EbV

[Herkules97]

OOPS I FORGOT TO MENTION, IT'S 1367a AND MAYBE 1373a+ DOESN'T HAVE THIS CRASH ISSUE. I THOUGHT I WAS USING 1373a BUT I MIXED IT UP WITH A FOLDER AT HOME THAT DOES.

I have a guaranteed way to crash EbV(Everything by Voidtools) with two files that have been compressed from the original scan that was uncompressed from Epson Scan. Copying only the uncompressed original does not crash EbV. Both the LZW and the Deflate compressed versions crash EbV shortly after copy.
These are from the OS drive and then copied to an external SSD.
I won't upload these files, but you can probably accomplish the same thing with any .tif files so I could probably scan some unidentifiable thing and then compress with GIMP and if it crashes, upload to a cloud service and link it here.
My OS database doesn't crash reading them, most likely because it has no additional property indexing so it doesn't touch the files in the same way.
If asked I can copy the EbV folder and then run that but try without property indexing and then if that doesn't crash, go through and remove one property being indexed at a time to see if it's a specific property value crashing it.

The same I think was accomplished by a GIMP-exported .tif file that Windows Explorer bugs with. That's a known bug where it locks the file and pretty much nothing can remove it with Explorer.exe still on. I'm not sure if that file crashed EbV. It may be the "save thumbnail" option, but I see no thumbnail in Irfanview so I don't know.

Possible issues may be the computer specs as EbV seems to run about 80% CPU usage before it crashes and maybe it doesn't have enough juice to get over these two files.
That the filenames have § in them because literally no other files on this drive have §. I don't think this is a case for a different database at the desktop I have at home that also has some property indexing enabled. I can't check right now as I'm on a laptop elsewhere.

Here is every property indexed if you want to try it yourself, using GIMP v2.10.36 with all properties indexing for all file types and all folders
properties=Album,Album Artist,Allocation Size,Artist,Aspect Ratio,Audio Bit Rate,Audio Bits Per Sample,Audio Channels,Audio Format,Audio Sample Rate,Audio Track Count,Author URL,Authors,Binary Type,Bit Depth,Camera Maker,Color Representation,Comment,Company,Composer,Compressed Size,Compression,Container File Count,Container Filenames,Content Created,Content Type,Copyright,Date Acquired,Date Changed,Date Indexed,Date Saved,Date Taken,Description,Digital Signature Name,Digital Signature Timestamp,Dimensions,Exif Version,Frame Count,Frame Rate,Genre,Height,Horizontal Resolution,Language,Last Author,Length,Machine Target,MD5,Media Created,Orientation,Original Filename,Original Location,Photometric Interpretation,Product Name,Product Version,Resolution Unit,Software,Subject,Subtitle,Subtitle Track Count,Tags,Title,Total Bit Rate,Track,Valid UTF-8,Version,Version Number,Vertical Resolution,Video Bit Rate,Video Format,Video Track Count,Width,Year

I spent little time searching for a similar issue, I'm lazy.

[Herkules97]

After testing, it's the EXIF option. XMP, IPTC and color profile all does not crash EbV.
Have I been shadowbanned from replies, seems like at least a hundred have seen this post but no one has replied.
Am I internetting wrong?

[Herkules97]

After testing, there is something wrong with properties starting with ca-com.
Removing all of them, or any it seems, fixes the crashing.
I decided to stick with removing Color Representation.
I don't think it's that the database is just bugged, I remove A-B properties and still crashed and force re-index with no properties removed also did nothing.
But I believe I disabled only one of the properties starting with co and it worked, it didn't seem to matter which one.
I can't be arsed to do this again. Color Representation removed works because that's what I have right now and it didn't crash even after exporting a new file with all usual info.
You could try it yourself if you want, but if the bug is solved by disabling color representation property index I'll just live with that.

[void]

Thank you for the crash report Herkules97,

Does this crash occur with Everything 1.5.0.1380a or later?

1380a fixes an issue with gathering 'indexed values'.
I see you are indexing Date Indexed.
'Date Indexed' is an indexed value and will cause 1379a or earlier to crash if indexed.

[Herkules97]

Thank you for the crash report Herkules97,

Does this crash occur with Everything 1.5.0.1380a or later?

1380a fixes an issue with gathering 'indexed values'.
I see you are indexing Date Indexed.
'Date Indexed' is an indexed value and will cause 1379a or earlier to crash if indexed.

Date Indexed does not crash EbV and has never done that for any of the databases with it enabled that I have here at home and on the laptop.
As I said it's one of the properties starting with ca-com and it stopped crashing when I disabled Color Representation. But presumably any of them would do, Idk..I didn't test. I disabled them in groups and ca-com was the next group and it stopped crashing. I then reverted and disabled only Color Representation because I thought it was the most pointless and it stopped crashing.
I'll test 1380+ tomorrow and see if it crashes.

I'll make a .tiff and send it after confirming it's a crasher and you can test it yourself. It could be the hardware of the laptop(Thinkpad T470 refurb I think, but they may have different hardware under the same name), maybe it asks for RAM that isn't there trying to load these files. I'm lazy and haven't tested the files on the stationary.
Rather I'll test it, confirm, upload, download, test and confirm again. If the upload modifies it..Well there is archive formats, maybe those will keep it intact enough.

After checking out the changelog, it isn't just date indexed. It is date indexed with fast sort. I don't have that enabled, so that may be why it has never crashed from indexing that property.

The crash was caused from indexing the "Index Volume Label" property and enabling fast sort.

Or at least I assume that's what it is, you call it something different in that post but here you say it's date indexed. Either way, I don't have fast sort enabled for date indexed property on any of the databases I use because I have no use for that.
I have non-fast sort date indexed on just cause it's another date property that may have unique data. Unlike "Day accessed" and "Time accessed" that is "Date accessed" but worse.

[Herkules97]

Thank you for the crash report Herkules97,

Does this crash occur with Everything 1.5.0.1380a or later?

1380a fixes an issue with gathering 'indexed values'.
I see you are indexing Date Indexed.
'Date Indexed' is an indexed value and will cause 1379a or earlier to crash if indexed.

Have now tested with 1381 and it still crashes.

I now prepared an archive, it's a blank page that still crashes EbV so it'll be small instead of the 164MB original.

The quickest way to crash EbV with the above is to extract it somewhere and use folder monitoring on only it.
I didn't add the .ini to it, so here are the relevant lines and maybe some irrelevant ones:

properties=Album,Album Artist,Allocation Size,Artist,Aspect Ratio,Audio Bit Rate,Audio Bits Per Sample,Audio Channels,Audio Format,Audio Sample Rate,Audio Track Count,Author URL,Authors,Binary Type,Bit Depth,Camera Maker,Color Representation,Comment,Company,Composer,Compressed Size,Compression,Container File Count,Container Filenames,Content Created,Content Type,Copyright,Date Acquired,Date Changed,Date Indexed,Date Saved,Date Taken,Description,Digital Signature Name,Digital Signature Timestamp,Dimensions,Exif Version,Frame Count,Frame Rate,Genre,Height,Horizontal Resolution,Language,Last Author,Length,Machine Target,MD5,Media Created,Orientation,Original Filename,Original Location,Photometric Interpretation,Product Name,Product Version,Resolution Unit,Software,Subject,Subtitle,Subtitle Track Count,Tags,Title,Total Bit Rate,Track,Valid UTF-8,Version,Version Number,Vertical Resolution,Video Bit Rate,Video Format,Video Track Count,Width,Year
properties_include_folders=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
properties_include_files=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
properties_include_only_folders=,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
properties_exclude_folders=,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
properties_include_only_files=,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
properties_exclude_files=,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
properties_max_size=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
properties_max_size_unit=2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
properties_fast_sort=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
properties_exclude_not_content_indexed=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
properties_exclude_recall_on_data_access=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

[void]

Thank you for the archive and for testing 1381a Herkules97,

I am looking into the issue..

[void]

Thank you for the tif and property list Herkules97,

Everything 1.5.0.1383a fixes an issue with indexing Color Representation.

The system uses 4 bytes to represent Color Representation.
Everything only uses 2 bytes.
Everything was incorrectly reading the system Color Representation with a smaller buffer, corrupting your index.

[Herkules97]

Thank you for the tif and property list Herkules97,

Everything 1.5.0.1383a fixes an issue with indexing Color Representation.

The system uses 4 bytes to represent Color Representation.
Everything only uses 2 bytes.
Everything was incorrectly reading the system Color Representation with a smaller buffer, corrupting your index.

You're sure it's not all properties of ca-com and only Color Representation? Pretty sure I only disabled that because it seemed the worst to keep, not that I did tests to determine it was the only cause.
Would be a coincidence if I happened to pick the broken one then.