On 2016-11-15 16:21:27, Matt Turner wrote: > Jordan, > > In > > commit 0041169cacb300a882b4dc38cd341f98bf2a7c38 > Author: Jordan Justen <[email protected]> > Date: Fri Oct 21 12:56:49 2016 +0100 >
This date is not correct. In my branch it was: Date: Mon Jun 30 00:50:56 2014 +0000 I wonder how the date got reset... Nevertheless, the newest version I have in my old branch also seems to have the bugs you describe. Anyway, Lionel pushed this patch and some others for aux-hiz support. It looks like he also has a "i965: miptree: prevent potential NULL pointer access" follow up patch to address this issue. Do we have a bugzilla for it? -Jordan > i965: Wrap MCS miptree in intel_miptree_aux_buffer > > you changed intel_miptree_alloc_mcs() to return mt->mcs_buf != NULL. > > mt->mcs_buf is assigned a few lines higher the result of > intel_mcs_miptree_buf_create(), which may return NULL. Then, inside > intel_miptree_init_mcs(), mt->mcs_buf is unconditionally dereferenced > multiple times (and even free()d without setting the pointer to NULL > afterwards). > > This seems very broken. > > ________________________________________________________________________________________________________ > *** CID 1394290: Null pointer dereferences (REVERSE_INULL) > /src/mesa/drivers/dri/i965/intel_mipmap_tree.c: 1610 in > intel_miptree_alloc_mcs() > 1604 mt->logical_width0, > 1605 mt->logical_height0, > 1606 > MIPTREE_LAYOUT_ACCELERATED_UPLOAD); > 1607 > 1608 intel_miptree_init_mcs(brw, mt, 0xFF); > 1609 > >>> CID 1394290: Null pointer dereferences (REVERSE_INULL) > >>> Null-checking "mt->mcs_buf" suggests that it may be null, but it has > >>> already been dereferenced on all paths leading to the check. > 1610 return mt->mcs_buf != NULL; > 1611 } > 1612 > 1613 > 1614 bool > 1615 intel_miptree_alloc_non_msrt_mcs(struct brw_context *brw, _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
