Potential NPE: missing non-null contract for Context in BaseFilterRender.initGl
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- mobile-dev
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Inspect
CropFilterRender.initGlFilter(context: Context?). - Observe that the nullable value is passed to
GlUtil.getStringFromRaw. - Observe that
GlUtil.getStringFromRawcallscontext.getResources()without a null check. - Please confirm whether
Contextis guaranteed to be non-null wheneverBaseFilterRender.initGlis 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:
- a confirmed bug,
- an intentional non-null contract,
- a false positive, or
- a case that requires a specific Android/GL lifecycle to reproduce?
- Dominant language
- Kotlin
- Stars
- 3k
- Forks
- 946
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 9
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pedroSG94/RootEncoder
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
pedroSG94/RootEncoder#2213 ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
pedroSG94/RootEncoder#2203 ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
pedroSG94/RootEncoder#2192 · 2 comments ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
pedroSG94/RootEncoder#2177 · 44 comments ·
Maintainers usually reply within 2 days
-
Docs/Migration: 1.x → 2.x breaking API changes are not documented (package rename, ConnectChecker rename)May be free again @pedroSG94 claimed this 75 days ago, and no pull request is open. Openenhancement
pedroSG94/RootEncoder#2118 · 1 assignee ·
Maintainers usually reply within 2 days
All issues in pedroSG94/RootEncoder
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
callstack/react-native-brownfield#492 · 1 comment ·
Maintainers usually reply within 4 days
-
fix: retain the best partial noise-correction solutionPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
world-federation-of-advertisers/cross-media-measurement#4653 ·
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
kabirvashisht4-glitch/Vet#22 ·
-
documentation good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
djazairdev/wilayas#23 ·
Maintainers usually reply within 1 day