[Bug] RowFormatReaderFactory leaks the input stream when reading the footer fails

Abierto Apto para principiantes
#9,006 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java

Línea de trabajo

Comienza en RowFormatReaderFactory.createReader y sigue quién es responsable del stream después de abrirlo, especialmente en las rutas de análisis del footer y del block-index. Usa el escenario de cola truncada o footer corrupto descrito en el issue; se considera completado cuando los fallos cierran el input stream antes de volver a lanzarse, incluidos los errores de seek, read, análisis del footer y análisis del block-index.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Search before asking
  • I searched in the issues and found nothing similar.
Paimon version

master, 142f8239b

Compute Engine

Engine independent.

Minimal reproduce step

Found by code inspection rather than from a failing job. Read a row format file whose tail is truncated, or whose footer is corrupt, so that footer or block index parsing throws.

What doesn't meet your expectations?

RowFormatReaderFactory.createReader opens the stream first and only transfers ownership to RowFormatReader on the last line:

SeekableInputStream in = fileIO.newInputStream(path);

int tailSize = (int) Math.min(TAIL_PREFETCH_SIZE, fileSize);
long tailOffset = fileSize - tailSize;
in.seek(tailOffset);
byte[] tailBuf = new byte[tailSize];
IOUtils.readFully(in, tailBuf);

RowFileFooter footer = RowFileFooter.readFrom(tailBuf, tailSize - RowFileFooter.FOOTER_SIZE);

RowBlockIndex blockIndex;
...
    blockIndex = RowBlockIndex.readFrom(in, footer.indexOffset, footer.indexLength);

return new RowFormatReader(in, path, footer, blockIndex, rowType, projection, context.selection());

There is no try / catch anywhere in the method, so a throw from in.seek, IOUtils.readFully, RowFileFooter.readFrom or RowBlockIndex.readFrom leaves in open with no owner. Scanning a set of files where several are corrupt leaks one stream per file.

Anything else?

Same interaction as the sibling report on CachingSeekableInputStream: with the lifetime tracking added in #8962, a stream that is never closed holds its lease forever, so that entry's FileIO is never released. That matches today's behaviour rather than regressing it, but it does keep the fix from reaching the affected entries.

Fix shape: close in before rethrowing.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Lenguaje dominante
Java
Estrellas
3.4k
Forks
1.4k
Merge medio
1 d 14 h
PR fusionados (30 d)
468

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/paimon

Todos los issues de apache/paimon

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.