Firefox crashes when attempting to play webm video on ARM with Thumb2 enabled

Thanks, but I'm not too sure what you expect me to do with this with such little information ;)

Could you at least provide a backtrace, or the crash ID of the crash report you submitted to Mozilla when the crash reporter dialog popped up

Note, you can access submitted crash reports from about:crashes

I don't expect you do to anything with it. If you want to investigate, go right ahead, it's easy to reproduce and debug to your heart's content. That image is already gone from my panda (sorry, I had other things to test) but I'm sure the bug itself is not. It could be a bug in the compiler, in the video codec code or in firefox on arm. I'm not here to determine which.

The crash report:
https://crash-stats.mozilla.com/report/index/bp-22e23234-387d-43d0-ad3e-a11c12110613

Happens with the normal Ubuntu image, and quite easy to reproduce, just try to play an youtube video with HTML5 and it'll explode.

Changing to Medium as this is the only way to play youtube videos on the released Ubuntu on ARM images, as we don't have full flash support.

Thanks for that. Remember that not everyone (myself included) has the hardware to reproduce this on though, which makes things quite difficult for me.

Could you reproduce this in gdb? I could do with seeing the stack variables in the top few frames really, but crash-stats doesn't provide that information.

Thanks

It would also be useful to try this on the latest trunk nightly (upstream will request that anyway). We provide builds for those, but unfortunately not for armel

Running with GDB doesn't help much at the crash, even with all debug symbols:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x5b8ff2b0 (LWP 2663)]
0x59cf8d64 in ?? ()
(gdb) bt full
#0 0x59cf8d64 in ?? ()
No symbol table info available.
#1 0x5b8fe8f0 in ?? ()
No symbol table info available.
Cannot access memory at address 0x0
#2 0x5b8fe8f0 in ?? ()
No symbol table info available.
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

When iterating step by step at vp8cx_init_de_quantizer the video frames were displayed correctly, without crashing. The crash happens as soon as I hit continue.

I'll keep trying to get more useful information, and I'm also building the latest daily package locally on another board.

The error is happening while calling vp8_push_neon(dx_store_reg) at mozilla/media/libvpx/vp8/decoder/onyxd_if.c:342.

gdb:
...
(gdb) b vp8dx_receive_compressed_data
Breakpoint 1 at 0x407d1ea4: file /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c, line 318.
(gdb) b vp8_push_neon
Breakpoint 2 at 0x407dd662
(gdb) c
Continuing.
[Thread 0x49a262b0 (LWP 2947) exited]
[New Thread 0x49a262b0 (LWP 2968)]
[New Thread 0x51aff2b0 (LWP 2969)]
[Thread 0x4e5ff2b0 (LWP 2952) exited]
[New Thread 0x4e5ff2b0 (LWP 2970)]
Running global cleanup code from study base classes.
[New Thread 0x536ff2b0 (LWP 2971)]
[New Thread 0x53eff2b0 (LWP 2972)]
[New Thread 0x54aff2b0 (LWP 2973)]
[Switching to Thread 0x54aff2b0 (LWP 2973)]

Breakpoint 1, vp8dx_receive_compressed_data (ptr=0x52eaa020, size=442, source=0x4cd4eb00 "\220\064", time_stamp=0) at /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c:318
318 /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c: No such file or directory.
 in /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c
(gdb) n
330 in /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c
(gdb)
335 in /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c
(gdb)
322 in /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c
(gdb)
335 in /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c
(gdb)
339 in /build/buildd/firefox-5.0~b5+build1+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c
(gdb) p cm
$1 = (VP8_COMMON *) 0x52eab1d0
(gdb) p cm->rtcd
$2 = {idct = {idct1 = 0x407db52a <vp8_short_idct4x4llm_1_neon>, idct16 = 0x407db57a <vp8_short_idct4x4llm_neon>, idct1_scalar_add = 0x407cad41 <vp8_dc_only_idct_add_c>, iwalsh1 = 0x407da81a <vp8_short_inv_walsh4x4_1_neon>,
    iwalsh16 = 0x407da796 <vp8_short_inv_walsh4x4_neon>}, recon = {copy16x16 = 0x407da6ce <vp8_copy_mem16x16_neon>, copy8x8 = 0x407da68a <vp8_copy_mem8x8_neon>, copy8x4 = 0x407da666 <vp8_copy_mem8x4_neon>,
    recon = 0x407db4ba <vp8_recon_b_neon>, recon2 = 0x407db3ce <vp8_recon2b_neon>, recon4 = 0x407db426 <vp8_recon4b_neon>, recon_mb = 0x407d76e3 <vp8_recon_mb_neon>, recon_mby = 0x407cd427 <vp8_recon_mby_c>,
    build_intra_predictors_mby_s = 0x407d6fe7 <vp8_build_intra_predictors_mby_s_neon>, build_intra_predictors_mby = 0x407d6fc1 <vp8_build_intra_predictors_mby_neon>}, subpix = {sixtap16x16 = 0x407dc8c6 <vp8_sixtap_predict16x16_neon>,
    sixtap8x8 = 0x407dc212 <vp8_sixtap_predict8x8_neon>, sixtap8x4 = 0x407dbbce <vp8_sixtap_predict8x4_neon>, sixtap4x4 = 0x407db65a <vp8_sixtap_predict_neon>, bilinear16x16 = 0x407da25e <vp8_bilinear_predict16x16_neon>,
    bilinear8x8 = 0x407da04e <vp8_bilinear_predict8x8_neon>, bilinear8x4 = 0x407d9eea <vp8_bilinear_predict8x4_neon>, bilinear4x4 = 0x407d9da6 <vp8_bilinear_predict4x4_neon>}, loopfilter = {
    normal_mb_v = 0x407d6dad <vp8_loop_filter_mbv_neo...

Also able to reproduce the same issue with Nightly 7.0a1 (2011-06-19):
https://crash-stats.mozilla.com/report/index/bp-35ce5a2a-c1f8-40e4-ae6a-c89062110620

The trace shows the seg fault is happening at the same place as with previous firefox.

(gdb) b vp8dx_receive_compressed_data
Breakpoint 1 at 0x40c4899c: file /build/firefox/trunk/firefox-trunk-7.0~a1~hg20110618r71272+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c, line 318.
(gdb) b vp8_push_neon
Breakpoint 2 at 0x40c54132
(gdb) c
Continuing.
[New Thread 0x520ff460 (LWP 2080)]
[Thread 0x4c6ff460 (LWP 2062) exited]
[New Thread 0x5297c460 (LWP 2081)]
[New Thread 0x4c6ff460 (LWP 2086)]
[Switching to Thread 0x4c6ff460 (LWP 2086)]

Breakpoint 1, vp8dx_receive_compressed_data (ptr=0x53101020, size=14089,
    source=0x5346b000 "\260 \001\235\001*\340\001h\001\004\207\b\205\205\210\205\204\210N\203\270\070Ϩr\233\003\241{k\023\027\205!\355t\341\311?\t\376\347\235w!\367\257\362\037\301\376\316\366\251\337\307oy\254t\347\376\177\272/\232\277\360\277\362\177\251\370\005\375[\375\217\376\037d\317\355\276z\237\272?\002\277x}V\376\323\376\315\373\236\377\351\366\r\375\223\324?\373\217\372>\274oE/\335\037N\177\335\357\211\037\354\337\366\377s}\250\177\373\352kL\310\061\300j\320\363 \277E\016\312D\210\322-\351\060e\004\377\213J\245\243ܯ\277Rf\321C\351\061j\021X\216\252_^9\030h\311\300X\031*\327\270vƒ\252\a\n\244u\004\232\252Ќs"..., time_stamp=0)
    at /build/firefox/trunk/firefox-trunk-7.0~a1~hg20110618r71272+nobinonly/build-tree/mozilla/media/libvpx/vp8/decoder/onyxd_if.c:318
318 {
(gdb) l
313
314 return err;
315 }
316
317 int vp8dx_receive_compressed_data(VP8D_PTR ptr, unsigned long size, const unsigned char *source, INT64 time_stamp)
318 {
319 #if HAVE_ARMV7
320 INT64 dx_store_reg[8];
321 #endif
322 VP8D_COMP *pbi = (VP8D_COMP *) ptr;
(gdb) n
330 if (ptr == 0)
(gdb)
335 pbi->common.error.error_code = VPX_CODEC_OK;
(gdb)
322 VP8D_COMP *pbi = (VP8D_COMP *) ptr;
(gdb)
335 pbi->common.error.error_code = VPX_CODEC_OK;
(gdb) p ptr
$1 = (VP8D_PTR) 0x53101020
(gdb) n
339 if (cm->rtcd.flags & HAS_NEON)
(gdb) l
334
335 pbi->common.error.error_code = VPX_CODEC_OK;
336
337 #if HAVE_ARMV7
338 #if CONFIG_RUNTIME_CPU_DETECT
339 if (cm->rtcd.flags & HAS_NEON)
340 #endif
341 {
342 vp8_push_neon(dx_store_reg);
343 }
(gdb) p cm
$2 = (VP8_COMMON *) 0x531021d0
(gdb) p cm->rtcd
$3 = {idct = {idct1 = 0x40c51ffe <vp8_short_idct4x4llm_1_neon>, idct16 = 0x40c5204e <vp8_short_idct4x4llm_neon>, idct1_scalar_add = 0x40c41839 <vp8_dc_only_idct_add_c>, iwalsh1 = 0x40c512fe <vp8_short_inv_walsh4x4_1_neon>,
    iwalsh16 = 0x40c5127a <vp8_short_inv_walsh4x4_neon>}, recon = {copy16x16 = 0x40c511b2 <vp8_copy_mem16x16_neon>, copy8x8 = 0x40c5116e <vp8_copy_mem8x8_neon>, copy8x4 = 0x40c5114a <vp8_copy_mem8x4_neon>,
    recon = 0x40c51f8e <vp8_recon_b_neon>, recon2 = 0x40c51ea2 <vp8_recon2b_neon>, recon4 = 0x40c51efa <vp8_recon4b_neon>, recon_mb = 0x40c4e1db <vp8_recon_mb_neon>, recon_mby = 0x40c43f1f <vp8_recon_mby_c>,
    build_intra_predictors_mby_s = 0x40c4dadf <vp8_build_intra_predictors_mby_s_neon>, build_intra_predictors_mby = 0x40c4dab9 <vp8_build_intra_predictors_mby_neon>}, subpix = {sixtap16x16 = 0x40c53396 <vp8_sixtap_predict16x16_neon>,
    sixtap8x8 = 0x40c52ce2 <vp8_sixtap_predict8x8_neon>, sixtap8x4 = 0x40c5269e <vp8_sixtap_predict8x4_neon>, sixtap4x4 = 0x40c5212a <vp8_sixtap_pred...

Tried to build the daily version with 'noopt' but then got blocked by another bug:

/usr/bin/python2.7 /build/firefox/trunk2/firefox-trunk-7.0~a1~hg20110618r71272+nobinonly/build-tree/mozilla/config/pythonpath.py -I../../config /build/firefox/trunk2/firefox-trunk-7.0~a1~hg20110618r71272+nobinonly/build-tree/mozilla/config/expandlibs_exec.py --uselist -- c++ -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -g -fno-strict-aliasing -std=gnu++0x -pthread -mthumb -pipe -DNDEBUG -DTRIMMED -g -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsRDFResource.o -lpthread -mthumb -Wl,-rpath-link,/build/firefox/trunk2/firefox-trunk-7.0~a1~hg20110618r71272+nobinonly/build-tree/mozilla/obj-arm-linux-gnueabi/dist/bin -Wl,-rpath-link,/usr/lib ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libjetpack_s.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libfileview.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libsystem-pref.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../stat...

Ok, this actually seems to be related with THUMB2 support.

Built firefox-5.0+build1+nobinonly without THUMB2 and disabling the ELF hack and now I'm fully able to play webm videos at youtube.

Seems THUMB2 support was enabled while fixing bug 696895, and probably nobody ever tested with webm, as it seems the problem only happens at the libvpx library (firefox keeps it's own version and link it against libxul.so). So a valid workaround for now would be basically disable THUMB2 while we work to enable thumb support again.

Will build again with latest nightly and also report the bug upstream.

Note that I've disabled elfhack entirely on our nightly builds anyway, as it's pretty much a no-op on Ubuntu

Merge proposal: https://code.launchpad.net/~rsalveti/firefox/natty-disable-thumb2/+merge/65757

SRU Justification for Natty:

Impact: Current firefox package enable THUMB2 support by default on ARM, but as a side effect this break WebM support, disabling youtube html5 support (this is important on ARM as we don't have public available flash plugins). The fix just disable THUMB2 support, and allow developers to easily change the rules file to package with THUMB2 again while debugging the issue.

Fix: Disable THUMB2 support while configuring the package on ARM.

Testcase: Open Firefox on Panda, go to www.youtube.com/html5, enable the trial and then try to open a WebM video.

I built firefox with this patch and pushed the packages at https://launchpad.net/~rsalveti/+archive/armel, so no FTBFS related with this change.

It looks like the underlying cause may be a bug in gas, which causes the wrong alignment to be set for code sections -- upstream binutils bug raised and cross-referenced from this bug.

When building firefox for Thumb, .text contains a mixture of Thumb code and ARM code (the ARM code comes from the */arm/*.asm files). The ARM code sections don't declare an appropriate alignment requirement in the objects output from the assembler, and end up in the final link aligned on an odd halfword offset.

Disassembling /usr/lib/firefox-5.0/libxul.so shows the boundary between compiler-generated Thumb code and the hand-written ARM assembler, with the ARM instructions on an invalid, non-word-aligned offset:

  61e6f2: 9201 str r2, [sp, #4]
  61e6f4: 6a5a ldr r2, [r3, #36] ; 0x24
  61e6f6: 695b ldr r3, [r3, #20]
  61e6f8: f42f efd0 blx 24e69c <_init+0x5da4>
  61e6fc: bd0e pop {r1, r2, r3, pc}

0061e6fe <vp8_decode_mb_tokens_v6>:
  61e6fe: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
  61e702: e24dd040 sub sp, sp, #64 ; 0x40
  61e706: e1a07001 mov r7, r1
  61e70a: e1a09000 mov r9, r0

Great Dave, I'm building firefox with the potential workaround described by you and should have the results in a few hours.

Built 5.0+build1+nobinonly-0ubuntu0.11.04.2 with the workaround and the bug is gone! You can find the test packages at https://launchpad.net/~linaro-maintainers/+archive/overlay (5.0+build1+nobinonly-0ubuntu0.11.04.2linaro2).

Also created a new merge proposal with this fix (https://code.launchpad.net/~rsalveti/firefox/natty-fix-thumb2/+merge/65922), instead of just disabling THUMB2 support.

Will now build the latest daily image and push the patch upstream as soon I confirm it also fixes upstream.

It would be interesting to try building the assembler code in Thumb since that would also fix this problem, but the code isn't 100% ready yet.

There are some bits that are not Thumb-ready (e.g., MOV pc, lr instead of BX lr), and because the assembler is invoked separately, ".thumb", ".syntax unified" and ".type <symblol>, %function" directives would be needed to make that work.

Could be worth feeding comments upstream (in addition to the workaround I posted earlier).

> Could be worth feeding comments upstream (in addition to the workaround
> I posted earlier).

Ricardo already filed https://bugzilla.mozilla.org/show_bug.cgi?id=666931

I discussed this with the libvpx ARM maintainer on IRC, and we produced https://review.webmproject.org/2568 (currently untested). Please test and let us know if this breaks anything.

See the following commit in binutils trunk.

If this is causing problems in other places, it could be worth
considering for backport into the linaro tools.

Cheers
---Dave

http://sourceware.org/bugzilla/show_bug.cgi?id=12931

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc
dot gnu.org> 2011-06-29 16:29:43 UTC ---
CVSROOT:    /cvs/src
Module name:    src
Changes by:    <email address hidden>    2011-06-29 16:29:38

Modified files:
   gas            : ChangeLog
   gas/config     : tc-arm.c

Log message:
   PR gas/12931
   * config/tc-arm.c (mapping_state): When changing to ARM or THUMB
   state set the minimum required alignment of the section.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.4527&r2=1.4528
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-arm.c.diff?cvsroot=src&r1=1.495&r2=1.496

Chris, how do you usually proceed when a patch is already available upstream but needs backporting for a previous Ubuntu version, like Natty?

I created the merge proposal at https://code.launchpad.net/~rsalveti/firefox/natty-fix-thumb2/+merge/65922 but don't know if you prefer to merge it or just wait it to land in a newer version and then just integrating it at Natty.

Let me know if there a way I can help you landing this on natty-updates.

@Ricardo Salveti

This would need to go through the normal SRU process after Firefox 6 is released or you can wait for Firefox 7 which will come ~Sep 27.

I would welcome it a lot to see this fix in the natty updates ! Thanks for investigating this. I have been wondering about this crash for a while.

On the cortex-a8 based htc hd2 the bug is reconstructable in natty with the following package versions of firefox and fennec :

firefox 6.0+build1+nobinonly-0ubuntu0.11.04.1
fennec 4.0~b3-0ubuntu2

Firefox 6.0 at Natty still has this issue as the patch is not yet applied. Also confirmed that this is already included at the 7.X version available for Oneiric, so once the 7 release is backported to Natty, this should be officially fixed.

Meanwhile I'll build and maintain the 6.0 version at the Linaro Overlay PPA.

This will be fixed with Firefox 7, so will close this in the changelog

This bug was fixed in the package firefox - 7.0.1+build1+nobinonly-0ubuntu0.11.04.1

---------------
firefox (7.0.1+build1+nobinonly-0ubuntu0.11.04.1) natty-security; urgency=low

  * New upstream stable release v7.0.1 (FIREFOX_7_0_1_BUILD1)

  * Add Mongolian and Swahili to locale blacklist. These aren't meant to be
    built on the release channel, but they still appear in the upstream
    shipped-locales
    - update debian/locales.blacklist

firefox (7.0+build2+nobinonly-0ubuntu0.11.04.1) natty-security; urgency=low

  * New upstream stable release (FIREFOX_7_0_BUILD2)
    - fix LP: #789198 - Firefox crashes when attempting to play webm video on
      ARM with Thumb2 enabled
    - see LP: #857098 for USN information

  [ Chris Coulson <email address hidden> ]
  * Rewrite the apport hook to be more useful
    - update debian/apport/firefox.py.in
  * Ship a file in /etc/apport/native-origins.d to enable bug reporting
    on PPA branches
    - add debian/apport/native-origins.in
    - rename debian/apport/firefox.in => debian/apport/blacklist.in
    - update debian/rules
    - update debian/firefox.install.in
    - update debian/firefox.dirs.in
  * Update the apport blacklist file now that the binary name has changed
    - update debian/apport/firefox.in
  * Dropped patches which are obsolete/fixed upstream
    - remove debian/patches/cairo-lcd-filter.patch
    - remove debian/patches/fix-sdk-bin-install.patch
    - update debian/patches/series
  * Refresh patches
    - update debian/patches/firefox-kde.patch
    - update debian/patches/mozilla-kde.patch
    - update debian/patches/reload-new-plugins.patch
  * Look in the correct location for the staged langpack xpi's. They moved
    from dist/install to dist/linux-$(DEB_HOST_GNU_CPU)
    - update debian/rules
  * Simplify firefox-dev.install a bit by installing everything in
    /usr/include
    - update debian/firefox-dev.install.in
  * Handle video/webm mimetypes
    - update debian/firefox.desktop.in
  * Fix check-sync-dirs.py test failure - ensure config/system-headers and
    js/src/config/system-headers are kept in sync
    - update debian/patches/unity-globalmenu-build-support-patch
  * Fix browserGlue_distribution.js and browserGlue_smartBookmarks.js xpcshell
    test failures. Update DEFAULT_BOOKMARKS_ON_MENU with the correct number of
    default bookmarks
    - update debian/patches/ubuntu-bookmarks.patch
  * Fix jsreftest failures by setting the correct timezone and locale
    - update debian/testsuite.mk
  * Switch off debian/patches/fix-selection-drag-autoscroll.patch for now. This
    code has been completely rewritten in Firefox 7
    - update debian/patches/series
  * Fix "format not a string literal and no format arguments" error
   - add debian/patches/printf-fix.patch
   - update debian/patches/series
  * Update for the binary name change
    - update debian/firefox.install.in
    - update debian/firefox.sh.in
  * Ensure we install dependentlibs.list so that Firefox knows which libs
    to dlopen before libxul
    - update debian/firefox.install.in
  * Get rid of some more hanging IPC xpcshell tests
    - update debian/testsuite.mk
  * Now Firefox lazy loads libxu...

fixed in oneiric

natty has seen the end of its life and is no longer receiving any updates. Marking the natty task for this ticket as "Won't Fix".