1194933 - ASan: SEGV in FastConvertYUVToRGB32Row

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: call_stack.txt

Comment 1

[Tyson Smith [:tsmith]]

Attachment: test_case.webm

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

To be clear - the workflow is to try and play back the above webm movie on Ubuntu, and this error happens.

Comment 3

[Lee Salzman [:lsalzman]]

I tried loading this in a Linux ASAN build, and I get no crash. I just see a message: "Video can't be played because the file is corrupt." Same behavior on a regular build as well.

So more information would be nice... What version of Firefox did this happen on for you? Does this happen on nightly?

Comment 4

[Tyson Smith [:tsmith]]

I am seeing this on nightly (Linux ASan). The latest build I tried was from ~12 hours ago.

Comment 5

[Andrew Comminos [:acomminos]]

(In reply to Lee Salzman [:eihrul] from comment #3)
> I tried loading this in a Linux ASAN build, and I get no crash. I just see a
> message: "Video can't be played because the file is corrupt." Same behavior
> on a regular build as well.

I get the same result (video can't be played) with 2015-08-25's linux64 debug asan nightly on Debian Stretch.

Comment 6

[Tyson Smith [:tsmith]]

(In reply to Andrew Comminos [:acomminos] from comment #5)
> (In reply to Lee Salzman [:eihrul] from comment #3)
> > I tried loading this in a Linux ASAN build, and I get no crash. I just see a
> > message: "Video can't be played because the file is corrupt." Same behavior
> > on a regular build as well.
> 
> I get the same result (video can't be played) with 2015-08-25's linux64
> debug asan nightly on Debian Stretch.

I was seeing this fairly frequently with my fuzzer. I'll update the ff build and post an update when I get some fresh results.

Comment 7

[u279076]

I tried to reproduce this on Fedora 22 (all updates installed) with today's ASAN Linux64 Nightly and it does not reproduce for me. 

Tyson, does this replicate outside of your fuzzer (ie. if you try to load the video manually)? If so, are there steps beyond just opening the webm file in Firefox that trigger this bug? All I get is an error stating the video is corrupt. If this only reproduces in your fuzzer we'll likely need access to it to regress this further. Alternatively I'd be happy to provide instructions so you could regress this locally.

In addition, can you please let me know your specific system configuration? It'd be useful to know exactly which version of Ubuntu you're using, your Desktop Environment and version, as well as any changes you've made to the default system configuration. At this point it might also help to have a copy of your about:support page attached to this bug.

Thanks

Comment 8

[Tyson Smith [:tsmith]]

Attachment: about-support.txt

Comment 9

[Tyson Smith [:tsmith]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #7)
> Tyson, does this replicate outside of your fuzzer (ie. if you try to load
> the video manually)? 
No. This issue seems to have a race component to it :(

> In addition, can you please let me know your specific system configuration?
Ubuntu 14.04.3 Desktop (and Server using xvfb on other fuzzing boxes)

> At this point it might also help to have a
> copy of your about:support page attached to this bug.
Attached.

At the moment I see this issue every 10 minutes or so. I'd be willing to try other builds if anyone has any suggestions.

Comment 10

[Tyson Smith [:tsmith]]

Could bug 1197935 be related to this issue?

Comment 12

[Andrew McCreight [:mccr8]]

The duped bug has some more specific steps to reproduce this. Maybe somebody can try to take a look again? (FWIW, this seems to involve the same pref as bug 1203763, but I don't know if that means it is related.)

Comment 13

[Lee Salzman [:lsalzman]]

(In reply to Andrew McCreight [:mccr8] from comment #12)
> The duped bug has some more specific steps to reproduce this. Maybe somebody
> can try to take a look again? (FWIW, this seems to involve the same pref as
> bug 1203763, but I don't know if that means it is related.)

I tried reproducing again, but still no luck.

Comment 14

[Tyson Smith [:tsmith]]

I updated to a new firefox build and put some fuzzers on this. I'll see what comes up in the next 24h or so.

Comment 15

[Tyson Smith [:tsmith]]

I let the fuzzers run over the weekend and I have not seen this issue.

Comment 16

[Tyson Smith [:tsmith]]

Attachment: call_stack_valgrind.txt

I was able to find an invalid read with valgrind that looks like it may be related.

Comment 17

[Tyson Smith [:tsmith]]

Attachment: test_case_valgrind.webm

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

Anything we can tell from the stack that would let us get a version built for Tyson to try and get us more information, if this is still not locally reproducible?

Comment 19

[Lee Salzman [:lsalzman]]

(In reply to Milan Sreckovic [:milan] from comment #18)
> Anything we can tell from the stack that would let us get a version built
> for Tyson to try and get us more information, if this is still not locally
> reproducible?

The stack just points into the same big uncommented block of assembly. You could hypothetically try disabling the SSE support in ConvertYCbCrToRGB32 to see if it is just a bug in the assembly code itself and the unaccelerated code is fine, or if it is a deeper issue that exists in both paths.

It would take a bit to digest what the assembly is doing there, so would be better to verify that the problem is specifically in the assembly first.

Comment 20

[Tyson Smith [:tsmith]]

Attachment: another_valgrind_log.txt

This one looks a little different. Figured I'd add it just in case.

Comment 21

[Andrew McCreight [:mccr8]]

Tyson, can you still reproduce these issues? Maybe this should be closed as incomplete and new bugs filed for new test cases? Thanks.

Comment 22

[Tyson Smith [:tsmith]]

I will close this and log anything that pops up.