Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-665

JVM hangs because of inappropriate error handling

XMLWordPrintable

      In JBPM code there are quite a few catch Throwable statements. These catch statements catch Errors as well as Exceptions, although JDK states that: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch." This can lead to very serious defects.

      One particular case is StackOverflowError. Catching and rethrowning it (together with its HUGE stack trace) causes the JVM thread to hang, taking up 100% CPU until the JVM is restarted, without reporting the error anywhere, so people can only guess why all of a sudden the thing went nuts.

      This can be reproduced by creating a process with a loop, e.g. an action and a jump back to that action with no tasks or other wait states in between. JBPM executes this loop with recursive calls, so once the loop executes somewhere above 100-150 times (with default JRE 1.5 settings), a StackOverflowError occurs, but it doesn't get thrown or reported, instead the thread just goes crazy and the application needs to be restarted... Proper error handling would have stopped such a process and reported the error.

      Process cycles such as this may not be very common in processes, but they are definitely possible, especially due to bugs in processes. JBPM can't possibly allow buggy processes to hang the entire application.

      A simpler way to reproduce the behaviour is this:

      public static void infiniteRecursion() {
      try

      { infiniteRecursion(); }

      catch (Throwable t)

      { throw new RuntimeException("Error.", t); }

      }

      This effectively causes the thread to hang, while catching only Exceptions properly stops the execution and reports the error.

      StackOverflowErrors may be caught, though, if they are handled properly - i.e. they must not be rethrown (an exception may be thrown, but without the original exception) and generally nothing should be done with them that involves their stack trace.

      Now, while StackOverflowErrors can be caught and handled properly, that may not be possible with other types of Errors. So I would suggest that all catch Throwable statements are replaced with catch Exception. Or, if you absolutely must catch Errors, make sure their handling mechanism is as lightweight as possible, because the JVM may be in a very bad state at that moment.

            tom.baeyens Tom Baeyens (Inactive)
            JakaJaksic Jaka Jaksic (Inactive)
            Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 3 hours
                3h
                Remaining:
                Remaining Estimate - 3 hours
                3h
                Logged:
                Time Spent - Not Specified
                Not Specified