Search results

I think this particular failure mode would, since I don't think any of these listeners are setting properties.

I got timein to succeed locally, although I'm still tweaking the code. I suspect that in general, we need to trigger listener updates on the Swing event dispatch thread, to avoid Swing synchronization from causing deadlocks with preference reads.

Okay. It turns out even if we move that out of the lock, we still run into issues, since LoginManager.timein() grabs the lock up the stack. I suppose I can make AdventureFrame.updateFromPreferences schedule on the event thread...

This reproduces even with saveSettingsOnSet set to false. It looks like we're doing UI processing off the Swing Event dispatch thread (CommandQueueHandler is updating models...) which is causing a deadlock between Swing UI updates and preference reads. I made an edit that prints out the...

This was triggered simply by executing `timein` in the CLI. It silently prints a debug log, but it can't really notify the user about that because the GUI is stalled.

(I wrote a deadlock detector that spits out debug logs.)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= KoLmafia r27526-M, Linux, Java 17.0.8 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Please note: do not post this log in the KoLmafia thread of KoL's Gameplay-Discussion forum. If you would...

I've stared at the code some more, and I think this could only be problematic when timing in across rollover. That's not relevant here (even if it is a real bug, which I'm still not convinced of). I don't see anything special about cheating for the Mickey Mantle card (in the code or otherwise)...

This should be reverted as of r27526. Sorry for the breakage. @fronobulax I've started tinkering in https://github.com/kolmafia/kolmafia/pull/1889 if you want to play around there.

One instance of deadlock potential: resetDailies (holding userValues) calls Preferences.setString, which eventually dispatches to setObject. If saveSettingsOnSet is true, this calls maybeSaveToFileAfterUpdating() which in turn calls saveToFile, which grabs lock. Meanwhile, reset() will grab...

One of the threads is most likely the timein. In Veracity's case, that sounds like it was blocking the Swing event dispatch thread (since it was triggered by clicking on a UI element). ApiRequest.updateStatus(boolean) is a synchronized function. This calls ApiRequest.run(), which delegates to...

Well. The usual questions I ask are more pedagogical to figure out what's going on. Java synchronized sections should be reentrant, namely that if a single thread can acquire the same lock multiple times in a call stack. For anyone who reproduced this: was Mafia pegging a full CPU core? That...

My general rule of thumb is "revert and ask questions later".

Pretty much the only weirdness I'm able to reproduce is: - The second run is better than the first run. - Maximizer keeps wanting to unequip the mer-kin breastplate. No significant reduction in score from iterated runs :/ Attaching a patch in case it's a useful starting point for someone else.

Can you provide a full list of your equipped items before/after? In particular, the above CLI output snippets only show 2 accessories moving around.

From ChatSender.java: ChatSender.scriptedMessagesEnabled = recipient == null || recipient.equals("") || recipient.equals("/clan") || recipient.equals("/hobopolis") || recipient.equals("/slimetube") ||...

Does it really matter which name we go with, as long as we're consistent? r26878 (the change that introduced the preferences in the first place) specified lastFriars... in QuestManager.java and the corresponding tests, but lastFriar... in defaults.txt and Preferences.java. So we actually never...

Blocking writes but not reads is somewhat atypical, especially in the context of ReadWriteLocks (where you generally can have many simultaneous readers but only one writer). It seems reasonable in this context, but sounds like it would need to be handled carefully (regarding performance...

Ah, looks like you made that change in r27450. I haven't fully decided how I feel regarding cancel on timein, but my gut agrees with MCroft's suggestion to present the Login frame, based purely on the wording in the prompt: buf.append(" Press 'Yes' if you are satisfied with the current...

I did the same thing, so I support this request. As an alternative, I'd also support printing an error if the value is neither "true" nor "false".