Segmentation fault

[khavishbhundoo]

I have compile latest pik and i get a segmentation fault with the following command

cpik bench.png bench_1.0_new.pik

Details :
Thread 1 "cpik" received signal SIGSEGV, Segmentation fault. 0x00000000004fd44c in pik::ANSSymbolWriter::FlushToBitStream() ()

Backtrace :

#0  0x00000000004fd44c in pik::ANSSymbolWriter::FlushToBitStream() ()
#1  0x00000000004fa9be in pik::EncodeImage[abi:cxx11](pik::Image3<short> const&, int, pik::PikImageSizeInfo*) ()
#2  0x000000000048df17 in pik::EncodeToBitstream[abi:cxx11](pik::QuantizedCoeffs const&, pik::Quantizer const&, pik::NoiseParams const&, pik::ColorTransform const&, bool, pik::PikInfo*) ()
#3  0x00000000004c39e1 in pik::OpsinToPik(pik::CompressParams const&, pik::Header const&, pik::MetaImage<float> const&, pik::ThreadPool*, pik::PaddedBytes*, pik::PikInfo*) ()
#4  0x00000000004ca2ba in bool pik::PixelsToPikT<pik::MetaImage<float> >(pik::CompressParams const&, pik::MetaImage<float> const&, pik::ThreadPool*, pik::PaddedBytes*, pik::PikInfo*) ()
#5  0x0000000000409ed9 in pik::(anonymous namespace)::CompressAndWrite(int, char**) ()
#6  0x00007ffff682b18b in __libc_start_main () from /lib64/libc.so.6
#7  0x0000000000408d4a in _start ()

GCC version : 8.1.1

[jan-wassenberg]

Thanks for reporting this. Looks like we might have some compiler trouble, especially because -fsanitize=address does not report an error.

I can repro with g++ 7.3 but not Clang 4.0.1 nor Apple's 9.1.0 (clang-902.0.39.2).
We'll investigate on Monday; in the meantime, would you mind adding override CXX := clang++ to Makefile?

[khavishbhundoo]

I get a segmentation fault even when compiling with clang 6.0 (fedora repo)

clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/8
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

[jan-wassenberg]

Ah, good to know, thanks. The problem was indeed compiler-dependent but our code was at fault - it assumed a certain evaluation order, but C++ leaves it unspecified.

Fixed, please re-open if you are still seeing an issue.