diff options
author | nea <nea@nea.moe> | 2023-02-16 23:12:04 +0100 |
---|---|---|
committer | nea <nea@nea.moe> | 2023-02-16 23:38:54 +0100 |
commit | d7f875a0dc1f46402abc3462c2fbe357876773bb (patch) | |
tree | 39e9f6f4e5075ae1a70af6f20f04e8d658eff065 /COPYING | |
parent | 1d75ac44c20fafd9f834dc7c01066a85a74f89e7 (diff) | |
download | NotEnoughUpdates-fix/apicache-nullpointer.tar.gz NotEnoughUpdates-fix/apicache-nullpointer.tar.bz2 NotEnoughUpdates-fix/apicache-nullpointer.zip |
ApiCache: Fix apparent NullPointerExceptionfix/apicache-nullpointer
`CacheResult` should in theory have either a `file != null` a `future !=
null` or be `disposed`. Apparently this invariant of `CacheResult` is
either being violated somewhere, or the `synchronized` blocks arent as
synchronized as id hoped they were. In fact, `dispose()` does not even
delete the file, so i can really only see this happening because the
first `synchronized` block that writes the file and the second
`synchronized` block that reads from the file hold the same lock.
I have no idea how this would happen, but hopefully this fixes it (since
the dispose didn't have a threading issue reported so far, i feel more
confident leaving the .deleteOnExit in there, but I'm also wrapping any
potential IOExceptions during access, because I am just so confused how
the internal state was broken.
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions