Stopping a torrent while I2PSnark is allocating space causes out of bounds exception

[Reportage]

java.lang.IndexOutOfBoundsException: Illegal Request (6119,262144,1)
     at org.klomp.snark.Request.<init>(Request.java:52)
     at org.klomp.snark.PeerState.returnPartialPieces(PeerState.java:547)
     at org.klomp.snark.Peer.disconnect(Peer.java:484)
     at org.klomp.snark.PeerCoordinator.halt(PeerCoordinator.java:457)
     at org.klomp.snark.Snark.stopTorrent(Snark.java:640)
     at org.klomp.snark.Snark.stopTorrent(Snark.java:626)
     at org.klomp.snark.SnarkManager.stopTorrent(SnarkManager.java:2416)
     at org.klomp.snark.web.I2PSnarkServlet.processRequest(I2PSnarkServlet.java:1261)
     at org.klomp.snark.web.I2PSnarkServlet.doGetAndPost(I2PSnarkServlet.java:277)
     at org.klomp.snark.web.I2PSnarkServlet.doPost(I2PSnarkServlet.java:163)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
     at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
     at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
     at net.i2p.servlet.filters.XSSFilter.doFilter(XSSFilter.java:30)
     at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
     at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
     at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
     at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
     at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
     at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
     at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
     at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
     at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
     at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
     at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
     at org.eclipse.jetty.servlets.gzip.GzipHandler.handle(GzipHandler.java:529)
     at net.i2p.router.web.HostCheckHandler.handle(HostCheckHandler.java:120)
     at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
     at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
     at org.eclipse.jetty.server.Server.handle(Server.java:499)
     at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
     at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
     at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
     at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
     at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
     at java.lang.Thread.run(Thread.java:748)

[zzz]

nice

[Zlatin Balevsky]

Why are there any peers connected before the storage is allocated? I haven't seen any other torrent clients do this. This was most probably an incoming connection and I'm also going to guess the torrent was started and stopped repeatedly. Regardless, snark should not allow any incoming connections until the storage is allocated.

[Zlatin Balevsky]

If I'm right about it being started and stopped repeatedly, then the following is possible:

1. Torrent was started, and it's infohash added to the PeerCoordinatorSet
2. An incoming connection arrived and a new thread to handle it was started in ConnectionAcceptor line 200
3. Before that thread was able to do anything, the torrent was stopped and started again, removing the infohash from PeerCoordinatorSet but then re-adding it
4. The thread started in step 2 resumed operation and processed the incoming request, finding the infohash and adding the peer to the list
5. Torrent was stopped again and bang!

[zzz]

I'm working on a different theory.

@OP if you remember which torrent it was, can you confirm the piece size for it was 256 KB?

[Reportage]

I can confirm that I can reliably reproduce the error with torrents with a 256K piece size. Steps to reproduce:

• Start torrent
• Wait for "allocating" to appear on main torrent page
• Hit the Stop button

As an observation, it appears that, despite knowing the size of the torrent, the allocation doesn't take place until peer(s) have connected and start uploading.

[zzz]

I asked about piece size not because any particular piece size is problematic. I was trying to correlate the first line of the error:

java.lang.IndexOutOfBoundsException: Illegal Request (6119,262144,1)

with the piece size. So my question is, is the second number above (262144) equal to the piece size of the torrent being stopped?

Also, indeed, we don't allocate files until necessary, maybe that makes snark different than any other BT client, but it's not inherently a problem. And for magnets, you don't have a choice but to connect to peers first.

[zzz]

Fixed in d12c13d4e0e99c025a92c156e28f592e5b1ac9a7 0.9.35-5
Was caused by lazy reuse of Request class with a length of 1 on a completed piece. Added new constructor to fix it.
Due to locking, after clicking stop, page will not load until allocation is complete. That's the best I can do.