Menu
I am currently working on some code that I inherited. When executing it, a lot of exceptions get logged to the console, where one such exception would look like this:
["bg-thread-0" Id=28 RUNNABLE
at java.util.zip.ZipFile.read(Native Method)
at java.util.zip.ZipFile.access$1400(ZipFile.java:56)
at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:677)
- locked java.util.zip.ZipFile@67369c20
at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:413)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at org.eclipse.osgi.baseadaptor.bundlefile.BundleEntry.getBytes(BundleEntry.java:102)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:511)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455)
...
Number of locked synchronizers = 1
- java.util.concurrent.ThreadPoolExecutor$Worker@66e5b079
]
I am using Logback for the logging. Now I have no idea where that exception is generated or logged, because that information is cut by the ....
I also have no idea what it means. I guess it's got something to do with deadlocks (because of the Number of locked synchronizers = 1), but I don't know for sure.
So my question is: How to proceed here? What does that exception mean, how do I debug and find it and how do I resolve it? I really have no clue and would appreciate any hints. Thanks!
348
In some cases, you’ll experience chained exceptions in your stack trace. As you could have guessed, the stack trace shows you multiple exceptions that have occurred. Each individual exception is marked by the words “Caused by”.
It’s an effective and simple solution to make your stack traces easy to understand. On top of that, when your program throws a Throwable instance, you can call the getStackTrace () function on the instance to access the stack trace. You can then decide to print the stack trace to your terminal so you can collect the information for log analysis.
Here’s an example stack trace that includes several “Caused by” clauses. As you can see, the root issue in this example is the database call dbCall. Hopefully, this information gives you a better understanding of how to approach a call stack. So, what’s a stack trace used for?
Each individual exception is marked by the words “Caused by”. The lowest “Caused by” statement is often the root cause, so that’s where you should look at first to understand the problem. Here’s an example stack trace that includes several “Caused by” clauses. As you can see, the root issue in this example is the database call dbCall.
That looks like more like a Java thread dump than a regular stacktrace. (I would expect to see one of those for each thread.)
You (typically) get a Java thread dump when something external to the JVM sends a SIGQUIT signal to the JVM process.
This Q&A has some ideas on how to track down the source of unexpected signals:
One suggested approach is to use the Linux Audit system (see man auditctl), and another is to use systemtap. (I don't have experience with either ... but I did spot some systemtap examples for tracking down signals here: https://sourceware.org/systemtap/examples/).
For what it is worth, a "synchronizer" is building block class that is used to implement locks; see http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/package-summary.html. The line:
Number of locked synchronizers = 1
is effectively saying that that the thread is currently holding one lock. Note that Oracle don't formally document what the thread dump means, and they apparently say that the format may change across versions / releases.
176
I found it!
Somewhere deep in the code I found the following:
for (ThreadInfo threadInfo : ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)) {
System.out.println(threadInfo);
}
So it was a Thread Dump after all, but one that was triggered internally. Thanks for the answers!
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With