FTBFS on hppa/parisc architecture

[linuxmaniac]

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810960

sngrep fails to build because the testcases test-004, test-005 and test-005 fail, e.g.: https://buildd.debian.org/status/fetch.php?pkg=sngrep&arch=hppa&ver=1.2.0-1&stamp=1452639207

It turns out, that this is a bug in the C-code of the testcases of sngrep which affects only big-endian machines (e.g. s390x, ppc64 and hppa).

Testcases 1,2,3 and 7 defines the keystroke table correctly like this: const char keys[] = {...}; while testcases 4,5 and 6 define the keystrokes like this (with "int" type): const int keys[] = {...};

In tests/test_input.c each various key is then written with: unused = write(ppipe[1], &keys[i], sizeof(char));

Please note the usage of "char" vs. "int" in the keys tables above. If "int" is used, then on big-endian machines the &keys[i] refers to the first byte of each 2-byte (int) value, which is on big-endian machines the higher-8-bit value which is "0", while on little-endian machines the lower 8-bit-value which is the key which was actually defined.

So, the attached patch fixes this problem for all machines regardless of the endianess and adds a check to tests/test_input.c like this: const char keys[]; That way at least a compiler warning will be generated if new testcases with "int" usage would be added.

Can you please apply this patch to the next upload of sngrep and/or report this upstream ?

Thanks, Helge

PS: I still wonder why the testcases 4-6 didn't broke on all other big-endian arches. I assume the compiler did some optimization of the "int"-based-keys table and as such just hided the coding problem...

[Kaian]

Hi @linuxmaniac

Tests are mostly for you and me, and this change seems perfectly fine and well explained.

I should improve those test because ncurses actually uses int for keys. Right now I only test key inputs whose int value is < 255 so char is enough for this simple tests.

Thanks a lot for the report and Helge Deller for the patch and awesome explanation!

[linuxmaniac]

Still failling on sparc64 https://buildd.debian.org/status/architecture.php?a=sparc64&suite=sid 1.3.1

[Kaian]

Hi!

Most probably the problem is a bit different from the mentioned here. The compilation success but the tests fail, most probably because they have a timeout of 5 second implemented. All interface test should end leaving sngrep gracefully; If that doesn't happen in the timeout time, I assume I have broken something in the user interation loop. On some slow CPUs this timeout may not be enough and lead to failure of all UI tests :(

I think I can increase the value to something like 30 seconds. At the end, most likely tests are not run by humans.

Thanks for the info @linuxmaniac

[Kaian]

Still failing in sparc64 for 1.4.0 Doh! :-(

[linuxmaniac]

for 1.4.6 too

[Kaian]

I'll reopen this so I won't forget it.

Thanks @linuxmaniac !

[linuxmaniac]

for 1.6.0 too

[linuxmaniac]

make[3]: Entering directory '/<<PKGBUILDDIR>>/tests'
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_001.o test_001.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_002.o test_002.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_003.o test_003.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_004.o test_004.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_005.o test_005.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_006.o test_006.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_007.o test_007.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_008.o test_008.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_009.o test_009.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_010.o test_010.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o test_011.o test_011.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o ../src/vector.o ../src/vector.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o ../src/util.o ../src/util.c
gcc -DHAVE_CONFIG_H -I. -I../src   -Wdate-time -D_FORTIFY_SOURCE=2  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security  -c -o ../src/hash.o ../src/hash.c
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-003 test_003.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-006 test_006.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-004 test_004.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-001 test_001.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-002 test_002.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-005 test_005.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-009 test_009.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-008 test_008.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-011 test_011.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
/usr/bin/ld: warning: test-003 has a LOAD segment with RWX permissions
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-010 test_010.o ../src/hash.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
/usr/bin/ld: warning: test-006 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-004/usr/bin/ld:  has a LOAD segment with RWX permissionswarning: test-002
 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-001 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-005 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-009 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-008 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-011 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: test-010 has a LOAD segment with RWX permissions
gcc  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro -o test-007 test_007.o ../src/vector.o ../src/util.o  -lmenuw -lformw -lpanelw -lncursesw -ltinfo -lpcap -lpthread  
/usr/bin/ld: warning: test-007 has a LOAD segment with RWX permissions
make[3]: Leaving directory '/<<PKGBUILDDIR>>/tests'

[Kaian]

Hi!!

Thanks for remembering me this one!

I have tested in a hppa/parisc qemu image following these instructions. This architecture seems quite slow, it tooks me some hours to download and install all dependencies, so at first I thought that would be the reason for test failures.

Sadly, after compiling and running the tests, all of them passed, so I'm not sure how I could reproduce the problem. I can increse the timeout value for this architecture as a blind shot (although I think we already did that in the past). Any idea is welcomed!

Regards

[Kaian]

Oh, I realized the attached logs are from sparc64. I'll test again for that arch. My bad! :sweat_smile: