<div dir="ltr"><div>Thanks for the announcement, Even! I wonder if we should track such issues in a list? Or maybe give them a unique GitHub label?</div><div><br></div><div>We don't plan to release a 3.6.5, correct?<br></div><div><br></div><div>I'm going to make a Rasterio post release that patches 3.6.4 by tomorrow: <a href="https://github.com/rasterio/rasterio/issues/2943">https://github.com/rasterio/rasterio/issues/2943</a>.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023 at 9:26 AM Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <p><br>
    </p>
    <div>Le 16/10/2023 à 17:14, Kurt Schwehr a
      écrit :<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">Thanks for the heads up!
        <div dir="auto"><br>
        </div>
        <div dir="auto">Can you share that SHAs of the fix and cause?</div>
      </div>
    </blockquote>
    <p>master: d083af1ec9c38e79bfb0532885570de6e5b8a410</p>
    <p>3.7 branch (should apply to 3.6 as well):
      b5858ed5bc5004c97f7cd6000674015bdc70b33b</p>
    <p>cause: a worker thread of the multithreaded decoding could, in a
      situation where the block cache is full, cause a "dirty" (ie
      modified but not yet serialized to disk) block to be written,
      resulting in either a deadlock between the lock of the
      multithreaded decoder and the lock of the job queue mechanism, or
      other decoding threads could see their file handle being seek() by
      another thread.  In short: multithreading is hard.<br>
    </p>
    <blockquote type="cite"><br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023, 7:44 AM
          Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
          <br>
          For GDAL 3.6.0 to 3.7.2, use of multi-threaded GTiff <br>
          compression+decompression, in particular within the same file,
          as for <br>
          example in a "gdalwarp -co COMPRESS=... -co NUM_THREADS=..."
          workflow <br>
          can lead to deadlocks (process stalled forever) and/or data
          corruption <br>
          (sometimes without errors at generation). Cf <br>
          <a href="https://github.com/OSGeo/gdal/issues/8470" rel="noreferrer noreferrer" target="_blank">https://github.com/OSGeo/gdal/issues/8470</a>
          for a reproducer. The fix is <br>
          in <a href="https://github.com/OSGeo/gdal/pull/8561" rel="noreferrer noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/8561</a><br>
          <br>
          The issue is particularly visible on Windows, or more
          generally any <br>
          operating system (or file system where the output file is
          located) which <br>
          has no VSIVirtualHandle::PRead() implementation, but it can
          also be <br>
          occasionally reproduced on Linux (at least as a deadlock).<br>
          <br>
          Even<br>
          <br>
</blockquote></div></blockquote></div></blockquote></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Sean Gillies</div></div>