[Mesa-dev] [Bug 107098] Segfault after munmap(kms_sw_dt->ro_mapped)
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Jul 3 08:13:26 UTC 2018
https://bugs.freedesktop.org/show_bug.cgi?id=107098
Bug ID: 107098
Summary: Segfault after munmap(kms_sw_dt->ro_mapped)
Product: Mesa
Version: 18.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Other
Assignee: mesa-dev at lists.freedesktop.org
Reporter: jpalus at fastmail.com
QA Contact: mesa-dev at lists.freedesktop.org
Recently I've done a big update in my Linux guest running under VirtualBox
(Mesa 18.1.2, xorg server 1.20, kernel 4.17) and found X server segfaulting.
Linux guest inside VirtualBox runs modesetting driver, backed by vboxvideo KMS
driver and from what I understand modesetting is trying to use gallium
acceleration through swrast (I'm not really fluent in graphic stack so please
excuse me if I'm using some terms incorrectly).
After few debugging sessions, in which places of segfault were different
depending on glibc version, it appears the problem is caused by line in
kms_dri_sw_winsys.c:
munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
Judging by code kms_sw_dt->mapped / kms_sw_dt->ro_mapped are expected to be not
NULL if they point to mmaped memory or NULL otherwise. Now the problem is that
in my case kms_sw_dt->ro_mapped is NULL, so probably munmap() call is expected
to be a no-op, however it does not seem to be the case. On the contrary it
screws entire process big time, as if it unmapped process memory? All pointers
are no longer valid and it seems first dereference afterwards throws segfault.
With newer glibc it even occurs within symbol lookup mechanism.
Two things worked for me as a workaround:
* setting AccelMethod=none
* adding condition on above munmap() to call it only if ro_mapped is not NULL
Now I can't really tell if it's ok whether kms_sw_dt->ro_mapped is NULL, or how
should munmap() behave when called with NULL. Perhaps there should be a flag
whether mmap() was performed instead of relying on pointer value.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180703/06bb6667/attachment-0001.html>
More information about the mesa-dev
mailing list