212

I'm working on my usual projects on Eclipse, it's a J2EE application, made with Spring, Hibernate and so on. I'm using Tomcat 7 for this (no particular reason, I don't exploit any new feature, I just wanted to try that). Every time I debug my application, it happens that Eclipse debugger pops out like it has reached a breakpoint, but it is not the case, in fact it stops on a Java source file that is ThreadPoolExecutor. There is no stack trace on the console, it just stops. Then if I click on resume it goes on and the app works perfectly. This is what shows in the debugger window:

Daemon Thread ["http-bio-8080"-exec-2] (Suspended (exception RuntimeException)) 
    ThreadPoolExecutor$Worker.run() line: 912   
    TaskThread(Thread).run() line: 619

I really can't explain this, because I'm not using ThreadPoolExecutor at all. Must be something from Tomcat, Hibernate or Spring. It's very annoying because I always have to resume during debugging.

Any clues?

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
gotch4
  • 13,093
  • 29
  • 107
  • 170
  • 1
    @AmosM.Carpenter isn't it Java EE, not JEE? Even your own link seems to suggest so – eis Jun 09 '15 at 15:34

4 Answers4

298

The posted stack trace indicates that a RuntimeException was encountered in a Daemon thread. This is typically uncaught at runtime, unless the original developer caught and handled the exception.

Typically, the debugger in Eclipse is configured to suspend execution at the location where the exception was thrown, on all uncaught exceptions. Note that the exception might be handled later, lower down in the stack frame and might not lead to the thread being terminated. This would be cause of the behavior observed.

Configuring the behavior of Eclipse is straightforward:
Go to Window > Preferences > Java > Debug and uncheck Suspend execution on uncaught exceptions.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
  • In my case http://stackoverflow.com/questions/8911146/eclipse-debugger-stops-by-itself-without-any-throwable it didn't help :-( – Gangnus Jan 18 '12 at 15:27
  • 5
    I've filed Eclipse bug [384073](https://bugs.eclipse.org/bugs/show_bug.cgi?id=384073) about this since it essentially makes this option unusable when debugging Web apps. – Daniel Serodio Jul 02 '12 at 18:18
  • In my case this exception was throwing every time the web application was redeploying with WTP. Thanks!! – David García González Aug 29 '12 at 08:20
  • 9
    Disabling the "Suspend execution on uncaught exceptions" on Eclipse is a bad workaround: what if you do want Eclipse to suspend on real uncaught exceptions, e.g. originating from your own code? It seems to me this is a bug in Tomcat... –  Dec 24 '12 at 10:16
  • 3
    @Luis: I wondered the same! As per https://bugs.eclipse.org/bugs/show_bug.cgi?id=384073#c4 , one can: disable the global breakpoints, create a new breakpoint on java.lang.Exception, and apply an exclusive filter against this newly created breakpoint. – rektide Jan 23 '13 at 21:56
  • 3
    @Daniel... Maybe better to file an issue with the Tomcat team. I think this behavior is new in Tomcat 7... Eclipse does what it is supposed to do... (never thought I would end up defending Eclipse one day... :) – Stijn de Witt Sep 06 '13 at 14:26
  • Why is this still a default setting in Eclipse? – Brain Jul 02 '20 at 09:42
48

There's a more specific solution, which prevents Eclipse breaking on RuntimeExceptions thrown only from a given class.

  1. Add a new exception breakpoint from the Debugging perspective
  2. Go to its properties
  3. Go to Filtering
  4. In "Restrict to Selected Location(s)", click "Add Class"
  5. Add java.util.concurrent.ThreadPoolExecutor
  6. Untick the checkbox, meaning these will be ignored
DeejUK
  • 12,891
  • 19
  • 89
  • 169
  • 1
    I can't seem to make it work with Tomcat 7 and Eclipse/STS 3.4.0. Are there any other settings necessary? Should this breakpoint be registered on `RuntimeException`? Does it have to enabled or disabled? Should 'Caught locations' and 'Uncaught locations' be on or off? – Henrik Heimbuerger Dec 02 '13 at 16:33
  • 2
    It appears that the exception breakpoint needs to be a java.lang.RuntimeException, must be enabled, must be for uncaught location only, and must not have the java.util.concurrent.ThreadPoolExecutor class checked. – mario Jul 09 '14 at 02:47
  • Unfortunately on Ubuntu 14.04 the "Restrict to Selected Location(s)" is not available, for Eclipse Luna 4.4.0. – eeezyy Sep 03 '14 at 14:19
25

This behavior is triggered by tomcat when a webapp is reloaded. It's part of tomcat "memory leak protection" feature that (among other things) forces the renewal of its threads.

This is now fixed from versions 7.0.54 and 8.0.6 of tomcat : https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

slaurent
  • 1,127
  • 9
  • 5
2

I have noticed that this often occurs after modifying server files (jsp or java) and STS has trouble reloading the application.

This usually leads to restarting the server in order to get it to get the changes synchronized.

After introducing JRebel - it appears to have gone away. So, I would like to think it is a reproducible issue in STS when hotswapping code in debug mode.

By removing the native hotswapping, it eliminates the issue with it breaking inside the ThreadPoolExecutor class.

DaCrazyCoder
  • 51
  • 1
  • 5