1162470 - Segfault at ofrinter2_lp_arm when viewing theora file on Firefox compiled for ARM

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[sam tygier]

Attachment: firefox_gdb.log

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux armv7l; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150417180557

Steps to reproduce:

37.0.2 on ubuntu on raspberry pi. crashes every time on www.vice.com. GDB log attached.

Package: firefox 37.0.2+build1-0ubuntu0.15.04.1
Uname: Linux 3.18.0-21-rpi2 armv7l

also reported at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1452692


Actual results:

Visit www.vice.com
Segfault at 
0x753f474a in ofrinter2_lp_arm () at /build/buildd/firefox-37.0.2+build1/obj-arm-linux-gnueabihf/media/libtheora/armfrag-gnu.s:263

Comment 1

[sam tygier]

Attachment: firefox_info.txt

Comment 2

[:Gijs (he/him)]

(In reply to sam tygier from comment #0)
> 37.0.2 on ubuntu on raspberry pi. crashes every time on www.vice.com. GDB
> log attached.

Can you try with a recent official nightly? ( https://nightly.mozilla.org/ )

and submit a crash report if it reproduces there? Trying with an official build of 38 ( http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-beta/ ) would also be useful.

It would also be useful to have a copy of the video that causes this crash. I get localized (British) content on vice.com, so I'm not sure offhand which video is causing this.


> Package: firefox 37.0.2+build1-0ubuntu0.15.04.1
> Uname: Linux 3.18.0-21-rpi2 armv7l
> 
> also reported at
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1452692

This link is dead.

Comment 3

[sam tygier]

I can't see any linux arm builds at that link. I don't see the crash on linux x86 with 37.0.2, and judging by the backtrace is arm specific. I guess I could build it, but that could take a while.

I am also in the UK, so I guess we are seeing the same page version.

Launchpad bug is also tag as possible security issue (segfaults in a browser are a potential issue right?). Right now there is no additional information there, but i can maybe add you as a CC.

Comment 4

[:Gijs (he/him)]

(In reply to sam tygier from comment #3)
> I can't see any linux arm builds at that link. I don't see the crash on
> linux x86 with 37.0.2, and judging by the backtrace is arm specific. I guess
> I could build it, but that could take a while.

Fair.

> I am also in the UK, so I guess we are seeing the same page version.

Hmm. I don't see any videos on the page, though... (document.querySelectorAll('video') returns an empty nodelist...)


> Launchpad bug is also tag as possible security issue (segfaults in a browser
> are a potential issue right?). Right now there is no additional information
> there, but i can maybe add you as a CC.

Ah, OK, sorry - I assumed it would tell be something else in that case.
Anyway, I'm not the most important person to CC, let's see if some of our media folks can chime in...

Comment 5

[sam tygier]

I get the same crash at http://quirksmode.org/html5/videos/big_buck_bunny.ogv so I guess it is any theora file.

Comment 6

[:Gijs (he/him)]

Vlad, looks like you originally fixed this in bug 511038. Do you have time to look at this and/or can you recommend someone else?

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Very much doubt this is related to bug 511038 at all, other than happening in theora & on ARM.  I would suggest someone on ajones' team, or maybe monty...

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Theora isn't a priority for my team. Brion - are you interested?

Comment 9

[Timothy B. Terriberry (:derf)]

(In reply to :Gijs Kruitbosch from comment #2)
> It would also be useful to have a copy of the video that causes this crash.
> I get localized (British) content on vice.com, so I'm not sure offhand which
> video is causing this.

I get no videos at all, so yes, a direct video URL or file is pretty essential, here.

The stack trace is likely to be bogus, as ofrinter_lp_arm is a label inside oc_frag_recon_inter_arm(), which is absolutely never called from oc_dec_headerin().

This code is for ARMv4, but we have an ARMv6 version and the Raspberry Pi should support it, so I don't know why it would ever be run at all. Without working steps to reproduce or a valid stack trace, I am not sure how to proceed here.

Comment 10

[sam tygier]

Also crashes with http://quirksmode.org/html5/videos/big_buck_bunny.ogv (can someone edit the original description?)

This is on raspberrypi2 so arm7.

Comment 11

[Timothy B. Terriberry (:derf)]

(In reply to sam tygier from comment #10)
> Also crashes with http://quirksmode.org/html5/videos/big_buck_bunny.ogv (can
> someone edit the original description?)

Okay, I no longer have a functioning m-c setup for ARM, so it will take me a while to try to reproduce. Any better information you can get from a debugger in the meantime would be helpful (specifically, try breaking on oc_dec_headerin and stepping through).

> This is on raspberrypi2 so arm7.

There is also a NEON version: oc_frag_recon_intern_neon(). Even if there wasn't, it should fall back to ARMv6 code before going all the way back to ARMv4.

Comment 12

[sam tygier]

Here is gdb log with breaking on oc_dec_headerin and stepping through. Let me know what other info you'd like. Would it be useful for me to unpack the source package at the path it expects?

I have tried building current version of firefox, but I hit

370:29.31 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/bilinearpredict_neon.o uses VFP register arguments, output does not
370:29.31 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/idct_blk_neon.o uses VFP register arguments, output does not
370:29.31 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/denoising_neon.o uses VFP register arguments, output does not
370:29.31 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/picklpf_arm.o uses VFP register arguments, output does not
370:29.31 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/vp9_convolve_neon.o uses VFP register arguments, output does not
370:29.32 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/vp9_idct16x16_neon.o uses VFP register arguments, output does not
370:29.32 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/vp9_loopfilter_16_neon.o uses VFP register arguments, output does not
370:29.32 /usr/bin/ld.gold.real: error: /home/sam/mozilla-central/obj-armv7l-unknown-linux-gnueabihf/toolkit/library/../../media/libvpx/yv12extend_arm.o uses VFP register arguments, output does not
370:29.32 collect2: error: ld returned 1 exit status
370:29.32 /home/sam/mozilla-central/config/rules.mk:814: recipe for target 'libxul.so' failed

I tried MOZ_FLOAT_ABI=hard, but that does not seem to help. An ideas? I'll see if I can track down the .mozconfig that the ubuntu package is built with.

Comment 13

[sam tygier]

Attachment: firefox_gdb4.log

Comment 14

[Timothy B. Terriberry (:derf)]

> Here is gdb log with breaking on oc_dec_headerin and stepping through. Let
> me know what other info you'd like. Would it be useful for me to unpack the
> source package at the path it expects?

The source here has fortunately not changed in a while, so it is relatively easy to match line numbers.

This log is very helpful. The call that appears to be failing is actually the very first call to oc_pack_read_arm(), which is also hand-written ARMv4 assembly. There is no ARMv6 or NEON version of this function (it is serial code, not SIMD), so at least this much of the trace makes sense.

There are a few likely suspects. One is that the structure offsets of oc_pack_buf are somehow not the same on your system as they are on other 32-bit ARM systems. I am not quite certain yet how this would lead to loading a value into PC that is in the ofrinter2_lp_arm region, but as the function saves/restores the return address onto the stack, it is possible it is being corrupted somewhere. Would it be too much trouble to ask you to post a log using "stepi" and "info registers" once you reach the oc_pack_read_arm() invocation?

> I tried MOZ_FLOAT_ABI=hard, but that does not seem to help. An ideas? I'll
> see if I can track down the .mozconfig that the ubuntu package is built with.

I have not seen these errors before, so I'm not sure what the problem is. Getting the same .mozconfig would definitely be helpful. If you do get your own builds working, another very simple test is to change line 32 of media/libtheora/lib/arm/armbits.h from

# if defined(OC_ARM_ASM)

to 

# if 0&&defined(OC_ARM_ASM)

This will disable the asm versions of the bitreading code.

Comment 15

[sam tygier]

Attachment: firefox_gdb5.log

gdb log with stepi in oc_pack_read_arm

Comment 16

[Timothy B. Terriberry (:derf)]

(In reply to sam tygier from comment #15)
> Created attachment 8604218 [details]
> firefox_gdb5.log
> 
> gdb log with stepi in oc_pack_read_arm

Perfect. Here is your problem:
pc             0x753f7246	0x753f7246 <oc_pack_read_arm+2>

It is treating this code as Thumb code, even though it is not. I believe this is a build system/configuration issue, and not a problem with the code.

Comment 17

[Timothy B. Terriberry (:derf)]

NI'ing glandium to see if he has any ideas why the invocation would enter this code in Thumb mode instead of ARM mode.

Comment 18

[Mike Hommey [:glandium]]

Please put your libxul.so somewhere it can be downloaded, and attach a new gdb log with registers on the steps before reaching oc_pack_read_arm.

Comment 19

[Mike Hommey [:glandium]]

(Note this is very likely not a security issue)

Comment 20

[sam tygier]

http://www.hep.manchester.ac.uk/u/samt/pub/libxul.so

firefox_gdb6.log has info registers at every stepi.

I'm happy for the security page lock to be removed then.

Also attached the mozconfig that I think ubuntu is using. I tried building the current hg with "ac_add_options --host=arm-linux-gnueabihf", but I still get similar errors: 

529:51.89 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/bilinearpredict_neon.o does not
529:51.89 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/bilinearpredict_neon.o
529:51.89 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/idct_blk_neon.o does not
529:51.89 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/idct_blk_neon.o
529:51.89 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/denoising_neon.o does not
529:51.89 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/denoising_neon.o
529:51.89 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/picklpf_arm.o does not
529:51.89 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/picklpf_arm.o
529:51.89 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/vp9_convolve_neon.o does not
529:51.90 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/vp9_convolve_neon.o
529:51.90 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/vp9_idct16x16_neon.o does not
529:51.90 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/vp9_idct16x16_neon.o
529:51.90 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/vp9_loopfilter_16_neon.o does not
529:51.90 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/vp9_loopfilter_16_neon.o
529:51.90 /usr/bin/ld.bfd.real: error: libxul.so uses VFP register arguments, ../../media/libvpx/yv12extend_arm.o does not
529:51.90 /usr/bin/ld.bfd.real: failed to merge target specific data of file ../../media/libvpx/yv12extend_arm.o
529:51.90 /usr/bin/ld.bfd.real: failed to set dynamic section sizes: Memory exhausted
529:51.90 collect2: error: ld returned 1 exit status
529:51.90 /home/sam/mozilla-central/config/rules.mk:814: recipe for target 'libxul.so' failed

Comment 21

[sam tygier]

Attachment: firefox_gdb6.log

Comment 22

[sam tygier]

Attachment: mozconfig-ubuntu

Comment 23

[Nils Ohlmeier [:drno]]

Mass closing because of inactivity.
Please feel free to re-open if still relevant.