Bug - Fixed Missing Tab

A

awesomeperson

New member
I'm not entirely sure how to describe it, but the whole "main tab" of my kolmafia was missing when I logged in, with the landing tab defaulting to the graphical CLI. Attached images and debug log to illustrate. I'm not sure how to reproduce it because I'm not sure what's causing it. Logging out and logging in does nothing, except for a possibly-unrelated issue where logging in is impossible ("could not acquire file lock for "character name". Most likely, another instance of Kolmafia is logged in" is displayed) until I close OpenJDK Platform binary in my task manager. I first encountered the issue on Kolmafia-27701, but have obtained the same issue in Kolmafia-27704 (Most recent build).

"Could not acquire file lock":
1701514282573.png

Wonky screen:
1701514433686.png
 

Attachments

Last edited by a moderator:
Just found out that running the command "logout" and then logging in again seems to resolve the issue. I'm still not sure what happened or if this is just a temporary fix for something that's going to be a recurring problem, though.
 
Per the debug log:

java.lang.NullPointerException: Cannot invoke "net.sourceforge.kolmafia.persistence.DailyLimitDatabase$DailyLimit.hasUsesRemaining()" because the return value of "net.sourceforge.kolmafia.persistence.DailyLimitDatabase$DailyLimitType.getDailyLimit(int)" is null

The stack trace points to trying to load your currentMood. Can you share the value of that preference ("get currentMood" in the graphical CLI), as well as the corresponding snippet of your mood file (should be something like settings/awesomeperson_moods.txt)?
 
Current Mood:
1701523483455.png

Snippet of relevant mood from llonys_moods
1701523575156.png

If it's relevant, I changed my in-game username yesterday -- so this is a relatively new mood file (llonys_moods), and it's coexisting with the old one (awesome_person_moods) -- I'm not sure if I should be deleting all the files tagged with the old username?
 
Tangentially "could not acquire file lock for "character name" is the error message when there is another instance of KoLmafia running and "character name" is also logged in there. This is normally avoided by logging out of "other" instances of KoLmafia or shutting them down completely. The fact that you resolved the problem by killing an instance of the OpenJDK Platform binary via Task Manager is interesting because it suggests that KoLmafia is being left in a state where it is still running with a character logged in but there is no GUI displayed.

Changing in game name is not a well debugged process. If I wanted it to run smoothly I would make sure no instances of KoLmafia were running. I would delete all files that start with active_session in sessions/ I would rename the moods and prefs files in settings/ from <oldchar>_moods to <newchar>_moods etc. If the newchar file already exists then you will have to do some manual process to preserve any values in the old file that you want to retain in the new. You will probably want to change any custom combat script that KoL mafia knows about but that doesn't have to be a rename as long as mafia is using the file you expect.

It is possible that your missing tabs are the result of KoLmafia looking for a file that is supposed to be there, and is named with the character. When you in game renamed that changed the file name mafia was looking for but did not actually recreate it.
 
I wouldn't think the old username matters. As frono mentions, I would not be surprised if Mafia doesn't handle some aspect of username changes properly. But it sounds like this happened on a fresh login, so I doubt that's directly related.

The relevant daily limits in the mood seem to be for the Aug 7 (incredibly well lit) and Aug 13 (left/off-hander's day) skills. This agrees with the stack trace (UseSkillRequest.java:648 is a switch case for the Aug skills).

I don't suppose you have any lines in your session log about errors parsing daily limits? Something like "Daily Limit: Cast Acquire Rhinestones is bogus" or "Daily Limit: Cast Ancestral Recall has invalid max".

I don't see a relevant debug log entry, so I think we can rule out DailyLimitDatabase.reset() catching an exception in the middle of parsing.
 
I would guess if anything is wonky as a result of the name change, it's that preferences are somehow not being propagated correctly. But this case reads more like a fundamental issue with Mafia not loading its datafiles correctly.

The error is exactly what you'd expect if at least one of the Aug skills did not make it into DailyLimitType.CAST.dailyLimits, regardless of any settings the user might have. Those entries appear very early in dailylimits.txt, so if there's an error loading the file or parsing one of the earliest entries, that could explain it.
 
heeheehee said:
I wouldn't think the old username matters. As frono mentions, I would not be surprised if Mafia doesn't handle some aspect of username changes properly. But it sounds like this happened on a fresh login, so I doubt that's directly related.

The relevant daily limits in the mood seem to be for the Aug 7 (incredibly well lit) and Aug 13 (left/off-hander's day) skills. This agrees with the stack trace (UseSkillRequest.java:648 is a switch case for the Aug skills).

I don't suppose you have any lines in your session log about errors parsing daily limits? Something like "Daily Limit: Cast Acquire Rhinestones is bogus" or "Daily Limit: Cast Ancestral Recall has invalid max".

I don't see a relevant debug log entry, so I think we can rule out DailyLimitDatabase.reset() catching an exception in the middle of parsing.
Click to expand...
Come to think of it, there was some wonkiness during those startups where breakfast would re-attempt casting Advanced Cocktailcrafting even though I'd run out of those casts on an earlier login. I had to force an abort in the CLI. No message about daily limits that I can find or recall, though.

I lost the text itself, but here's a snippet from the one of the session logs (it goes on for a bit, so I've cut it short):
1701537996962.png
 
Trying to cast Advanced Cocktailcrafting 112 times lines up with daily limits not being handled correctly -- you should only be able to cast that once per day.

I don't have any other immediate insights as far as what could have gone wrong. I'll think about this some more.
 
Just tried logging in on a fresh session and there's some new weirdness -- it either displays "Error during session initialization" or if I click the "login" button again, it goes through all the motions and closes the login window without opening the actual mafia window. Notably, OpenJDKPlatform Binary continues to run if I do this, so it hasn't simply crashed.

If I'm not taking a look at the wrong debug log, this looks related to your Daily Limits hypothesis.

Here's a snippet of the log I've copy-pasted (I've also attached the full file):
Error during session initialization
class java.lang.NullPointerException: Cannot invoke "net.sourceforge.kolmafia.persistence.DailyLimitDatabase$DailyLimit.hasUsesRemaining()" because the return value of "net.sourceforge.kolmafia.persistence.DailyLimitDatabase$DailyLimitType.getDailyLimit(int)" is null
java.lang.NullPointerException: Cannot invoke "net.sourceforge.kolmafia.persistence.DailyLimitDatabase$DailyLimit.hasUsesRemaining()" because the return value of "net.sourceforge.kolmafia.persistence.DailyLimitDatabase$DailyLimitType.getDailyLimit(int)" is null
at net.sourceforge.kolmafia.request.UseSkillRequest.getMaximumCast(UseSkillRequest.java:648)
at net.sourceforge.kolmafia.request.UseSkillRequest.setBuffCount(UseSkillRequest.java:409)
at net.sourceforge.kolmafia.request.UseSkillRequest.getInstance(UseSkillRequest.java:1631)
at net.sourceforge.kolmafia.request.UseSkillRequest.getInstance(UseSkillRequest.java:1646)
at net.sourceforge.kolmafia.request.UseSkillRequest.getInstance(UseSkillRequest.java:1651)
at net.sourceforge.kolmafia.moods.MoodTrigger.<init>(MoodTrigger.java:86)
at net.sourceforge.kolmafia.moods.MoodTrigger.constructNode(MoodTrigger.java:432)
at net.sourceforge.kolmafia.moods.MoodManager.loadSettings(MoodManager.java:616)
at net.sourceforge.kolmafia.moods.MoodManager.loadSettings(MoodManager.java:591)
at net.sourceforge.kolmafia.moods.MoodManager.updateFromPreferences(MoodManager.java:69)
at net.sourceforge.kolmafia.preferences.Preferences.reset(Preferences.java:647)
at net.sourceforge.kolmafia.KoLCharacter.reset(KoLCharacter.java:343)
at net.sourceforge.kolmafia.session.LoginManager.initialize(LoginManager.java:394)
at net.sourceforge.kolmafia.session.LoginManager.doLogin(LoginManager.java:318)
at net.sourceforge.kolmafia.session.LoginManager.login(LoginManager.java:270)
at net.sourceforge.kolmafia.request.LoginRequest.processLoginRequest(LoginRequest.java:296)
at net.sourceforge.kolmafia.request.GenericRequest.handleServerRedirect(GenericRequest.java:1836)
at net.sourceforge.kolmafia.request.GenericRequest.retrieveServerReply(GenericRequest.java:1761)
at net.sourceforge.kolmafia.request.GenericRequest.externalExecute(GenericRequest.java:1399)
at net.sourceforge.kolmafia.request.GenericRequest.execute(GenericRequest.java:1386)
at net.sourceforge.kolmafia.request.GenericRequest.run(GenericRequest.java:1153)
at net.sourceforge.kolmafia.request.LoginRequest.run(LoginRequest.java:128)
at net.sourceforge.kolmafia.RequestThread.postRequest(RequestThread.java:242)
at net.sourceforge.kolmafia.RequestThread.postRequest(RequestThread.java:207)
at net.sourceforge.kolmafia.swingui.LoginFrame$LoginPanel.doLogin(LoginFrame.java:256)
at net.sourceforge.kolmafia.swingui.LoginFrame$LoginPanel.actionConfirmed(LoginFrame.java:220)
at net.sourceforge.kolmafia.swingui.panel.GenericPanel$ConfirmedListener.execute(GenericPanel.java:504)
at net.sourceforge.kolmafia.swingui.listener.ThreadedListener.run(ThreadedListener.java:175)
at net.sourceforge.kolmafia.RequestThread$SequencedRunnable.run(RequestThread.java:342)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Error during session initialization
 

Attachments

I've done a bit of experimentation that's got rather interesting results (methodology below, skip to "Results" if you don't care):
1) I moved all kolmafia files to an external device and removed it
2) Downloaded the most recent build r27705
3) New build logs in as expected -- it's a fresh set of files, after all
4) Closed the running instance and copied my CCS files over to the new ccs folder
5) Also copied+pasted my moods (from the moods text file) over to the new text file. Got rid of duplicates (apathetic, default)
6) Attempted to run mafia again. Login issue, debug log printed (attached)
7) Closed mafia, cleared the mood changes
8) Opened mafia again, no apparent issues.

Results: Errors appear(?) to stem at least partially from my mood settings.
 

Attachments

Further testing seems to imply that the mood setting that checks for and refreshes "incredibly well lit" leads to a problematic login.
 
I would expect the trigger to be related to "incredibly well lit" as well as "offhand remarkable", since those are the two skills that show up in dailylimits.txt.

I think the issue may actually be an initialization issue. DailyLimitDatabase.reset() is supposed to be called statically, but it doesn't seem to be set at this time. To this point in logging into a fresh character, we've never actually called a static method on DailyLimitDatabase (the explicit call to DailyLimitDatabase.reset() happens later in KoLCharacter.reset(boolean)).

Meanwhile, if you first log into a character that doesn't have such a mood, we call Preferences.reset(playerName), which doesn't use that specific codepath, then later call DailyLimitDatabase.reset(), which sets up the relevant objects for future logins.

I have a possible fix, although I don't think there's a good way to test it (since ~every test will call KoLCharacter.reset(), thereby initializing the object).
 
I believe r27711 should fix this, but let us know if you still experience the bug after that revision. Thanks!
 
You must log in or register to reply here.
Back
Top