Potential NPE: missing non-null contract for Context in BaseFilterRender.initGl

Abierto
#2,207 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android, java, kotlin
Área
mobile-dev

Línea de trabajo

Read the cited CropFilterRender.kt, BaseFilterRender.java, and GlUtil.java code, then trace the BaseFilterRender.initGl call sites to determine whether null can reach the filter. Confirm the intended Context contract and, if needed, add a regression test for the initialization path; done means the contract is explicit and the behavior is covered.

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

Descripción

Describe the bug

During a source-level review, I found a potential Kotlin–Java nullability issue in CropFilterRender.

CropFilterRender.initGlFilter declares its parameter as nullable (Context?) and passes it directly to the Java method GlUtil.getStringFromRaw(Context context). That Java method immediately calls context.getResources() without checking for null.

Relevant code:

CropFilterRender.kt#L65-L67
BaseFilterRender.java#L46-L66
GlUtil.java#L100-L104

If a null value reaches this call path, context.getResources() can throw a NullPointerException.

I have not reproduced this exception in an Android instrumentation test yet. The normal rendering path appears to initialize MainRender with a non-null Context, so I would appreciate confirmation of the intended nullability contract.

To Reproduce

This report was prepared against RootEncoder commit ebb9b4b0cc5c54d58efbd18a760ca5b7e50d3fc7.

  1. Inspect CropFilterRender.initGlFilter(context: Context?).
  2. Observe that the nullable value is passed to GlUtil.getStringFromRaw.
  3. Observe that GlUtil.getStringFromRaw calls context.getResources() without a null check.
  4. Please confirm whether Context is guaranteed to be non-null whenever BaseFilterRender.initGl is called.

No direct initGlFilter(null) call was found in the repository. However, BaseFilterRender.initGl(...) is public, its Java Context parameter has no @NonNull annotation, and the nullability contract is not explicit.

Expected behavior

The nullability contract should be explicit:

If Context must always be non-null, the Java parameters should be annotated as non-null and the Kotlin override should use Context instead of Context?.
If null is a valid input, the code should handle it before calling GlUtil.getStringFromRaw.

Screenshots

Not applicable. This is a source-level nullability finding.

Smartphone (please complete the following information)

Library version: 2.8.1
Source commit: ebb9b4b0cc5c54d58efbd18a760ca5b7e50d3fc7
Device: Not reproduced on a device yet
OS: Not reproduced on a device yet
Media server: Not applicable
Class used: CropFilterRender / BaseFilterRender

Additional context

The normal internal rendering path appears to provide a non-null Context, but the public initialization contract does not make this requirement explicit.

A possible fix is to:

Add @NonNull to the Java filter initialization parameters.
Change CropFilterRender.initGlFilter to accept Context.
Store the MainRender context as a non-null initialized value.
Add a regression test covering the filter initialization path.

Could you please clarify whether this should be considered:

  1. a confirmed bug,
  2. an intentional non-null contract,
  3. a false positive, or
  4. a case that requires a specific Android/GL lifecycle to reproduce?
Lenguaje dominante
Kotlin
Estrellas
3k
Forks
946
Merge medio
2 d 4 h
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 pedroSG94/RootEncoder

Todos los issues de pedroSG94/RootEncoder

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.