Opened 8 years ago

Closed 8 years ago

#370 closed defect (fixed)

Potential resource leaks in net.i2p.util.FileUtil

Reported by: John Doo Owned by: zzz
Priority: minor Milestone: 0.8.4
Component: api/utils Version: 0.8
Keywords: Cc:
Parent Tickets: Sensitive: no

Description

I've noticed a potential resource leak in net.i2p.util.FileUtil?.copy(String source, String dest, boolean overwriteExisting, boolean quiet).

The input- and output-streams are closed in the try-block. This is a fault, as the streams never get closed if any one of the previous statements causes an exception. The correct way to do this is to close the streams in a finally-block.

readFile(String path, String root, OutputStream? out) contains potentially the same fault for the output stream, but maybe it's by intention to close the output stream only if the whole file was read successfully.

Yours sincerely
John Doo

Subtickets

Attachments (2)

diff.txt (2.7 KB) - added by John Doo 8 years ago.
diff2.txt (37.5 KB) - added by John Doo 8 years ago.
extractZip / verifyZip

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by John Doo

Attachment: diff.txt added

comment:1 Changed 8 years ago by Eche|on

Milestone: 0.8.3
Owner: set to zzz
Status: newassigned

comment:2 Changed 8 years ago by zzz

Yeah, that's the kind of thing caught by findbugs, and it's been a long time since anybody made an effort to clean that kind of stuff up.

For fun I just ran findbugs for the first time in a while. It found 691 issues, including 25 stream leaks, including the one you identified in this ticket. Lots of work to do.

Changed 8 years ago by John Doo

Attachment: diff2.txt added

extractZip / verifyZip

comment:3 in reply to:  2 Changed 8 years ago by John Doo

Replying to zzz:

Yeah, that's the kind of thing caught by findbugs, and it's been a long time since anybody made an effort to clean that kind of stuff up.

For fun I just ran findbugs for the first time in a while. It found 691 issues, including 25 stream leaks, including the one you identified in this ticket. Lots of work to do.

The same problem appears in extractZip and verifyZip. I've added diff2.txt for this, which doesn't contain the fixes of the previously mentioned failures, though.

Are there any code formatting rules for i2p? I'm using Eclipse, and I heavily use the built-in code formatter, which makes it very difficult to produce diffs afterwards.

comment:4 Changed 8 years ago by zzz

Milestone: 0.8.30.8.4

re: rules, the main rule is to follow what's already there, which is 4-space indent in most places. If you are generating diffs for others, you should probably turn off the Eclipse formatter.

comment:5 Changed 8 years ago by zzz

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.