GNOME Bugzilla – Bug 606198
rtph264pay is causing alignment trap on ARM arch
Last modified: 2010-01-07 16:01:18 UTC
Hello, I'm working on TI ARM processor and have likely found an issue with rtph264pay payload element. On some cases I get bus error as shown below: "Alignment trap: gst-launch-0.10 (803) PC=0x40dde948 Instr=0xe5933000 Address=0x000b9011 FSR 0x013" This indicated that rtph264pay is trying to access an unaligned memory. And by default kernel generates Bus error on unaligned memory access. Looking at the code indicates that this unaligned access is coming from "is_nal_equal()" routine. <snip> /* we don't use memcpy but this faster version (around 20%) because we need to * perform it on all data. */ static gboolean is_nal_equal (const guint8 * nal1, const guint8 * nal2, guint len) { /* if we have a 64-bit processor, we may use guint64 to make * this go faster. Otherwise with 32 bits, we are already * going faster than byte to byte compare. */ guint remainder = len & 0x3; guint num_int = len >> 2; guint32 *pu1 = (guint32 *) nal1, *pu2 = (guint32 *) nal2; guint i; /* compare by groups of sizeof(guint32) bytes */ for (i = 0; i < num_int; i++) { /* XOR is faster than CMP?... */ if (pu1[i] ^ pu2[i]) return FALSE; } .......... <snip> } Lets consider the case when len=9. If len=9 then memory is not 32-bit aligned and will cause trap while comparing (pu1[1] ^ pu2[1]). If i force kernel to "fixup" alignment problem (i.e echo 2 > /proc/cpu/alignment)then everything works just fine. A simple strcmp is working fine for me but wanted to run with you guys to see if i'm missing something here or if anyone has seen this issue before ? Thanks Brijesh Singh
commit ed22a974787058928457f2cf734a2732791fcbed Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Thu Jan 7 16:58:55 2010 +0100 rtph264pay: remove weird memcmp code Use plain memcmp for comparing memory instead of the custom buggy one. Fixes #606198