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

[master, 18.04] Segfault in renderer #1332

Closed
AlanGriffiths opened this issue Feb 28, 2020 · 6 comments · Fixed by #1343 or #1356
Closed

[master, 18.04] Segfault in renderer #1332

AlanGriffiths opened this issue Feb 28, 2020 · 6 comments · Fixed by #1343 or #1356
Assignees
Labels

Comments

@AlanGriffiths
Copy link
Contributor

  1. Start multiscreen Mir-on-X: miral-app -demo-server --x11-output 640x480:800x600.
  2. Position windows side-by-side to make it easy to move cursor across windows.
  3. Drag the terminal window back and forth between windows.

Expect: everything works smoothly.
Actual: lots of flickering and odd display effects, followed by a core dump.

(gdb) bt
#0  0x00007fdba09fda9a in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#1  0x00007fdba09fdf4a in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2  0x00007fdba0a068ca in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3  0x00007fdba0a06b84 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x00007fdba09d6def in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x00007fdba0c64c28 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#6  0x00007fdba0c64cc5 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#7  0x00007fdbadb6c0d4 in mir::renderer::gl::Renderer::draw(mir::graphics::Renderable const&) const (this=0x7fdb8c000b20, renderable=...)
    at /home/alan/display_server/mir/src/renderers/gl/renderer.cpp:615
#8  0x00007fdbadb6b45d in mir::renderer::gl::Renderer::render(std::vector<std::shared_ptr<mir::graphics::Renderable>, std::allocator<std::shared_ptr<mir::graphics::Renderable> > > const&) const (this=0x7fdb8c000b20, renderables=std::vector of length 1, capacity 1 = {...})
    at /home/alan/display_server/mir/src/renderers/gl/renderer.cpp:421
#9  0x00007fdbad930728 in mir::compositor::DefaultDisplayBufferCompositor::composite(std::vector<std::shared_ptr<mir::compositor::SceneElement>, std::allocator<std::shared_ptr<mir::compositor::SceneElement> > >&&) (this=0x7fdb8c02c7e0, scene_elements=...)
    at /home/alan/display_server/mir/src/server/compositor/default_display_buffer_compositor.cpp:84
#10 0x00007fdbad936781 in mir::compositor::CompositingFunctor::operator()() (this=0x561f7d266d50)
    at /home/alan/display_server/mir/src/server/compositor/multi_threaded_compositor.cpp:141
#11 0x00007fdbad93c311 in std::__invoke_impl<void, mir::compositor::CompositingFunctor&>(std::__invoke_other, mir::compositor::CompositingFunctor&) (__f=...) at /usr/include/c++/7/bits/invoke.h:60
#12 0x00007fdbad93b8b4 in std::__invoke<mir::compositor::CompositingFunctor&>(mir::compositor::CompositingFunctor&) (__fn=...) at /usr/include/c++/7/bits/invoke.h:95
#13 0x00007fdbad93aae0 in std::reference_wrapper<mir::compositor::CompositingFunctor>::operator()<>() const (this=0x7fdb9d831af0) at /usr/include/c++/7/bits/refwrap.h:356
#14 0x00007fdbad939aac in std::_Function_handler<void (), std::reference_wrapper<mir::compositor::CompositingFunctor> >::_M_invoke(std::_Any_data const&) (__functor=...)
    at /usr/include/c++/7/bits/std_function.h:316
#15 0x00007fdbad7d2dbc in std::function<void ()>::operator()() const (this=0x7fdb9d831af0)
    at /usr/include/c++/7/bits/std_function.h:706
#16 0x00007fdbadb2c51d in (anonymous namespace)::Task::execute() (this=0x7fdb9d831af0)
    at /home/alan/display_server/mir/src/server/thread/basic_thread_pool.cpp:40
#17 0x00007fdbadb2c878 in (anonymous namespace)::Worker::operator()() (this=0x561f7cb65140)
@AlanGriffiths
Copy link
Contributor Author

Hmm. This seems to be a difference between master (problems) and 1.7.1 (works as expected).

@AlanGriffiths AlanGriffiths changed the title Segfault in renderer [master, not 1.x] Segfault in renderer Feb 28, 2020
@AlanGriffiths AlanGriffiths self-assigned this Feb 28, 2020
@AlanGriffiths
Copy link
Contributor Author

OK, seems to be #1148 (graphics/wayland: Handle wl_shm buffers through the WaylandAllocator r=wmww a=RAOF). Preparing a revert...

bors bot added a commit that referenced this issue Mar 4, 2020
1343: platform: Ensure each rendering thread has a separate gl::Program. r=AlanGriffiths a=RAOF

The GL uniforms (such as, for example, screen position) are per Program state, *not*
per context state, so when there were multiple rendering threads they would race.

Fix this by generating a `Program` per `ProgramFactory`; we already had a `ProgramFactory`
per thread.

Fixes: #1332, #1317

Co-authored-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
@bors bors bot closed this as completed in #1343 Mar 4, 2020
@bors bors bot closed this as completed in 99680ab Mar 4, 2020
@AlanGriffiths
Copy link
Contributor Author

Despite the purported fix landing, this now seems to be happening on 18.04, but not on 20.04

@AlanGriffiths AlanGriffiths reopened this Mar 4, 2020
@AlanGriffiths AlanGriffiths changed the title [master, not 1.x] Segfault in renderer [master, 18.04] Segfault in renderer Mar 4, 2020
@AlanGriffiths
Copy link
Contributor Author

Raised against mesa om LP: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1866069

@AlanGriffiths
Copy link
Contributor Author

Raised against mesa om LP: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1866069

Found Mir uploading to a texture (again) after it was initialized.

@AlanGriffiths
Copy link
Contributor Author

Note that i965 on 18.04 is a lot more sensitive to this than other drivers.

@bors bors bot closed this as completed in fd74a01 Mar 9, 2020
@bors bors bot closed this as completed in #1356 Mar 9, 2020
wmww pushed a commit that referenced this issue Apr 1, 2020
1343: platform: Ensure each rendering thread has a separate gl::Program. r=AlanGriffiths a=RAOF

The GL uniforms (such as, for example, screen position) are per Program state, *not*
per context state, so when there were multiple rendering threads they would race.

Fix this by generating a `Program` per `ProgramFactory`; we already had a `ProgramFactory`
per thread.

Fixes: #1332, #1317

Co-authored-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
AlanGriffiths pushed a commit that referenced this issue Apr 2, 2020
1356: Make various texture bind() functions threadsafe r=wmww a=AlanGriffiths

Make various texture bind() functions threadsafe. (Fixes: #1332)

The one that was actually causing #1332 was re-uploading a texture on multiple threads.
wmww pushed a commit that referenced this issue Apr 3, 2020
1356: Make various texture bind() functions threadsafe r=wmww a=AlanGriffiths

Make various texture bind() functions threadsafe. (Fixes: #1332)

The one that was actually causing #1332 was re-uploading a texture on multiple threads.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment