If a failure occurs early in src/mesa/drivers/dri/common/dri_util.c:__driUtilCreateScreen(), for example if drmOpen() fails, then in the cleanup path pSAREA, framebuffer.base, framebuffer.dev_priv, are accessed uninitialized, likely resulting in a segfault. Fix looks as simple as initializing them to NULL or MAP_FAILED as appropriate; should be 3 lines.
It appears that CallCreateNewScreen (src/glx/x11/glxext.c) has the same problem. That code does initialize framebuffer.dev_priv, but not the other two fields. I replaced the drmOpen call in that file with 'fd = -EPERM', and did *NOT* get a crash. I don't understand why GCC doesn't complain about variables being used without being initialized. Odd.
Same as bug 1501 ... multiple trees make it unclear to me whether it should be dup'ed or not.
driUtilCreateScreen no longer exists. Made sure that all the values used in the clean-up code of CallCreateNewScreen were initialized at some point. It is still unclear to me as to why GCC did not complain about the values being used uninitialized.. I suspect the problem may have been due to the depth of if-statement nesting.
Mass version move, cvs -> git
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.