GNOME Bugzilla – Bug 665580
testsuite failure on s390x: buffered-input-stream
Last modified: 2014-02-11 13:50:05 UTC
Created attachment 202797 [details] Full Debian-ports build log for glib2.0 2.30.2-4 on s390x s390x is a big-endian 64bit architecture. The following test cases fail: gobject/tests: TEST: param... (pid=17482) ** ERROR:/build/buildd-glib2.0_2.30.2-4-s390x-0J7ZlY/glib2.0-2.30.2/./gobject/tests/param.c:148:test_value_transform: assertion failed (g_value_get_char (&dest) == -124): (132 == -124) /value/transform: FAIL GTester: last random seed: R02S186980d972380fe09bc2895cde5249ba /bin/bash: line 1: 17430 Terminated MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) ../../glib/gtester --verbose boxed enums param signals threadtests dynamictests binding properties reference ifaceproperties valuearray gio/tests: TEST: buffered-input-stream... (pid=17795) ** ERROR:/build/buildd-glib2.0_2.30.2-4-s390x-0J7ZlY/glib2.0-2.30.2/./gio/tests/buffered-input-stream.c:109:test_set_buffer_size: assertion failed (size == bufsize): (47244640267 == 11) /buffered-input-stream/peek: OK /buffered-input-stream/peek-buffer: OK /bin/bash: line 1: 17560 Terminated MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) dbus-launch ../../glib/gtester --verbose io-stream actions memory-input-stream memory-output-stream readwrite g-file g-file-info converter-stream data-input-stream data-output-stream g-icon buffered-input-stream buffered-output-stream sleepy-stream filter-streams volumemonitor simple-async-result srvtarget contexts gsettings gschema-compile async-close-output-stream gdbus-addresses network-address gdbus-message socket pollable tls-certificate tls-interaction cancellable gdbus-close-pending gdbus-connection gdbus-connection-loss gdbus-connection-slow gdbus-names gdbus-proxy gdbus-proxy-threads gdbus-proxy-well-known-name gdbus-introspection gdbus-threading gdbus-export gdbus-error gdbus-peer gdbus-exit-on-close gdbus-non-socket gdbus-bz627724 appinfo contenttype file live-g-file desktop-app-info unix-fd unix-streams gapplication gdbus-test-codegen /buffered-input-stream/set-buffer-size: FAIL GTester: last random seed: R02S43ffeceab32c6ac61f705844dc89e4de For the latter gio test case the buffer-size property of buffered_input_stream is declared as an param_spec_uint. The property itself is a gsize and g_buffered_input_stream_get_buffer_size works correctly, as it returns a gsize. gsize is an unsigned long on s390x and hence the conversion to uint seems wrong and is faulty on big-endian 64bit architectures. For the former glib test case I guess that the casting goes wrong as the compiler reinterprets values in memory at the wrong place due to endianess. Possibly this one also causes the gio failure, so it should probably be fixed first. FWIW, char is unsigned on s390(x), in case it matters.
Looking more in details, it seems to the two problems are actually unrelated. The first issue seems to be due to the tests not working on architectures with unsigned char. For example on armel (which uses unsigned char and is 32-bit little endian), the first test fails while the second test succeeds. On sparc64 (which uses signed char, and is 64-bit big endian), the first test succeeds, while the second test fails.
Yep. I just filed #666833 for the first test, because that's IMHO a bug in the testsuite. So we should focus here on why buffered-input-stream fails.
So it seems that the backend code does the conversion correctly. It's odd to talk about gsizes if one cares about an uint anyway. Fixing the testsuite involves reading the value into an uint instead: static void test_set_buffer_size (void) { […] gsize size, bufsize; guint uisize; […] size = g_buffered_input_stream_get_buffer_size (G_BUFFERED_INPUT_STREAM (in)); g_assert_cmpint (size, ==, bufsize); g_object_get (in, "buffer-size", &uisize, NULL); g_assert_cmpint (uisize, ==, bufsize); […] That works. I wouldn't be surprised to see other such assumptions in code using it, though.
Appears to have been fixed in the 2.35 cycle, commit 753494a25e35bd1f2413bd741f73d60226fcfd14. *** This bug has been marked as a duplicate of bug 687801 ***