Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assertion failure in clear_target: DEPTH_WRITEMASK is 0 #2339

Closed
staktrace opened this issue Jan 24, 2018 · 5 comments
Closed

assertion failure in clear_target: DEPTH_WRITEMASK is 0 #2339

staktrace opened this issue Jan 24, 2018 · 5 comments

Comments

@staktrace
Copy link
Contributor

@staktrace staktrace commented Jan 24, 2018

Filing for https://bugzilla.mozilla.org/show_bug.cgi?id=1432819, seems to be an intermittent failure in mozilla-central CI. The panic is coming from this line - apparently both arguments are 0 so the debug_assert_ne is failing.

@kvark
Copy link
Member

@kvark kvark commented Jan 24, 2018

Good, means we have a logic bug and now my new checks panic on it. Hope it's not too annoying for Gecko. I'll look into it.

@kvark
Copy link
Member

@kvark kvark commented Jan 24, 2018

Hmm, scanning the code it seems pretty solid on enforcing the invariants about depth clearing. Could we get a more detailed @staktrace (no pun!)?

@staktrace
Copy link
Contributor Author

@staktrace staktrace commented Jan 24, 2018

The log pointed to in the bug has a stacktrace which isn't properly symbolicated. I pulled the xul.sym file for the build (it's in the target.crashreporter-symbols-full.zip artifact that's uploaded for the build job corresponding to the test job that failed) and did some symbolication-by-hand for the addresses. I got the xul.dll base address from the c6b19016-5e9e-4177-8bee-9530b869c841.extra artifact on the test job itself. Below is the stacktrace with the frames I symbolicated. I doubt it's very useful though:

stack backtrace:
0x7ff9923f4941 - <unknown>
0x7ff9924079ac - <unknown>
0x7ff992407695 - <unknown>
0x7ff992408033 - <unknown>
0x7ff992407ea8 - <unknown>
0x7ff992407d81 - <unknown> // std::panicking::begin_panic_fmt
0x7ff9929df8ea - <unknown> // webrender::device::Device::clear_target
0x7ff992a8aca7 - <unknown> // webrender::renderer::{{impl}}::render_impl::{{closure}}
0x7ff992a87c54 - <unknown> // webrender::renderer::Renderer::render_impl
0x7ff992a877f1 - <unknown> // webrender::renderer::Renderer::render
0x7ff992397011 - <unknown> // webrender_bindings::bindings::wr_renderer_render
0x7ff993f2986e - mozilla_dump_image // mozilla::wr::RendererOGL::Render()
0x7ff993f2b1c1 - mozilla_dump_image // mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId)
0x7ff993f27d70 - mozilla_dump_image
0x7ff993f29c8a - mozilla_dump_image
0x7ff993372138 - <unknown>
0x7ff99336bb46 - <unknown>
0x7ff99336c2f9 - <unknown>
0x7ff993371eff - <unknown>
0x7ff993372025 - <unknown>
0x7ff993371c35 - <unknown>
0x7ff99337328c - <unknown>
0x7ff99335d789 - <unknown>

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1432886 to make the symbolication better by default.

Edited to fill in a couple of the mozilla_dump_image frames as well, those aren't really in mozilla_dump_image.

@kvark
Copy link
Member

@kvark kvark commented Jan 24, 2018

Thanks!

seems to be an intermittent failure in mozilla-central CI

The fact it's an intermittent is worrying though. The assertion is pretty deterministic.
Might be a sign of a memory corruption affecting either WR or the driver.

@staktrace
Copy link
Contributor Author

@staktrace staktrace commented Jan 25, 2018

Apparently it was on a broken machine, https://bugzilla.mozilla.org/show_bug.cgi?id=1432819#c2

@staktrace staktrace closed this Jan 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.