Hi,

I tried that file and could not make it crash in my setup. I tried valgrind as well but it did not complain either. Tried a few different buffer sizes as well but still it works nicely

I suspect it is something from environment. What OS are you running it on? Do you have a stack dump? What compiler did you use?

Strange bug indeed...

One of the interesting things about compression routines like RNC1 is the separate huffman table for the dictionary offsets, so an optimal compressor can sometimes save a few bytes by not picking the optimal dictionary hit and instead use offsets that encode smaller in huffman.

@Temisu: Very strange, indeed. I use Mac OS X and compiled it with (--version output):

"Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin"

How can I change these myself?
Would really like to get this working.

Can't you debug the segmentation fault yourself? Is it reproducible?

I have no MacOS for testing, but I remember that OSX is similar to BSD. So you should be able to debug the core file (if OSX generates one), or start the program again with gdb. Then inspect the crash location (like a function backtrace, state of variables, find out which access caused the segfault, etc.) and pass this information to temisu. Maybe it helps.

Yeah, I tried with two different macs and I was not able to reproduce the issue. However, I did not have the exact same clang version.

Basically what I tested was building the compressor with make in extra-directory and then running it in debugger with 'lldb ./bruteRNC1 assetsLevel1.bin test.out'

By providing one more number to the command line you can set the blockSize, but that did not seem to do anything either.

If you can run it in your environment and do a backtrace ('bt' in gdb/lldb) that would help a lot

Will try that, thanks for your input, guys... :)