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

Arithmetic overflow on shrinking window #236

Closed
gmorenz opened this issue Mar 11, 2016 · 1 comment
Closed

Arithmetic overflow on shrinking window #236

gmorenz opened this issue Mar 11, 2016 · 1 comment

Comments

@gmorenz
Copy link
Contributor

@gmorenz gmorenz commented Mar 11, 2016

Webrender programs (including servo) crash when shrinking the window with the following error:

thread '<main>' panicked at 'arithmetic operation overflowed', /home/normal/.multirust/cargo/git/checkouts/webrender-ec406de34643a7ef/master/src/renderer.rs:1151
stack backtrace:
   1:     0x558d42358200 - sys::backtrace::tracing::imp::write::h1df2fc52f5a1077eehv
   2:     0x558d4235abfb - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44584
   3:     0x558d4235a868 - panicking::default_handler::hdd51c136086dc3e0CWz
   4:     0x558d4234f88c - sys_common::unwind::begin_unwind_inner::h3a281a3586db30a7x5t
   5:     0x558d4234fd18 - sys_common::unwind::begin_unwind_fmt::heafd13fa24ecdc24D4t
   6:     0x558d42357671 - rust_begin_unwind
   7:     0x558d4238a02f - panicking::panic_fmt::h98b8cbb286f5298alcM
   8:     0x558d4238a308 - panicking::panic::h4265c0105caa1121SaM
   9:     0x558d421d024c - renderer::Renderer::draw_layer::h373ff08c64417302dot
                        at /home/normal/.multirust/cargo/git/checkouts/webrender-ec406de34643a7ef/master/src/renderer.rs:1151
  10:     0x558d421beaab - renderer::Renderer::draw_frame::h3813b56ac28d901enSt
                        at /home/normal/.multirust/cargo/git/checkouts/webrender-ec406de34643a7ef/master/src/renderer.rs:1662
  11:     0x558d421bc2aa - renderer::Renderer::render::_$u7b$$u7b$closure$u7d$$u7d$::closure.32236
                        at /home/normal/.multirust/cargo/git/checkouts/webrender-ec406de34643a7ef/master/src/renderer.rs:397
  12:     0x558d421bc194 - profiler::TimeProfileCounter::profile::h1814810466230545351
                        at /home/normal/.multirust/cargo/git/checkouts/webrender-ec406de34643a7ef/master/src/profiler.rs:122
  13:     0x558d421bbf78 - renderer::Renderer::render::hda829cc1b47ef2cdUMs
                        at /home/normal/.multirust/cargo/git/checkouts/webrender-ec406de34643a7ef/master/src/renderer.rs:387
  14:     0x558d41f24fcc - main::h863aa207fe202af4Fba
                        at src/main.rs:102
  15:     0x558d4235a4c4 - sys_common::unwind::try::try_fn::h14340067080102042102
  16:     0x558d423575fb - __rust_try
  17:     0x558d42359f5b - rt::lang_start::h582466266dfb2119IOz
  18:     0x558d41f85a39 - main
  19:     0x7f41e8bc170f - __libc_start_main
  20:     0x558d41f23ba8 - _start
  21:                0x0 - <unknown>

Backtrace generated from this code but servo generates a slightly longer but otherwise identical one.

@gmorenz
Copy link
Contributor Author

@gmorenz gmorenz commented Mar 20, 2016

I'm going to spend a bit of time trying to fix this.

bors-servo added a commit that referenced this issue Mar 29, 2016
Use signed arithmetic to avoid underflow when shrinking window.

fixes #236

The underflow occurs when the y co-ordinate of `viewport_size` in the last `render_api.set_root_stacking_context` call is bigger than the y co-ordinate of  `framebuffer_size` in a `renderer.render` call.

The problem is the calculated layer_origin y is negative, but we calculate it using unsigned ints, and then cast to signed just for the gl calls. The two places where this calculated value is used are `gl::scissor` and `gl::viewport`, both of these are perfectly happy with a negative origin point (as far as I know and can tell, but I don't have much experience with opengl), thus I've just changed it so we cast to signed integers early.

The other options would be to require the above doesn't happen, either by using an outdated bigger framebuffer size (which results in the contents of the window moving upwards as the window shrinks), or recalling `set_root_stacking_context` (which is less efficient).
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.

1 participant
You can’t perform that action at this time.