You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I previously noticed that using different value of -helperThreads produce different files. I wondered if it was due to a bug.
I recently wrote a patch in the illwieckz/max-threads branch to set the maximum amount of threads to be usable at build time.
Given crunch is supposed to work with a main thread and some helper threads, the amount of helper threads is assumed to be the maximum amount of threads minus one, so it is assumed the tool should work with only two threads.
Building crunch with an arbitrary maximum amount of threads can be done like this with the illwieckz/max-threads branch:
mkdir buikd && cd build
cmake .. -DUSE_MAX_THREADS=2 && ninja
When I run a conversion from PNG to TGA it segfaults, like if it stumbled on some memory issues. It doesn't crash when spawning a thread, it crashes when reading data:
Thanks to this branch I more curious behaviors. I already noticed that using -helperThreads 3 with the default max amount of threads being 16, crn build was reproducible. It was not with amounts of helper threads higher than 3.
But with that branch, I can test different maximum amount of threads:
with default 16 max threads and -helperThreads 3, the image conversion is reproducible.
with default 16 max threads and -helperThreads 4, I get 6 different files (some DDS, CRN and KTX files).
with default 16 max threads and -helperThreads 7, the image conversion is reproducible.
with default 16 max threads and -helperThreads 14, I get 7 different files (some DDS, CRN and KTX files).
with default 16 max threads and -helperThreads 15, I get 1 different file (a DDS file).
with 4 max threads and -helperThreads 3, the image conversion is reproducible.
with 8 max threads and -helperThreads 3, the image conversion is reproducible.
with 8 max threads and -helperThreads 4, I get 6 different files (some DDS, CRN and KTX files).
with 8 max threads and -helperThreads 7, the image conversion is reproducible.
with 32 max threads and -helperThreads 3, the image conversion is reproducible.
with 32 max threads and -helperThreads 4, I get 6 different files (some DDS, CRN and KTX files).
with 32 max threads and -helperThreads 8, the image conversion is reproducible.
with 32 max threads and -helperThreads 9, I get 1 different file (a DDS file).
with 32 max threads and -helperThreads 10, I get 1 different file (a DDS file).
with 32 max threads and -helperThreads 11, the image conversion is reproducible.
with 32 max threads and -helperThreads 12, the image conversion is reproducible.
with 32 max threads and -helperThreads 13, the image conversion is reproducible.
with 32 max threads and -helperThreads 14, I get 7 different files (some DDS, CRN and KTX files).
with 32 max threads and -helperThreads 15, I get 1 different file (a DDS file).
with 32 max threads and -helperThreads 16, I get 5 different files (some DDS, CRN and KTX files).
with 32 max threads and -helperThreads 17, the image conversion is reproducible.
with 32 max threads and -helperThreads 18, the image conversion is reproducible.
with 32 max threads and -helperThreads 19, the image conversion is reproducible.
with 32 max threads and -helperThreads 24, the image conversion is reproducible.
with 32 max threads and -helperThreads 30, the image conversion is reproducible.
with 64 max threads and -helperThreads 14, I get 7 different files (some DDS, CRN and KTX files).
with 64 max threads and -helperThreads 15, I get 1 different file (a DDS file).
So I suspect there is a memory corruption or memory allocation error somewhere.
When there are different images being produced, it's always the same conversion that produces something different.
The text was updated successfully, but these errors were encountered:
illwieckz
changed the title
suspicious segfault in CRN compression with one main thread and mone helper thread
suspicious segfault in CRN compression with one main thread and one helper thread
Oct 8, 2024
Make a build tailored for reproducibility: cmake -S. -Bbuild -DUSE_FAST_MATH=OFF && cmake --build build
Edit test/test.py to customize -helperThreads with problematic values.
Run test/test.py
When using the illwieckz/max-threads branch, it's possible to set -DUSE_MAX_THREADS=64 (or other values) as CMake argument to customize the maximum amount of threads.
I previously noticed that using different value of
-helperThreads
produce different files. I wondered if it was due to a bug.I recently wrote a patch in the
illwieckz/max-threads
branch to set the maximum amount of threads to be usable at build time.Given crunch is supposed to work with a main thread and some helper threads, the amount of helper threads is assumed to be the maximum amount of threads minus one, so it is assumed the tool should work with only two threads.
Building
crunch
with an arbitrary maximum amount of threads can be done like this with theillwieckz/max-threads
branch:When I run a conversion from PNG to TGA it works:
When I run a conversion from PNG to TGA it segfaults, like if it stumbled on some memory issues. It doesn't crash when spawning a thread, it crashes when reading data:
Thanks to this branch I more curious behaviors. I already noticed that using
-helperThreads 3
with the default max amount of threads being 16, crn build was reproducible. It was not with amounts of helper threads higher than 3.But with that branch, I can test different maximum amount of threads:
-helperThreads 3
, the image conversion is reproducible.-helperThreads 4
, I get 6 different files (some DDS, CRN and KTX files).-helperThreads 7
, the image conversion is reproducible.-helperThreads 14
, I get 7 different files (some DDS, CRN and KTX files).-helperThreads 15
, I get 1 different file (a DDS file).-helperThreads 3
, the image conversion is reproducible.-helperThreads 3
, the image conversion is reproducible.-helperThreads 4
, I get 6 different files (some DDS, CRN and KTX files).-helperThreads 7
, the image conversion is reproducible.-helperThreads 3
, the image conversion is reproducible.-helperThreads 4
, I get 6 different files (some DDS, CRN and KTX files).-helperThreads 8
, the image conversion is reproducible.-helperThreads 9
, I get 1 different file (a DDS file).-helperThreads 10
, I get 1 different file (a DDS file).-helperThreads 11
, the image conversion is reproducible.-helperThreads 12
, the image conversion is reproducible.-helperThreads 13
, the image conversion is reproducible.-helperThreads 14
, I get 7 different files (some DDS, CRN and KTX files).-helperThreads 15
, I get 1 different file (a DDS file).-helperThreads 16
, I get 5 different files (some DDS, CRN and KTX files).-helperThreads 17
, the image conversion is reproducible.-helperThreads 18
, the image conversion is reproducible.-helperThreads 19
, the image conversion is reproducible.-helperThreads 24
, the image conversion is reproducible.-helperThreads 30
, the image conversion is reproducible.-helperThreads 14
, I get 7 different files (some DDS, CRN and KTX files).-helperThreads 15
, I get 1 different file (a DDS file).So I suspect there is a memory corruption or memory allocation error somewhere.
When there are different images being produced, it's always the same conversion that produces something different.
The text was updated successfully, but these errors were encountered: