xserver-multidpi/test/bigreq/meson.build

xcb_dep = dependency('xcb', required: false)
xcb_xinput_dep = dependency('xcb-xinput', required: false)

if get_option('xvfb')
    if xcb_dep.found() and xcb_xinput_dep.found()
        requestlength = executable('request-length', 'request-length.c',
                                   dependencies: [xcb_dep, xcb_xinput_dep])
        test('request-length', simple_xinit, args: [requestlength, '--', xvfb_server])
    endif
endif
test: Add a test for the overflow bug in bigreqs. The failing struct comes from the python test written by Michal Srb <msrb@suse.com>. v2: Use a drawable (root window) and gc, so that PolyLines hopefully actually tries processing things. However, the request seems to process successfully so the poll() just stalls out. However, this does let us distinguish between detecting the bigrequests error and not, at least. v3: Clean up the description of what we expect the poll() call to do. v4: Use XI2 instead of PolyLine to trigger a predictable error. We know the server replies with BadValue for a zero num_masks argument. So if we send a bigreq with a num_masks 0 and a length 0, we can just check whether we get killed (good) or a BadValue (bad). It doesn't test for specific memory overflows or crashes, but based on the assumption that we shouldn't look at any BigReq of size 0, this seems to be sufficient. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> 2017-10-10 02:14:32 +02:00			`xcb_dep = dependency('xcb', required: false)`
test: Fix build dependency for bigreq test libxcb-xinput isn't a thing in whichever Ubuntu it is that Travis is using. The test is already optional, make it more so. Signed-off-by: Adam Jackson <ajax@redhat.com> 2017-12-06 21:12:20 +01:00			`xcb_xinput_dep = dependency('xcb-xinput', required: false)`
test: Add a test for the overflow bug in bigreqs. The failing struct comes from the python test written by Michal Srb <msrb@suse.com>. v2: Use a drawable (root window) and gc, so that PolyLines hopefully actually tries processing things. However, the request seems to process successfully so the poll() just stalls out. However, this does let us distinguish between detecting the bigrequests error and not, at least. v3: Clean up the description of what we expect the poll() call to do. v4: Use XI2 instead of PolyLine to trigger a predictable error. We know the server replies with BadValue for a zero num_masks argument. So if we send a bigreq with a num_masks 0 and a length 0, we can just check whether we get killed (good) or a BadValue (bad). It doesn't test for specific memory overflows or crashes, but based on the assumption that we shouldn't look at any BigReq of size 0, this seems to be sufficient. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> 2017-10-10 02:14:32 +02:00
			`if get_option('xvfb')`
test: Fix build dependency for bigreq test libxcb-xinput isn't a thing in whichever Ubuntu it is that Travis is using. The test is already optional, make it more so. Signed-off-by: Adam Jackson <ajax@redhat.com> 2017-12-06 21:12:20 +01:00			`if xcb_dep.found() and xcb_xinput_dep.found()`
			`requestlength = executable('request-length', 'request-length.c',`
			`dependencies: [xcb_dep, xcb_xinput_dep])`
test: Add a test for the overflow bug in bigreqs. The failing struct comes from the python test written by Michal Srb <msrb@suse.com>. v2: Use a drawable (root window) and gc, so that PolyLines hopefully actually tries processing things. However, the request seems to process successfully so the poll() just stalls out. However, this does let us distinguish between detecting the bigrequests error and not, at least. v3: Clean up the description of what we expect the poll() call to do. v4: Use XI2 instead of PolyLine to trigger a predictable error. We know the server replies with BadValue for a zero num_masks argument. So if we send a bigreq with a num_masks 0 and a length 0, we can just check whether we get killed (good) or a BadValue (bad). It doesn't test for specific memory overflows or crashes, but based on the assumption that we shouldn't look at any BigReq of size 0, this seems to be sufficient. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> 2017-10-10 02:14:32 +02:00			`test('request-length', simple_xinit, args: [requestlength, '--', xvfb_server])`
			`endif`
			`endif`