[regression] Mir servers crashing in malloc() with heap corruption

[Daniel van Vugt]

Mir servers are crashing (after a while) in malloc() with heap corruption.

Test case:
  1. Start mir_proving_server
  2. Start lots of clients (e.g. 30+ mir_demo_client_egltriangle)
  3. Wait a while and the server will crash.

(gdb) bt
#0 _int_malloc (av=av@entry=0x7f1000000020, bytes=bytes@entry=296)
    at malloc.c:3489
#1 0x00007f1015728e0c in __libc_calloc (n=<optimised out>,
    elem_size=<optimised out>) at malloc.c:3219
#2 0x00007f1014c53a82 in g_malloc0 ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f1014c4b9e7 in g_source_new ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f1016c7e782 in mir::detail::add_timer_gsource(_GMainContext*, std::shared_ptr<mir::time::Clock> const&, std::function<void ()> const&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >) (main_context=0x1cbc160, clock=
    std::shared_ptr (count 16, weak 1) 0x1cbc250, handler=..., target_time=...)
    at /home/dan/bzr/mir/dev/src/server/glib_main_loop_sources.cpp:287
#5 0x00007f1016c76f48 in (anonymous namespace)::AlarmImpl::reschedule_for (
    this=0x7f100000af80, time_point=...)
    at /home/dan/bzr/mir/dev/src/server/glib_main_loop.cpp:69
#6 0x00007f1016c76e7b in (anonymous namespace)::AlarmImpl::reschedule_in (
    this=0x7f100000af80, delay=...)
    at /home/dan/bzr/mir/dev/src/server/glib_main_loop.cpp:61
#7 0x00007f1016d71354 in (anonymous namespace)::TimeoutFrameDroppingPolicy::swap_now_blocking (this=0x7f100000ea30)
    at /home/dan/bzr/mir/dev/src/server/compositor/timeout_frame_dropping_policy_factory.cpp:69
#8 0x00007f1016d72af1 in mir::compositor::BufferQueue::client_acquire(std::function<void (mir::graphics::Buffer*)>) (this=0x7f100000fd20, complete=...)
    at /home/dan/bzr/mir/dev/src/server/compositor/buffer_queue.cpp:180
#9 0x00007f1016d55c8b in mir::compositor::BufferStreamSurfaces::acquire_client_buffer(std::function<void (mir::graphics::Buffer*)>) (this=0x7f100000faf0,
    complete=...)
    at /home/dan/bzr/mir/dev/src/server/compositor/buffer_stream_surfaces.cpp:55
#10 0x00007f1016cfc07c in mir::scene::BasicSurface::swap_buffers(mir::graphics::Buffer*, std::function<void (mir::graphics::Buffer*)>) (this=0x7f1000010570,
    old_buffer=0x7f100000f290, complete=...)
    at /home/dan/bzr/mir/dev/src/server/scene/basic_surface.cpp:216

[Daniel van Vugt (vanvugt)]

I *think* this has been happening on occasion for at least a month or so.

[Daniel van Vugt (vanvugt)]

Found the problem. It's all GlibMainLoop stuff, which I think was introduced in r2072 (and in Mir 0.9!). Valgrind log attached.

------------------------------------------------------------
revno: 2072 [merge]
tags: br0.9, v0.9.0
author: Alexandros Frantzis <email address hidden>
committer: Tarmac
branch nick: development-branch
timestamp: Wed 2014-11-19 02:07:20 +0000
message:
  server: Use the GLibMainLoop implementation by default

  This MP also adds an option of using the AsioMainLoop implementation (--use-asio-main-loop or MIR_SERVER_USE_ASIO_MAIN_LOOP) for easier comparative testing. Fixes: https://bugs.launchpad.net/bugs/1392256.

  Approved by PS Jenkins bot, Cemil Azizoglu, Alan Griffiths, Kevin DuBois.
------------------------------------------------------------