Bug java.lang.NullPointerException during maximize

[ckb]

Script execution aborted (java.lang.NullPointerException)

This happened during a maximize. Re-running the script was successful, so I could not replicate it, though it has happened before. Posting debug log.
Sorry there is not more info, but this is all I know.

 

[Crowther]

I think I witnessed the same thing during a autoBasement managed basement dive. KoLmafia aborted during a maximize. Rerunning autoBasement should have run the same maximize function, but it did not abort until later. I was in a hurry and did not investigate more. I'm mentioning this because it might be a way to recreate this.

 

[xKiv]

So ... something in inventory is (briefly) null? Weird.

 

[Saklad5]

The debug log seems to indicate the issue lies with Sweet Synthesis. I think it’s an off-by-one error when sorting candies?

 

[Saklad5]

Line 409 of CandyDatabase.java seems a likely culprit:

public int compareTo( final Candy o )
{
    if ( o == null )
    {
        throw new NullPointerException();
    }


    return this.itemId - o.itemId;
}

 

[Veracity]

According to the Java spec for compareTo, an NPE exception is the correct response to a null argument. So, not sure why that method is the “culprit”. Passing in a null object is the direct error. Having a null object when none is expected would be the real error.

 

[Saklad5]

According to the Java spec for compareTo, an NPE exception is the correct response to a null argument. So, not sure why that method is the “culprit”. Passing in a null object is the direct error. Having a null object when none is expected would be the real error.

You’re right, that was a poor choice of words on my part. I meant that it is where the error is originating.

 

[xKiv]

You’re right, that was a poor choice of words on my part. I meant that it is where the error is originating.

That's where the error is *detected*. (the *exception* is originating there ..., but that's not that interesting).

 

[heeheehee]

Actually, a few frames up the stack trace is AdventureResult.getCount( inventory ), and inventory contains AdventureResults, so the Candy comparator shouldn't be relevant to this particular crash.

The weird thing about xKiv's comment #3 (which is where I arrived as well) about something in inventory being null is that SortedListModel.add(int, E) explicitly refuses to add null elements. It's possible that somewhere is calling LockableListModel.set(null). I couldn't find any errors when I skimmed SortedListModel's binary search implementation, but that's also a possible culprit.

(The only instance of inventory.set( index, result ) I could find is in AdventureResult.addResultToList(), but that looks to be adequately guarded against setting the value to null -- for one, indexOf would return -1 in that case, and we'd just call add().)

(tangent: could we rip out the SortedListModels in favor of something more standard, like ConcurrentHashMaps if we actually need locking? I'm inclined to trust that said implementations have been much more heavily vetted by way of much wider industry adoption.)

 

[Veracity]

Not sure what we'll be able to do about this, but bumping from Page 5.

 

[ckb]

FWIW, this has not happened to me any time recently.

 

[Veracity]

Yeah, I'm not expecting we can solve this, but I want to look at it a bit more, especially since heeheehee had some comments/suggestions.