Bug - Fixed NPE in batch_close()

[xKiv]

for some reason, I recently (this week) started getting a NullPointerException in batch_close (namely, of batches in which something is autosold):

...
class java.lang.NullPointerException: null
java.lang.NullPointerException
        at net.sourceforge.kolmafia.textui.RuntimeLibrary.batch_close(RuntimeLibrary.java:1469)
        at sun.reflect.GeneratedMethodAccessor119.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at net.sourceforge.kolmafia.textui.parsetree.LibraryFunction.execute(LibraryFunction.java:126)
        at net.sourceforge.kolmafia.textui.parsetree.FunctionCall.execute(FunctionCall.java:166)
        at net.sourceforge.kolmafia.textui.parsetree.BasicScope.execute(BasicScope.java:451)
...

that's weird, since the code basically does (slightly paraphrased)

if ((batched = LibraryFunction.interpreter.batched) != null) {
  for each entry in batched: KoLmafiaCLI.DEFAULT_SHELL.executeCommand(entry.command, entry.parameters);
  LibraryFunction.interpreter.batched = null; // this is the NPE line
}

That *looks* (without debugging - I should have really done *thar*) like something is setting LibraryFunction.interpreter = null, and the only place I can find anything like that is at the end of LibraryFunction.execute().


note: the autosell actually goes through

 

[jasonharper]

Do you have something like a chatbotScript running, that could have been invoked while your batched autosells were being processed?

 

[Veracity]

Heh. So, rather than simply setting and nulling the global interpreter variable, perhaps we should save and restore the previous value.

 

[jasonharper]

That wouldn't entirely fix the problem if the offending ASH invocation is coming from a different thread. If it's just a recursive invocation that's wiping out the interpreter variable, batch_close() could save it in a local variable.

 

[slyz]

I have had the same problem debug log with my logout script, which ends with

print("Transfering to store...", "green");
int num;
batch_open();
foreach it in $items[BRICKO Brick, gong, tiny bottle of absinthe, Game Grid token, agua de vida, prismatic wad, gatorskin umbrella, Pack of Alice's Army Cards]
   if ( item_amount(it) > 0 ) { num += 1; print( num ); put_shop( 0, 0, item_amount( it ), it ); }
batch_close();

This happens when I call my logout script via the gCLI:

[color=green]Transfering to store...[/color]
1
2
3
4
Transferring items to store...
Items offered up for sale.
Unexpected error, debug log printed.
[color=red]Script execution aborted[/color]

EDIT: no chatbot script or anything running. If no item is send to the mall, batch_close() does not cause an NPE.

 

[jasonharper]

Do any of you who are experiencing this problem have any relay overrides active, in particular on the charpane?

 

[AlbinoRhino]

Do any of you who are experiencing this problem have any relay overrides active, in particular on the charpane?

I am having this problem when Bale's OCD script autosells or puts items in the display case and yes I have a charpane override.

edit: I also have topmenu, woods, campground & desc_item overrides, if those mean anything.

 

[slyz]

I do, I use Lost's charpane.ash.

 

[xKiv]

I also have relay override on charpane (and topmenu), and no (other?) background scripts should be running at the time.
(i.e. I am not clicking anything; but I have open chat, in both relay browser and mafia's interface)

 

[lostcalpolydude]

I do, I use Lost's charpane.ash.

I've actually started using that again. I've refactored it a bit, but it's functionally identical for now.

I've noticed that whenever I make code changes, if I cause a syntax error in charpane.ash (putting mafia in an error state), I have to do something to return mafia to a normal state (I've been using the refresh button) before the override will be processed again.

 

[jasonharper]

r9671 probably fixes the problem in relation to having a charpane relay override. There are still some narrow time windows where an incoming chatbotScript invocation could screw you over, but fixing that would be a rather more major undertaking.

 

[slyz]

No more debug log with r9671. I'm marking this as fixed.