[ cobertura-Patches-2806475 ] FileLocker exception when writing coverage data

[SourceForge.net <no...@so...>]

Patches item #2806475, was opened at 2009-06-15 14:38
Message generated for change (Comment added) made by pranav24061980
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Chris van Es (cvanes)
Assigned to: John Lewis (lewijw)
Summary: FileLocker exception when writing coverage data

Initial Comment:
With the latest java 6 there's now an exception thrown when you attempt to register a shutdown hook whilst the jvm is shutting down, previously the call would just have been ignored. This means that as a jvm is being shutdown there is an attempt by cobertura to register the hook to delete a lock on the coverage file and an exception thrown before coverage data had been written. I've patched this to use a try/catch/finally block to delete the lock instead of the java.io.File.deleteOnExit method

----------------------------------------------------------------------

Comment By: Pranav (pranav24061980)
Date: 2011-05-19 17:27

Message:
But how can we compile these two java files.. after making changes I am not
able to compile this file getting compilation errors.. compilar is not able
to find any class file.

----------------------------------------------------------------------

Comment By: John Lewis (lewijw)
Date: 2009-06-25 20:25

Message:
Turns out that the delete of the lock file cannot be done while the lock is
in place.   So, since the FileLocker.release() method deletes the file
anyway, I'm removing the FileLocker.delete method.

----------------------------------------------------------------------

Comment By: John Lewis (lewijw)
Date: 2009-06-25 19:49

Message:
Rick,

I see your point.  I forgot the release method is doing a delete.   I've
removed the delete method, and within release(), I have moved the delete of
the file before the release of the lock.

John

----------------------------------------------------------------------

Comment By: Rick Riemer (ricq)
Date: 2009-06-25 18:24

Message:
The patch seems to do the job.

It seems strange to add the delete call to ProjectData though, because
release() already does a delete(). Two consecutive deletes won't make the
file go more away.

Looking forward to the release.

----------------------------------------------------------------------

Comment By: Chris van Es (cvanes)
Date: 2009-06-25 17:27

Message:
Yes, it does seem better to catch Throwable, although I think you're right
that current behaviour should remain, it's an error that we can't really
recover from.

----------------------------------------------------------------------

Comment By: John Lewis (lewijw)
Date: 2009-06-25 16:17

Message:
Thanks for the patch Chris!

I applied your patch pretty much the way you submitted it with the
following changes:

1.  I delete the file before releasing the lock.   Let me know if you see
a problem with this.
2.  I removed the catch (Exception).  I hope to release 1.9.2 today, and I
am more comfortable with keeping the current behavior when an Exception is
thrown.   We can add the print of the stack trace later if that is better,
but if we do, isn't it better to catch (Throwable) instead of just
Exception?

Revision 604.

Thanks again!

John


----------------------------------------------------------------------

Comment By: Chris van Es (cvanes)
Date: 2009-06-16 14:07

Message:
Ok, I've updated the ProjectData class to print out some info if an
exception is thrown whilst attempting to output coverage data. I haven't
verified but this issue may only affect java 6_14 at the minute, I haven't
had a chance to determine if this is an issue with earlier updates.

----------------------------------------------------------------------

Comment By: wyvern5 (wyvern5)
Date: 2009-06-16 06:03

Message:
I cast a vote in favor of prioritizing this fix. :) Are you sure that the
empty catch block is appropriate, though? It'd mean errors when merging and
saving coverage data would be silently ignored, if I'm understanding that
snippet correctly. (I haven't looked into what the calls inside the try {}
are doing, though -- I'm just guessing based on the method names.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2806475&group_id=130558