1253287 - Hitting MOZ_ASSERT(aVsyncTimestamp <= TimeStamp::Now()) in nsRefreshDriver.cpp

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[SkyLined]

Every now and then, I am hitting this assert when I am fuzzing Firefox.

https://dxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.cpp#502

I am unable to reproduce using the data I fed to Firefox. From the code it appears that the issue is timing related. There is no inline documentation or context to let me know what is going on and I am not familiar with the code, so I can not investigate further.

Comment 1

[Michelle Funches - QA]

@Reporter: we need more details so that we can try to reproduce and determine the correct component.
[Detailed Steps to Reproduce; Operating System]

Comment 2

[SkyLined]

Not sure what you want from me; the requested information is there, but let me clarify:
* I am unable to reproduce this manually - it happens every now and then during automated fuzzing. I therefore cannot provide steps to reproduce at this point.
* I set the platform to Windows in the initial report. It appears to happen on x86 and x64, but I have not confirmed this.

I opened this bug without further information because I need help tracking down what triggers it. I have no knowledge of the code and the assert I am hitting has no documentation explaining what it is checking or what might cause it to fail. I am looking for somebody familiar with the code who can explain this, so I can try to improve my testing to detect what is triggering it. Only then will I be able to provide you with more information.

Comment 3

[Michelle Funches - QA]

@Jesse - can you assist with this?

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Mason, any thoughts here?

Comment 5

[Mason Chang [Inactive] [:mchang]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)
> Mason, any thoughts here?

This is timing related, but it probably is coming from the test framework if we're hitting that assertion. Usually, we send the refresh driver a vsync timestamp from our vsync source, but we also assert that our vsync source is sending a timestamp bound by Now(). 

What are you fuzzing? If you're fuzzing vsync timestamps, the assertion is probably correct.

Comment 6

[SkyLined]

I am fuzzing HTML parsing, as well as the DOM and JavaScript APIs from a webpage loaded in the current release build of Firefox on Windows 10 in a Hyper-V VM. If set it up to resemble a real-life Firefox install where the user simply loads a webpage. Hitting this during fuzzing should mean it can happen in real life when a user loads a specially crafted webpage.

Comment 7

[Mason Chang [Inactive] [:mchang]]

A test case would be useful. Generally this means we're forcing a refresh driver tick with a bad timestamp. Since this is on windows, but on a hyper vm, I'm not sure if we're using vsync from the DWM [1] or just falling back to Software [2]. Otherwise, if you can attach the stack trace when you get this assertion, that would also help.

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp?from=gfxWindowsPlatform.cpp#2872
[2] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/SoftwareVsyncSource.cpp?from=SoftwareVsyncSource.cpp#108

Comment 8

[Ryan VanderMeulen [:RyanVM]]

SkyLined, is it possible for you provide the information requested in comment 7? It's going to be hard to make this bug actionable otherwise.

Comment 9

[SkyLined]

Alas, I seem to have not stored any of my crash reports and I haven't seen this crash in a while. I'll close it out and reopen with a stack should I see the crash again.

Comment 10

[Firefox Bug Husbandry Bot]

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598