Bug - Fixed r15988 relay browser hangs and never recovers

AlbinoRhino

AlbinoRhino

Active member
So after playing almost all of my turns today with 15987 with no issues. I updated to r15988 and immediately started getting the attached debug logs.

They were accompanied in the cli with the following:

Unexpected error, debug log printed.
Script execution aborted (java.lang.StackOverflowError): (Universal_recovery.ash, line 212)

All three times referred to that particular line in UR. First time I've seen a debug in my folder for quite a while !
All were caused right after clicking on the ninja snowman link to adventure there.

Symptoms were that the relay browser entered a never-ending state of "connecting", which closing and reopening (the browser) wouldn't fix. The gui still seemed responsive though. It ran my rollover script afterwards with no complaining.
 

Attachments

  • DEBUG_20150626.txt
    165.1 KB · Views: 50
Veracity

Veracity

Developer
Staff member
Code: 
	at net.sourceforge.kolmafia.textui.command.BurnMpCommand.run(BurnMpCommand.java:75)
	at net.sourceforge.kolmafia.KoLmafiaCLI.doExecuteCommand(KoLmafiaCLI.java:596)
	at net.sourceforge.kolmafia.KoLmafiaCLI.executeCommand(KoLmafiaCLI.java:549)
	at net.sourceforge.kolmafia.KoLmafiaCLI.executeLine(KoLmafiaCLI.java:450)
	at net.sourceforge.kolmafia.KoLmafiaCLI.executeLine(KoLmafiaCLI.java:318)
	at net.sourceforge.kolmafia.moods.ManaBurnManager.burnExtraMana(ManaBurnManager.java:86)
	at net.sourceforge.kolmafia.textui.command.BurnMpCommand.run(BurnMpCommand.java:75)
and on and on and on.
 
AlbinoRhino

AlbinoRhino

Active member
if (my_soulsauce() > 90)
{
cli_execute("burn *");
use_skill(18, $skill[Soul Food]);
}

This was in my after adventure script yesterday. Could that cause it ? It worked fine in 15987.
 
AlbinoRhino

AlbinoRhino

Active member
Prediction confirmed ! I replaced using "burn *" in my scripts with a custom ash function for burning and have had no further problems. However, lastChanceBurn is still set to "burn extra".
 
Veracity

Veracity

Developer
Staff member
Yeah. I can't see why that would ever work. Here's the relevant code in ManaburnManager.getNextBurnCast:

Code: 
		if ( chosen == null )
		{
			...
			// Last chance: let the user specify something to do with this
			// MP that we can't find any other use for.
			String cmd = Preferences.getString( "lastChanceBurn" );
			if ( cmd.length() == 0 )
			{
				return null;
			}
			
			return StringUtilities.globalStringReplace( cmd, "#",
				String.valueOf( allowedMP ) );
		}
That method is called by the "burn" command to decide what to cast next. If it can't find anything appropriate, the user can provide a command to make that decision. If there is a # in the command, it is replaced with the amount of MP available.

The expectation is that it will be an ASH script which will do something sensible using that much MP.

Calling "burn <anything>" will end up right back in the same spot; if the initial "burn" command was unable to find anything sensible to cast, the recursive "burn" command will do no better, and will call your lastChanceBurn command again. Hence, the infinite recursion.

I could just say "don't do that". However, simply disallowing the command to start with "burn " would also prevent the recursion. Something like this:

Code: 
			if ( cmd.length() == 0 || cmd.startsWith( "burn " ) )
			{
				return null;
			}
I don't know enough about mana burning to understand if there is a "burn" command that would sensible to call in this case. Probably not; I think it will end up in this same block of code...
 
AlbinoRhino

AlbinoRhino

Active member
I must have set that some time ago; as I don't remember doing it. I am surprised I never got debug logs before !

Once again, you have made everything clear ! I really appreciate your explanations. Thank you. I will make sure to use some ash for mp burning !
 
You must log in or register to reply here.
Top