crunchers with c and asm sources - Page 3

temisu · 18 August 2019, 18:40

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...

AmigaHope · 19 August 2019, 07:53

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.

Tigerskunk · 19 August 2019, 11:22

@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"

Tigerskunk · 20 August 2019, 10:52

Quote:

Tried a few different buffer sizes as well but still it works nicely

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

phx · 21 August 2019, 17:28

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.

temisu · 21 August 2019, 22:50

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

Tigerskunk · 22 August 2019, 08:20

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

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Crunchers that support overlays?	BarryB	support.Apps	9	07 March 2017 11:58
What Crunchers do you guys prefer?	Plagueis/KRX	Coders. General	67	30 July 2014 23:20
Old crunchers	absence	Coders. General	3	25 June 2012 18:47
ASM - Rolling Thunder sources - accurate delay	Asman	Coders. General	5	21 September 2010 23:15
Old crunchers for A500/WB1.3?	Photon	Coders. General	21	03 December 2004 02:14

18 August 2019, 18:40	#41
temisu Registered User Join Date: Mar 2017 Location: Tallinn / Estonia Posts: 74	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...

19 August 2019, 07:53	#42
AmigaHope Registered User Join Date: Sep 2006 Location: New Sandusky Posts: 942	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.

19 August 2019, 11:22	#43
Tigerskunk Inviyya Dude! Join Date: Sep 2016 Location: Amiga Island Posts: 2,770	@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"

21 August 2019, 17:28	#45
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	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.

21 August 2019, 22:50	#46
temisu Registered User Join Date: Mar 2017 Location: Tallinn / Estonia Posts: 74	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

22 August 2019, 08:20	#47
Tigerskunk Inviyya Dude! Join Date: Sep 2016 Location: Amiga Island Posts: 2,770	Will try that, thanks for your input, guys...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)