After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606198 - rtph264pay is causing alignment trap on ARM arch
rtph264pay is causing alignment trap on ARM arch
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.16
Other Linux
: Normal normal
: 0.10.18
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-01-06 13:17 UTC by Brijesh Singh
Modified: 2010-01-07 16:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Brijesh Singh 2010-01-06 13:17:06 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
Comment 1 Wim Taymans 2010-01-07 16:01:18 UTC
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