On 9 February 2015 at 15:09, Jon TURNEY <jon.tur...@dronecode.org.uk> wrote: > On 09/02/2015 14:03, Daniel Martin wrote: >> >> On 9 February 2015 at 14:45, Jon TURNEY <jon.tur...@dronecode.org.uk> >> wrote: >>> >>> ephyr_glamor_connect() returns NULL if we failed, but applying >>> xcb_connection_has_error() to NULL is not permitted. >>> >>> Signed-off-by: Jon TURNEY <jon.tur...@dronecode.org.uk> >>> --- >>> hw/kdrive/ephyr/hostx.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c >>> index f64861b..15edce8 100644 >>> --- a/hw/kdrive/ephyr/hostx.c >>> +++ b/hw/kdrive/ephyr/hostx.c >>> @@ -443,7 +443,7 @@ hostx_init(void) >>> else >>> #endif >>> HostX.conn = xcb_connect(NULL, &HostX.screen); >>> - if (xcb_connection_has_error(HostX.conn)) { >>> + if (!HostX.conn || xcb_connection_has_error(HostX.conn)) { >> >> >> No need to change the check, as xcb_connect() ... >> "Always returns a non-NULL pointer to a xcb_connection_t, even on >> failure." >> http://cgit.freedesktop.org/xcb/libxcb/tree/src/xcb.h#n549 > > > I'm afraid you need to look at a little more context than is in the diff. > > If glamor is enabled, HostX.conn contains the result of > ephyr_glamor_connect(), not xcb_connect(), which can be NULL. >
Ah, I see. Another way to fix it would have been to return such an error from ephyr_glamor_connect() like xcb_connect() would do. But, that be more complicated then this simple check ... Reviewed-by: Daniel Martin <consume.no...@gmail.com> _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel