Bug Debug logs after update to KoLmafia-20329M.jar

Ethelred

Member
I run multiple KoL chars and use 2 different computers. I build my mafia .jar files on system A and run them on both system A and system B. After updating to KoLmafia-20329M.jar today, I started getting debug logs on system B, but not system A. Each login generates 30 some debug logs, which all go into the same file. I edited that file to only include the first 2, but can provide more if you wish. Mafia seems to run fine in spite of all the debug logs.

System info:

System A:
MacOS Mojave -10.14
java version "1.8.0_201"

System B:
MacOS El Capitan -10.11.6
java version "1.8.0_201"

I tried to update ant to 1.10.8, which is still a work in progress for me, on system A where I build the .jar files. I don't know if this would have any effect on executing the .jar files on system B, but it's the only other thing I can think of that changed besides the KoLmafia source. The ant version on system B is 1.9.4

Thanks for any help with this mysterious behaviour.
 

Attachments

  • DEBUG_20200827.txt
    9.6 KB · Views: 19
Last edited:

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
I assume Sourceforge was down and the svnrepo.json download was invalid. This is the second time this has happened recently so I'll look into making the error nicer. But no fix available as such.
 

Ethelred

Member
Thanks for looking into to this. Is it possible that something more complex is going on? I only get the debug logs on system B. I can login another char on system A at the same time without getting debug logs. Checking Sourceforge via a browser during these times seems to indicate it is up and running. Any thoughts about what could be fubar on system B to cause this?
 

fronobulax

Developer
One test would be to confirm you are using the same jar file on both systems.

Another test would be to download a build from kolmafia.us instead of building your own.

Are both systems on the same network and likely to use the same network path to SourceForge?

A long shot since it seems to be building the Scripts menu and not trying to update, but it may be that the svn directories are corrupt on one system. If you have a snv tool that could verify/clean you might use it. Otherwise maybe copying the svn directory from the good system and use it to replace what is on the bad one might work.

But I'm clueless. I'm posting because sometimes when people try and explain to me why I'm clueless they stumble upon new data or ideas that lead to a real solution.
 

MCroft

Developer
If it's 38 debug logs, it's 38 attempts to update the script menu. You can probably make it happen after launch by opening the script Manager from the script menu, right clicking on a script, and choosing "reload remote repository". If it does cause the error to get added to the debug log, you can turn on the debug log before doing it a 2nd time to see if it captures more information.
That command gives me this DEBUG log:

Field: Strict-Transport-Security = [max-age=31536000]
Field: Cache-Control = [no-cache]
Field: Server = [nginx]
Field: X-Content-Type-Options = [nosniff]
Field: Content-Disposition = [attachment;filename="svnrepo.json"]
Field: Connection = [keep-alive]
Field: Pragma = [no-cache]
Field: Date = [Sun, 30 Aug 2020 04:53:40 GMT]
Field: Content-Type = [application/json]



You might check to see if your preferences for SVN are different between machine A and machine B. Maybe you're not updating automatically on one of the two.

BTW, the DEBUG shows that you're running 1.8_261, which I have not had great luck with. If you do have _201 on your system, you might want to set JAVA_HOME to that before launching. You might also want to run the jar from the terminal with java -jar /path/to/KoLMafia.jar, to see if you get more messages on the console. And you can always try https://adoptopenjdk.net (for Java 8, 11, or greater...).
 

Ethelred

Member
One test would be to confirm you are using the same jar file on both systems.

I'm difintely using the same jar file. I just copy it via drag and drop to a shared drive. But, as mysteriously as it arrived, the problem has gone away. No debug logs after rollover on Friday evening.

Another test would be to download a build from kolmafia.us instead of building your own.

Didn't get around to trying this since the problem went away

Are both systems on the same network and likely to use the same network path to SourceForge?

The two computers are attached to the same router. The computes are shared via a KVM switch. I can't think of any reason the network path would be different. But then I can't think of any way this whole think could be happening. Maybe my imagination is just lacking.

A long shot since it seems to be building the Scripts menu and not trying to update, but it may be that the svn directories are corrupt on one system. If you have a snv tool that could verify/clean you might use it. Otherwise maybe copying the svn directory from the good system and use it to replace what is on the bad one might work.

If the problem comes back, I'll try to figure out how to do that and give it a try.

But I'm clueless. I'm posting because sometimes when people try and explain to me why I'm clueless they stumble upon new data or ideas that lead to a real solution.

Thanks for your help. I'm also quite clueless in these matters. Much of the SVN stuff was set up more than 12 years ago and has remained vitrually untouched since then. I don't follow any kind of regular update schedule for the mafia build system I use. I suppose this could be a factor in the bit rot I seem to be experiencing.
 
Last edited:

Ethelred

Member
If it's 38 debug logs, it's 38 attempts to update the script menu. You can probably make it happen after launch by opening the script Manager from the script menu, right clicking on a script, and choosing "reload remote repository". If it does cause the error to get added to the debug log, you can turn on the debug log before doing it a 2nd time to see if it captures more information.
That command gives me this DEBUG log:

Field: Strict-Transport-Security = [max-age=31536000]
Field: Cache-Control = [no-cache]
Field: Server = [nginx]
Field: X-Content-Type-Options = [nosniff]
Field: Content-Disposition = [attachment;filename="svnrepo.json"]
Field: Connection = [keep-alive]
Field: Pragma = [no-cache]
Field: Date = [Sun, 30 Aug 2020 04:53:40 GMT]
Field: Content-Type = [application/json]



You might check to see if your preferences for SVN are different between machine A and machine B. Maybe you're not updating automatically on one of the two.

BTW, the DEBUG shows that you're running 1.8_261, which I have not had great luck with. If you do have _201 on your system, you might want to set JAVA_HOME to that before launching. You might also want to run the jar from the terminal with java -jar /path/to/KoLMafia.jar, to see if you get more messages on the console. And you can always try https://adoptopenjdk.net (for Java 8, 11, or greater...).

As I mentioned above, the problem seems to have gone away. If it returns, I'll try some of your suggestions. One thing you say really puzzles me, though. Everything I can think of to check on my system says I'm running java version "1.8.0_201", Java(TM) SE Runtime Environment (build 1.8.0_201-b09) not the 1.8_261 you mention.

In any event, thanks for the help. It's much appreciated. And I'm sorry to be such a dunce about this stuff, but as I say, much of it was installed many years ago, only updated as needed, and now mostly forgotten.
 
As I mentioned above, the problem seems to have gone away.

It went away because Sourceforge fixed their shit. I had the same issue happen every day I logged in. Checking the CLI showed a bunch of errors trying to check for updates from scripts hosted on Sourceforge's SVN (see this debug log View attachment DEBUG_20200828.txt that's the last time it happened)

Yes KoLmafia could handle failures like that more gracefully but if the problem is Sourceforge's servers, you're going to have to wait until they fix their issue.
 

fronobulax

Developer
As I mentioned above, the problem seems to have gone away. If it returns, I'll try some of your suggestions. One thing you say really puzzles me, though. Everything I can think of to check on my system says I'm running java version "1.8.0_201", Java(TM) SE Runtime Environment (build 1.8.0_201-b09) not the 1.8_261 you mention.

In the debug log, mafia reported it thought it was running
KoLmafia v20.7 r20323, Mac OS X, Java 1.8.0_261
which does not seem to me to match the version you reported when you provided the OS specs in the first post. I don't know whether that means you have multiple versions of Java or it is a continuation of the Java quirk that provides different labels for the same version.

Tangentially on Windows it was quite possible to inadvertently have two versions because installing/updating the developer's kit (JDK) did not necessary force an update of the runtime environment (JRE) which is what the operating system was going to use unless given a means to choose otherwise. So path, environment variables and how you invoked Java determined whether you got the JDK or the JRE,
 

fronobulax

Developer
It went away because Sourceforge fixed their shit. I had the same issue happen every day I logged in. Checking the CLI showed a bunch of errors trying to check for updates from scripts hosted on Sourceforge's SVN (see this debug log View attachment 9755 that's the last time it happened)

Yes KoLmafia could handle failures like that more gracefully but if the problem is Sourceforge's servers, you're going to have to wait until they fix their issue.

Agreed but since not all versions of mafia/Java respond the same way to SFs failures, there is an opportunity to improve mafia.

One obvious difference is you saw the issue "every day". I saw it only once, and that was a day when SF was so foobar'd that source code could not be updated. Furthermore, while I had error messages in the gCLI, I never had a debug log generated, let alone an entry for each script.
 
Top