GNOME Bugzilla – Bug 710983
Test failures on powerpc
Last modified: 2013-12-16 19:56:07 UTC
A few tests from gio/tests/ are failing on powerpc. See e.g. https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=powerpc&ver=2.38.1-2&stamp=1382915286 FAIL: proxy-test ================ # random seed: R02S34168afe21751ede098b681fedf23dfb # Start of proxy tests ok 1 /proxy/direct_sync ok 2 /proxy/direct_async ok 3 /proxy/single_sync ok 4 /proxy/single_async ok 5 /proxy/multiple_sync ok 6 /proxy/multiple_async ok 7 /proxy/dns ok 8 /proxy/override ok 9 /proxy/enumerator-ports # End of proxy tests 1..9 ***MEMORY-ERROR***: /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-proxy-test[5876]: GSlice: assertion failed: sinfo->n_allocated > 0 Aborted Running under valgrind I see no invalid read or writes, but it doesn't segfault, which might be relevant. Running under gdb I see a null pointer dereference: (experimental_powerpc-dchroot)pochu@partch:~/glib2.0-2.38.1/debian/build/deb/gio/tests$ gdb .libs/lt-proxy-test GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/pochu/glib2.0-2.38.1/debian/build/deb/gio/tests/.libs/lt-proxy-test...done. (gdb) r Starting program: /home/pochu/glib2.0-2.38.1/debian/build/deb/gio/tests/.libs/lt-proxy-test warning: Could not load shared library symbols for linux-vdso32.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". [New Thread 0xf7fc4420 (LWP 22231)] [New Thread 0xf75ff420 (LWP 22232)] [New Thread 0xf6bff420 (LWP 22233)] /proxy/direct_sync: OK /proxy/direct_async: OK /proxy/single_sync: OK /proxy/single_async: OK /proxy/multiple_sync: OK /proxy/multiple_async: OK /proxy/dns: OK /proxy/override: OK /proxy/enumerator-ports: OK Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf7fc4420 (LWP 22231)] slab_allocator_free_chunk (chunk_size=<optimized out>, mem=0x10022a28) at /home/pochu/glib2.0-2.38.1/./glib/gslice.c:1350 1350 prev->next = next; (gdb) t a a bt
+ Trace 232673
Thread 4 (Thread 0xf6bff420 (LWP 22233))
Thread 3 (Thread 0xf75ff420 (LWP 22232))
Thread 2 (Thread 0xf7fc4420 (LWP 22231))
Thread 1 (Thread 0xf7ff2000 (LWP 22228))
$1 = (SlabInfo *) 0x0 (gdb) I wonder why with valgrind I get no assertion or crash. Perhaps there's some memory corruption here but I'm not hitting it when running under valgrind...
(In reply to comment #0) > /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-proxy-test[5876]: GSlice: > assertion failed: sinfo->n_allocated > 0 > Aborted > > > Running under valgrind I see no invalid read or writes, but it doesn't > segfault, which might be relevant. The crash is in GSlice, but GSlice automatically disables itself when you're running under valgrind now; you can set G_SLICE="" in the environment to avoid that.
Created attachment 258267 [details] Valgrind log Maybe this helps; valgrind log
After looking at the valgrind log I thought this would be about port being a guint16 but the class property being a guint, and thus g_object_new reading the wrong amount of bytes and into invalid memory, then writing into the wrong address as well. I've tried a quick fix for that (a cast to guint for port when calling g_object_new() there) but it doesn't help, so it may be something else.
Doh. gtype changes its behavior under valgrind too... ==3922== Invalid write of size 4 ==3922== at 0xFFBA7A4: memset (in /usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so) ==3922== by 0xFF021CF: g_slice_alloc0 (string3.h:84) ==3922== by 0xFE4BA8B: g_type_create_instance (gtype.c:1841) This is in the valgrind-specific part of the new-and-improved instance-private allocating stuff.
I noticed that this goes away when glib is configured with --enable-debug=no. The distro builds with the bug are =minimal.
Building with --enable-debug=yes (default for odd releases) passes the tests. The main difference between --enable-debug=yes and --enable-debug=minimum is -DG_ENABLE_DEBUG. Investigating further I have tracked it down to this code in gobject/gtype.c: #ifdef G_ENABLE_DEBUG memset (allocated, 0xaa, ivar_size + private_size); #endif With that memset, a debug build passes the test, but with it commented out the tests fail. Similarly, a minimum build fails, but unconditionally compiling that memset makes the tests pass again. This code changed in commit 31fde567a95ff8f50b6b0e75d4010da9b73514ed. Ryan, do you have insight on this?
Bug 702648 documents another case of (what increasingly appears to be) Debian's ppc compiler mis-compiling the valgrind macros when optimisation is enabled. Building gtype.c with -O0 also fixes the problem here -- as does removing the valgrind macros. Pretty sure this is not our bug.
Indeed -- looking at valgrind.h. it appears that it modifies the value of r0 without properly declaring it in the clobber list. Adding it to the clobber list makes the crash go away.
Upstream bug is already open here: https://bugs.kde.org/show_bug.cgi?id=278808
Created attachment 260389 [details] [review] valgrind.h: add "r0" to the clobber list on PPC Looks like the magic sequences trash this register, so make sure GCC knows that.
Cheers, I checked this in a Debian/PPC environment and it fixes the testsuite for me.
Attachment 260389 [details] pushed as 6c8600b - valgrind.h: add "r0" to the clobber list on PPC No reply upstream, so let's push this for now.