• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1
  • kkannaiy
  • Reporter: teck
  • October 16, 2007
  • 0
  • Watchers: 0
  • February 12, 2013
  • January 16, 2009

Description

The code that introduces synchronization on the resolve lock during array de-reference doesn’t handle exceptions correctly. In fact, the original exception will get lost and an IllegalMonitorStateException will be generated instead.

Exceptions can occur in this code path if:

a) Something unexpected like an OOME happens b) There is a programming error in the TC code, like an assertion failure c) The class for the array element cannnot be resolved.

The one that I worry most about is (c) since that is something a user can more or less naturally do on their own. Although, even though they are getting the wrong exception, I can’t imagine the handling in the customer application would really be any different in practice, it will be an unexpected exception.

If possible, it would be nice to isolate the deference into a helper method where we can make sure the the synchronization is always done correctly. It is hard (impossible?) to do inline at the moment since an existing exception handler can already be covering the code. But using a helper method means computing the type of dereference since AALOAD is not a typed instruction. The verifier won’t let us just write a method that returns Object here :-(

Comments

Fiona OShea 2008-12-11

Possibly related to DEV-2194

Chris Dennis 2009-01-16

Integration of an exception table sorter into the main adapter chain (beneath TransparencyCodeAdapter) solves this. The finally block added by the instrumentation will now appear before any enclosing handlers in the table ensuring that the monitorexit is always correctly executed. This has also allowed the removal of the checkArrayIndex method from TCObject as the array access can now throw in directly, knowing that the handler will correctly unlock the monitor.

Chris Dennis 2009-01-16

CDV-391 has the same underlying cause (exception table ordering).

Chris Dennis 2009-01-19

Retargeted as this was fixed as a side effect of a 2.7.3 targeted item (CDV-391).

Kalai Kannaiyan 2009-02-03

Tested with Terracotta 2.7.3, as of 20090129-100112 (Revision 11424 by cruise@WXPMO0 from 2.7), it is working as expected.