Comment # 3 on bug 109679 from
Agree this looks like an issue in IGT or possibly in the chameleond daemon. At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It does look feasible that if
we were to pass a 0 for width and height, we could potentially get a
div-by-zero exception when chameleond prepares the video output:
CaptureVideo ->
_PrepareCapturingVideo/_captured_params['max_frame_limit']/flow_manager.GetMaxFrameLimit
-> input_flow.GetMaxFrameLimit -> frame_manager.GetMaxFrameLimit ->
field_manager.GetMaxFieldLimit -> VideoDumper.GetMaxFieldLimit:
  def GetMaxFieldLimit(cls, width, height):                          
    """Returns of the maximal number of fields which can be dumped.""" 
    BYTE_PER_PIXEL = 3                                                 
    PAGE_SIZE = 4096                                                         
    field_size = width * height * BYTE_PER_PIXEL   
    field_size = ((field_size - 1) / PAGE_SIZE + 1) * PAGE_SIZE
    return cls._DUMP_BUFFER_SIZE / field_size

That said, running this myself locally does not result in the failure of this
sighting, and from kms_chamelium.c, during the CRC check, we are passing 0 for
width and height:
  chamelium_capture(data->chamelium, port, 0, 0, 0, 0, count);

So I'd expect this to fail all the time if the issue were in the Python call I
indicated above.

And I'd also expect for CI to have seen this already if that were the case,
given this code has been present for some time.


You are receiving this mail because: