mir server crashes with SIGFPE in glEGLImageTargetTexture2DOES

Bug #1124948 reported by Daniel van Vugt on 2013-02-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Alexandros Frantzis
mir (Ubuntu)

Bug Description

mir server crashes with SIGFPE in glEGLImageTargetTexture2DOES.

I discovered this by accident. Create a simple connection and surface with EGL initialization. If the surface was created with an unsupported pixel format then as soon as the client calls eglInitialize, the server will crash. Obviously an error should have been reported to the client. The server should not crash...

Program received signal SIGFPE, Arithmetic exception.
intel_set_texture_image_region (ctx=ctx@entry=0x785f20,
    image=image@entry=0xa26de0, region=0x7fffdc001e90,
    target=target@entry=3553, internalFormat=<optimised out>,
    format=<optimised out>, offset=0) at intel_tex_image.c:280
280 intel_tex_image.c: No such file or directory.
(gdb) bt
#0 intel_set_texture_image_region (ctx=ctx@entry=0x785f20,
    image=image@entry=0xa26de0, region=0x7fffdc001e90,
    target=target@entry=3553, internalFormat=<optimised out>,
    format=<optimised out>, offset=0) at intel_tex_image.c:280
#1 0x00007ffff3669b4a in intel_image_target_texture_2d (ctx=0x785f20,
    target=3553, texObj=<optimised out>, texImage=0xa26de0,
    image_handle=<optimised out>) at intel_tex_image.c:364
#2 0x00007ffff319ff97 in _mesa_EGLImageTargetTexture2DOES (target=3553,
    image=0xa63530) at ../../../../../src/mesa/main/teximage.c:3207
#3 0x00007ffff7b9f32d in (anonymous namespace)::EGLImageBufferTextureBinder::bind_to_texture (this=0x7fffdc001f10)
    at /home/dan/bzr/mir/toy/src/graphics/gbm/gbm_buffer_allocator.cpp:101
#4 0x00007ffff7b97d57 in mir::graphics::GLRenderer::render(std::function<void (std::shared_ptr<void> const&)>, mir::graphics::Renderable&) (this=0x91fd10,
    save_resource=..., renderable=...)
    at /home/dan/bzr/mir/toy/src/graphics/gl_renderer.cpp:270
#5 0x00007ffff7b828ca in mir::compositor::RenderingOperator::operator() (
    this=0x7fffffffe260, renderable=...)
    at /home/dan/bzr/mir/toy/src/compositor/rendering_operator.cpp:32
#6 0x00007ffff7b9a68b in mir::surfaces::SurfaceStack::for_each_if (
    this=0x910be0, filter=..., renderable_operator=...)
    at /home/dan/bzr/mir/toy/src/surfaces/surface_stack.cpp:49
#7 0x00007ffff7b7cecc in operator() (buffer=..., this=0xa67cf0)
    at /home/dan/bzr/mir/toy/src/compositor/compositor.cpp:72
#8 std::_Function_handler<void(mir::graphics::DisplayBuffer&), mir::compositor::Compositor::render(mir::graphics::Display*)::<lambda(mir::graphics::DisplayBuffer&)> >::_M_invoke(const std::_Any_data &, mir::graphics::DisplayBuffer &) (
    __functor=..., __args#0=...) at /usr/include/c++/4.6/functional:1778
#9 0x00007ffff7ba26ec in operator() (__args#0=..., this=0x7fffffffe320)
    at /usr/include/c++/4.6/functional:2161
#10 mir::graphics::gbm::GBMDisplay::for_each_display_buffer(std::function<void (mir::graphics::DisplayBuffer&)> const&) (this=<optimised out>, f=...)
    at /home/dan/bzr/mir/toy/src/graphics/gbm/gbm_display.cpp:63
#11 0x00007ffff7b7cca2 in mir::compositor::Compositor::render (this=0xa69010,
    display=0x61e050) at /home/dan/bzr/mir/toy/src/compositor/compositor.cpp:75
#12 0x00007ffff7b6e66d in mir::DisplayServer::start (this=0x7fffffffe530)
    at /home/dan/bzr/mir/toy/src/display_server.cpp:103
#13 0x0000000000406954 in run_mir (socket_file=...)
    at /home/dan/bzr/mir/toy/src/main.cpp:63
#14 main (argc=1, argv=0x7fffffffe638) at /home/dan/bzr/mir/toy/src/main.cpp:96

Related branches

Daniel van Vugt (vanvugt) wrote :

Is it right that the server is rendering anything on client eglInitialize?

information type: Proprietary → Public
Kevin DuBois (kdub) wrote :

i saw a similar crash in android on the nexus4. hard to say if its related or not, maybe something is going on with the egl state?

Changed in mir:
status: New → Triaged
Robert Ancell (robert-ancell) wrote :

Has anyone seen this recently?

Daniel van Vugt (vanvugt) wrote :

I'll have to intentionally make the same mistake and see what happens...

Daniel van Vugt (vanvugt) wrote :

Confirmed, I can still reproduce this server crash with the latest lp:mir (r766).

See attached for a simple patch that will make the server blow up when an offending client runs.

Changed in mir:
milestone: none → 0.0.4
Changed in mir:
milestone: 0.0.4 → 0.0.5
Changed in mir:
milestone: 0.0.5 → 0.0.6
kevin gunn (kgunn72) on 2013-06-28
Changed in mir:
assignee: nobody → Eleni Maria Stea (hikiko)
Changed in mir:
milestone: 0.0.6 → 0.0.7
Changed in mir:
milestone: 0.0.7 → 0.0.8
Changed in mir:
milestone: 0.0.8 → 0.0.9
Changed in mir:
assignee: Eleni Maria Stea (hikiko) → Alexandros Frantzis (afrantzis)
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.0.9

Changed in mir:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mir - 0.0.8+13.10.20130808.2-0ubuntu1

mir (0.0.8+13.10.20130808.2-0ubuntu1) saucy; urgency=low

  [ Alexandros Frantzis ]
  * gbm: Don't try to allocate buffers with unsupported formats. (LP:

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 946
 -- Ubuntu daily release <email address hidden> Thu, 08 Aug 2013 15:18:56 +0000

Changed in mir (Ubuntu):
status: New → Fix Released
Changed in mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments