Bug - Fixed One char doesn't run after upgrade to KoLMafia-26897-M.jar

Ethelred

Member
Last night I upgreaded my kolmafia build from KoLmafia-26886-M.jar to KoLMafia-26897-M.jar and one of my chars wouldn't run. Five others ran just fine. I tried multiple times for the failed char, but always got and abort and a log file. Then I tried to run that char using the older build and it ran just fine. One of the log files is attached. Thanks for any help in diagnosing the problem. Please let me know if additional info is needed.

System info:
OS: MacOS Monterey 12.6.1
java: openjdk version "17.0.2" 2022-01-18
Mafia version: KoLMafia-26897-M.jar
 

Attachments

  • hs_err_pid5557.log
    117.5 KB · Views: 5

heeheehee

Developer
Staff member
As suggested, updating your version of Java may be a good start. It's atypical for a Java application to cause Java to segfault, as that's usually a problem with the JVM itself. If that doesn't fix the problem:

log said:
# Problematic frame:
# J 7228 c2 net.sourceforge.kolmafia.persistence.SkillDatabase.getMPConsumptionById(I)J (504 bytes) @ 0x000000012ff686d0 [0x000000012ff68400+0x00000000000002d0]

What class is the character? Does it have any librams?

The -M suffix on your version suggests that you're running a custom build. What local modifications do you have?

It looks like it's running into problems in `log snapshot`, in particular when trying to print out your list of skills.

Do you happen to have... a Juju Mojo Mask equipped on that specific character? (Exercise left to reader to figure out why I think that might be the case)
Buried in the log, in the register to memory mapping:
- 'key' 'Ljava/lang/Object;' @16 a 'java/lang/Integer'{0x0000000401109700} = 7104 (802212e0)
- 'value' 'Ljava/lang/Object;' @20 a 'java/lang/Integer'{0x0000000400553fa8} = 5 (800aa7f5)

7104 is Wrath of the Volcano God; 5 is the skill "type", namely, combat.
 

Veracity

Developer
Staff member
Ha ha.

Code:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000013786a770, pid=32977, tid=158723
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.3+7 (17.0.3+7) (build 17.0.3+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (17.0.3+7, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# J 19391 c2 net.sourceforge.kolmafia.persistence.SkillDatabase.getMPConsumptionById(I)J (504 bytes) @ 0x000000013786a770 [0x000000013786a4c0+0x00000000000002b0]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/brianna/root/src/kolmafia/hs_err_pid32977.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues

The character is a Seal Clubber who has no IOTMs and has completed a Journeyman run, so has lots and lots of non-SC skills.
He had just started a fight.

I just updated to 17.0.5. Enough of this.
 

fewyn

Administrator
Staff member
Yeah I had this same problem the other day upgrading to 17.0.5 fixed it. Didn't matter which multi I did it on though.
 

fewyn

Administrator
Staff member
and as soon as I said that i'm now experiencing it even with 17.0.5
 

Veracity

Developer
Staff member
I am getting it with all characters on 17.0.5.
Not always at login. I can often login and run all my turns.
Other times, I have to restart my run multiple times.
 

Veracity

Developer
Staff member
I am experimenting. This is clearly a Java runtime bug - user programs are not supposed to be able to make the JVM crash - but I'm trying to see if I can narrow down where the crash happened.

Code:
# Problematic frame:

# J 5938 c2 net.sourceforge.kolmafia.persistence.SkillDatabase.getMPConsumptionById(I)J (500 bytes) @ 0x00000001198a81b0 [0x00000001198a7f00+0x00000000000002b0]

So I stuck this line at the top of SkillDatabase.getMPConsumptionById

Code:
    if (1 == 1) return 0;

(which fools the compiler into not complaining that the rest of the method is "unreachable".

No crashes after repeated starts and lengthy script execution.

I'll try moving that line incrementally down the method, and if the crashes start again, the preceding line is suspicious.

Edit: This appears to be the culprit:

Code:
    boolean isCombat =
        (SkillDatabase.isCombat(skillId) && !SkillDatabase.isNonCombat(skillId))
            || (SkillDatabase.isCombat(skillId) && FightRequest.getCurrentRound() > 0);

That's inefficient, anyway. I will rewrite it and see if it fixes the crash.

Edit 2: With a lot of fiddling, I no longer get a crash with this:

Code:
    // The following funkiness seems to work around a compiler bug in 17.0.3
    // and 17.0.5 that makes the JVM to crash.
    boolean isNonCombat = SkillDatabase.isNonCombat(skillId);
    boolean inFight = (FightRequest.getCurrentRound() > 0);
    boolean isCombat = SkillDatabase.isCombat(skillId) && (!isNonCombat || inFight);

I'll make a PR.

I will also delete my 38 crash logs.
 

Ethelred

Member
Thanks for all the suggestions. I updated my java runtime to openjdk version "17.0.5" 2022-10-18 but still couldn't login the problem character. In the meantime, 2 more chars also failed. So I upgraded mafia again to KoLmafia-26902M.jar. With that version, I can at least log in the 3 problem characters. Can't test much until I have some turns after rollover, but a few checker scripts seem to work ok. Thanks for the quick fix.
 

fronobulax

Developer
Staff member
Thanks for all the suggestions. I updated my java runtime to openjdk version "17.0.5" 2022-10-18 but still couldn't login the problem character. In the meantime, 2 more chars also failed. So I upgraded mafia again to KoLmafia-26902M.jar. With that version, I can at least log in the 3 problem characters. Can't test much until I have some turns after rollover, but a few checker scripts seem to work ok. Thanks for the quick fix.
On Windows, if you open a command window and the run mafia (java -jar <mafia.jar>) you sometimes get useful output that is NOT written to the gCLI or session log. That might be something to try to get more information.
 
Top