Bug#674156: alignment issue
On Tue, 06 Nov 2012 at 09:42:48 +0100, Sjoerd Simons wrote: > This obviously breaks ABI on these platforms, not only of glib but also of > libraries which have a GStaticMutex embedded in their public structs in some > way. I sent this upstream, GNOME #688406. The new ABI has already been in two upstream stable branches, so reverting it would be just as painful from their point of view (and, I suspect, ours - testing is in an inconsistent state where some things have been recompiled, but not everything). In general, 32-bit RISC architectures are affected. i386 is unaffected because its ABI only aligns doubles on 32-bit boundaries, and 64-bit architectures are unaffected because the pointer at the beginning of GStaticMutex aligns the next struct member at a 64-bit boundary without needing padding. Confirmed affected: armel, armhf, mipsel, powerpc, s390, sparc (see https://bugzilla.gnome.org/show_bug.cgi?id=688406 for a standalone test) Suspected to be affected, but I couldn't log into a porterbox: armeb, mips, powerpcspe (of which mips is the only release architecture) Confirmed unaffected: amd64, i386, ia64, sh4, s390x Suspected to be unaffected, but I couldn't log into a porterbox: alpha, ppc64, sparc64 (all 64-bit, none are release architectures?) Untested: kfreebsd-i386, kfreebsd-amd64, hurd-i386 (assumed to have the same struct member alignment requirements as Linux, in which case all are unaffected) No idea: hppa, m68k (not release architectures anyway) One mitigating factor is that since GLib 2.32, only the first sizeof(void *) bytes of a GStaticMutex are actually used - so in global static mutexes, the most common use, it doesn't actually matter. The problem cases are structs that contain a GStaticMutex, and either are a GObject, or have members after the GStaticMutex. In GLib, GStaticRWLock and GStaticRecMutex are also affected (they contain a GStaticMutex). I haven't done the trawl through codesearch.debian.net to find out whether they're in anything else's public headers. > Whatever we do, we do need to ensure that all affected software gets compiled > against whatever final solution we pick. My vote would be to use codesearch.debian.net to find all affected software, and binNMU it on all release architectures, plus all affected unofficial architectures that have the infrastucture for binNMUs. The slower official architectures need the binNMU anyway, because they're precisely the 32-bit non-x86 architectures that are affected. If we binNMU on the unaffected official architectures - any-i386, any-amd64 and ia64 - as well, it shouldn't take any longer (they're "fast" architectures), and keeping the binNMU version in sync between architectures will make more multiarch packages co-installable. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674156: alignment issue
reassign 674156 glib-2.0
thanks,
On Fri, Oct 19, 2012 at 10:32:46PM +0900, Koichi Akabe wrote:
> > (gst-plugin-scanner:961): GLib-GObject-WARNING **: specified instance
> > size for type `GstRtpAC3Depay' is smaller than the parent type's
> > `GstBaseRTPDepayload' instance size
Digging through this it turned out that GStaticMutex changed size since
squeeze... When running the following test program:
#include
#include
#define SIZE(x) printf (#x ": %"G_GSIZE_FORMAT"\n", sizeof (x))
int
main (int argc, char **argv)
{
SIZE (GMutex *);
SIZE (double);
SIZE (pthread_mutex_t);
SIZE (GStaticMutex);
SIZE (GStaticRecMutex);
SIZE (struct { GMutex *a; union { char pad[24] ; char d; }; });
return 0;
}
On squeeze (armel):
GMutex *: 4
double: 8
pthread_mutex_t: 24
GStaticMutex: 32
GStaticRecMutex: 48
struct { GMutex *a; union { char pad[24] ; double d; }; }: 32
On wheezy (armel):
GMutex *: 4
double: 8
pthread_mutex_t: 24
GStaticMutex: 28
GStaticRecMutex: 40
struct { GMutex *a; union { char pad[24] ; double d; }; }: 32
Digging futher and futher on squeese GStaticMutex was defined as:
struct _GStaticMutex
{
struct _GMutex *runtime_mutex;
union {
char pad[24];
double dummy_double;
void *dummy_pointer;
long dummy_long;
} static_mutex;
};
While on wheezy:
typedef struct
{
GMutex *mutex;
#ifndef G_OS_WIN32
/* only for ABI compatibility reasons */
pthread_mutex_t unused;
#endif
} GStaticMutex;
Even though both pthread_mutex_t and the earlier union are 24 bytes themselves,
because of the double in the union it gets aligned to a multiple of 8 on ARM,
causing 4 bytes of extra padding to be added. Which in turns makes the old
GStaticMutex struct 4 bytes bigger then the current one...
This obviously breaks ABI on these platforms, not only of glib but also of
libraries which have a GStaticMutex embedded in their public structs in some
way.
I'm not sure what to do at this point... One option would be to patch
glib-2.0 so it's at least ABI compatible again with squeeze again, but it's
unlikely other distributions would follow (so we would be incompatible with
others). On the other hand this might not matter so much for arm.
Whatever we do, we do need to ensure that all affected software gets compiled
against whatever final solution we pick.
--
The light of a hundred stars does not equal the light of the moon.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674156: alignment issue
According to the build log on armel:
> 0%: Checks: 1, Failures: 1, Errors: 0
> elements/rtpbin_buffer_list.c:198:F:general:test_bufferlist:0: '*(guint64 *)
> data' (939538581729009792) is not equal to '*(guint64 *) rtp_header[index]'
> (16815518223612020252)
>
It casts from *guint8 to *guint64. armel doesn't return expected result
if the first address is not suited for guint64. In this case, the data
is shifted 2 bytes.
939538581729009792 = 0x0D09E95CB8BB6080
16815518223612020252 = 0xE95CB8BB6080861C
>
> (gst-plugin-scanner:961): GLib-GObject-WARNING **: specified instance
> size for type `GstRtpAC3Depay' is smaller than the parent type's
> `GstBaseRTPDepayload' instance size
>
> (gst-plugin-scanner:961): GLib-CRITICAL **: g_once_init_leave:
> assertion `result != 0' failed
>
> (gst-plugin-scanner:961): GStreamer-CRITICAL **: gst_element_register:
> assertion `g_type_is_a (type, GST_TYPE_ELEMENT)' failed W: Could not
> load
> 'debian/gstreamer0.10-plugins-good/usr/lib/arm-linux-gnueabi/gstreamer-0.10/libgstrtp.so':
> File
> "debian/gstreamer0.10-plugins-good/usr/lib/arm-linux-gnueabi/gstreamer-0.10/libgstrtp.so"
> appears to be a GStreamer plugin, but it failed to initialize
>
I tried getting the size of these structures using sizeof(). Both
structures are 320 bytes, but
gst-plugins-base-0.10.36/tests/check/libs/struct_arm.h says 328 bytes.
I think it also alignment issue.
--
Koichi Akabe
vbkaisetsu at {gmail.com, debian.or.jp}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
