Bug SVN checkout twice = NPE

This happened in the script manager, when I told it to install the same script twice, thinking it didn't respond the first time...

Code:
Starting Checkout...
Starting Checkout...
Validating repo...
Validating repo...
Repo validated.
Repo validated.
<lots of SVN stuff>
At revision X.
<lots more SVN stuff, while it checks out the script again>
At revision X.
svn: E235000: Assertion failure in class 'org.tmatesoft.svn.core.internal.db.SVNSqlJetDb' (file SVNSqlJetDb.java) in method 'commit' on line 244: no opened transactions
Unexpected error, debug log printed.

KoLmafia v17.1 r16474, OS X 10.11.1, Java 8u66.
 

Attachments

  • DEBUG_20151116.txt
    3.3 KB · Views: 64
Last edited:
KoLmafia was also very slow, laggy and garbage collecting often at the time. I wonder if the memory eating issue reported elsewhere contributed to the initial slow response. There must be a memory leak somewhere...
 

Veracity

Developer
Staff member
There "must be" a memory leak.

I have literally no idea what you mean by "the memory eating issue reported elsewhere".

But, since you are a Java programmer, do feel free to track down the memory leak that "must be" present!

Thanks.
 
Heh, chalk this one up to lag and user error... but still, there IS an issue to be fixed here. SVN doesn't like being multi-instance run in parallel. So we should probably disallow that.
 

Theraze

Active member
Is svn not a locking CLI command? Most commands will only run one at a time there. It's why you can safely type "call farm.ash false<enter>exit<enter>" and have it finish farming and then quit, rather than immediately quitting.

There is the oddity in the initial login not locking the CLI unlike every other subsequent login under that instance, but that will need a FReq/Bug at some later point.

If SVN happens to be a command that runs in parallel rather than serial, it should probably just become a normal locking command, which would eliminate this problem...
 

heeheehee

Developer
Staff member
Multiple "locking CLI commands" can still be run concurrently, e.g. by a relay script or one of the handler scripts. Also, SVNManager has some locking (where I use locking here to denote mutexes), I think, but it's been a while since I last looked carefully at that code.
 

Theraze

Active member
Oh right, this was noted as happening through the script manager, which may not follow the sanity-checking of the gCLI console.
 
I'd whip up a quick and dirty patch to fix this if I was at a computer capable of running Java... ah well, will have to wait until later. (You shouldn't be allowed to install a script twice anyway, let alone install two copies in parallel.)
 
Top