Mir

mir server crashes with SIGFPE in glEGLImageTargetTexture2DOES

Bug #1124948 reported by Daniel van Vugt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
High
Alexandros Frantzis
mir (Ubuntu)
Fix Released
Undecided
Unassigned

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

information type: Proprietary → Public
Revision history for this message
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
Revision history for this message
Robert Ancell (robert-ancell) wrote :

Has anyone seen this recently?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
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)
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)
Revision history for this message
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
Revision history for this message
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:
    #1124948)

  [ 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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.