Bug 99464 - openmw - Segfault with the nouveau ddx + DRI3
Summary: openmw - Segfault with the nouveau ddx + DRI3
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-19 23:45 UTC by orbea
Modified: 2019-09-18 20:44 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Apitrace. (55.54 KB, application/octet-stream)
2017-01-19 23:45 UTC, orbea
Details

Description orbea 2017-01-19 23:45:53 UTC
Created attachment 129055 [details]
Apitrace.

When starting openmw which is the free engine re-implementation of the game morrowind it will segfault. This may be a mesa core bug, but it will only happen with the nouveau DDX + DRI3. It will not crash with modesetting + DRI3, DRI2 or the llvmpipe.

Here is a backtrace.
http://pastebin.com/HMdv4iWb

Apitrace log.
http://pastebin.com/FzZVyGqW

Here is a workaround as reported to the the mesa mailing list by Tobias Klausmann. It successfully hides the crash, but potentially breaking the hardware cursor used by openmw which works correctly with DRI2, modesetting or the llvmpipe. It also was not intended as a real fix.

"OpenMW tries to upload a new surface (mouse pointer) which fails in the now
guarded update_framebuffer_size() as the surface is NULL.

This is not inteded as a real "fix", as it would just hide the immediate crash.

So if somebody could take a look at this...

Reported-by: <ovariegata@yahoo.com>
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
---
src/mesa/state_tracker/st_atom_framebuffer.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c b/src/mesa/state_tracker/st_atom_framebuffer.c
index ea41d9d..3ee4ea5 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -177,8 +177,10 @@ update_framebuffer_state( struct st_context *st )
          /* rendering to a GL texture, may have to update surface */
          st_update_renderbuffer_surface(st, strb);
      }
-      pipe_surface_reference(&framebuffer->zsbuf, strb->surface);
-      update_framebuffer_size(framebuffer, strb->surface);
+      if (strb->surface) {
+        pipe_surface_reference(&framebuffer->zsbuf, strb->surface);
+        update_framebuffer_size(framebuffer, strb->surface);
+      }
    }
    else {
      strb = st_renderbuffer(fb->Attachment[BUFFER_STENCIL].Renderbuffer);
-- 
2.9.2"
Comment 1 orbea 2017-01-20 01:43:04 UTC
I asked a friend who also uses openmw, he has never experienced any crashes with xf86_video_ati + DRI3.
Comment 2 Greg V 2018-03-06 18:58:47 UTC
I'm currently also experiencing a crash with OpenMW in update_framebuffer_size (surface is NULL).

But with RadeonSI on Wayland! (SDL_VIDEODRIVER=wayland)

Radeon RX 480, FreeBSD 12-CURRENT + drm-next-kmod 4.11, Mesa 18.1.0-devel (git master with my BSD fixes).

Same game works fine on X11. Under Weston, this crash. It *used to* work fine on Wayland, but broke recently.
Comment 3 Greg V 2018-03-06 19:45:20 UTC
(In reply to Greg V from comment #2)

UPDATE! The issue was in our DRM port, specifically with ioctl authentication/permissions.

If nouveau still has this problem, try looking into that…
Comment 4 Tobias Klausmann 2018-09-27 20:43:55 UTC
The mentioned workaround in the original description got adapted and committed recently:

c3486cd8c9092cbe33dfc77b906e2475b1e32c8d st/mesa: do not call update_framebuffer_size with NULL pointer

This should fix at least the SEGV. Maybe it can be reported if the invisible mouse pointer still exists in newer versions of mesa!
Comment 5 GitLab Migration User 2019-09-18 20:44:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1125.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.