-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'queuePendingMember' causes NPE #68
Labels
bug
Something isn't working
Comments
It's not a particularly urgent issue, since the use case this was designed to cover wasn't supported previously either and would've crashed anyway. |
Yeah I thought as much haha, just wanted to mentioned it. I ran into it because I was trying to hook up mappings wrongly, which "triggered" this feature, after I did it right it worked perfectly. |
NebelNidas
added a commit
that referenced
this issue
Sep 9, 2024
- Fix #68 - Make the pending member queue fully functional (both for missing source names and descriptors) - Extend pending queue to cover classes as well - Enable incoming data to have inverted namespaces - Delay descriptor computation until `visitEnd`, so all potentially referenced classes are available - Fix `MemoryMappingTree#reset` to actually reset all its internal state related to the current visitation pass - Add protection against external data modification while visitation pass is in progress - Clarify API contracts regarding returned collections' mutability in Tree-API - Make Tree-API getters return only unmodifiable collections where possible - Fix mapping merging via tree-API not overwriting existing entries' data - Fully implement arg and var merging
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is this bit of code here, which constructs
FieldEntry
andMethodEntry
objects with the source name set tonull
:mapping-io/src/main/java/net/fabricmc/mappingio/tree/MemoryMappingTree.java
Lines 479 to 483 in a301899
I think this always causes a null pointer exception, because the parent constructor uses it to construct a key:
mapping-io/src/main/java/net/fabricmc/mappingio/tree/MemoryMappingTree.java
Line 1122 in a301899
And the constructor of the key in turn calls
.hashCode()
on the name without checking for null:mapping-io/src/main/java/net/fabricmc/mappingio/tree/MemoryMappingTree.java
Lines 1680 to 1684 in a301899
I suppose, since a key without the name being present probably makes little sense, it would make sense to lazily compute the key as soon as the entry is no longer pending?
Stack trace of the exception:
The text was updated successfully, but these errors were encountered: