How do I stop stacktraces truncating in logs

Question

Lots of times in Java logs I'll get something like:

Caused by: java.sql.BatchUpdateException: failed batch
    at org.hsqldb.jdbc.jdbcStatement.executeBatch(jdbcStatement.java:1102)
    at org.hsqldb.jdbc.jdbcPreparedStatement.executeBatch(jdbcPreparedStatement.java:514)
    at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
    at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
    ... 113 more

Does anyone know how to get the full stacktrace showing (i.e. show the other 113 lines)?

The JavaDocs (for Java 7) for Throwable have a pretty detailed explanation of what's going on.

the other 113 lines are **already in** the stack trace if you check the previous logged lines — Ahmed Nabil, Jul 05 '21 at 22:20

score 80 · Accepted Answer · answered Jan 13 '09 at 02:20

80

When you see '...113 more', that means that the remaining lines of the 'caused by' exception are identical to the remaining lines from that point on of the parent exception.

For example, you'll have

com.something.XyzException
  at ...
  at ...
  at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
  at ... <the other 113 lines are here>...
Caused by: <the above>.

The two stack traces 'meet' at AbstractBatcher.executeBatch, line 242, and then from then on the upward call trace is the same as the wrapping exception.

answered Jan 13 '09 at 02:20

Cowan

37,227
11
66
65

1

What? The cause is the same as the wrapping exception? I didn't got it... The couse should show the line where the problem is from, what it not showing when truncating the stacktrace. I'm having this problem and would like to understand this answer, if someone could reformulate it... Thanks! By the way, this answer seem not to show how to print the full stacktrace. – The Student Jun 01 '10 at 18:55
24

@TomBrito you ARE seeing the full stacktrace -- you have two exceptions, one inside the other. If the stack trace of the inner (wrapped) exception is A B C D E F G, and the outer exception's stack trace is A B C Z, then you'll see OuterException with the stack trace Z C B A, "caused by" InnerException with the stack trace "G F E D C ... 'then 2 more'". Those 2 more are A and B, from the outer stack trace, and they are ommitted for brevity. – Cowan Jun 01 '10 at 23:14
3

This answer is incorrect. I've absolutely run into situations where the remaining lines are NOT identical. In this situation, the solution was to increase the maximum depth of the stack trace, as Nikita Koksharov points out, below, by using the -XX:MaxJavaStackTraceDepth VM Option. – senfo Jun 12 '19 at 13:20

score 32 · Answer 2 · answered May 02 '18 at 06:11

32

Increase -XX:MaxJavaStackTraceDepth JVM option.

answered May 02 '18 at 06:11

Nikita Koksharov

10,283
1
62
71

5

Why is this being downvoted? This is exactly the answer. Set to -1 for an unlimited depth. – senfo Jun 12 '19 at 13:17
1

maybe "-1" doesn't work anymore in recent java versions? – masterxilo Oct 31 '22 at 12:14
-1 is out of range for jdk16. Message appearing: `-1 is outside the allowed range [ 0 ... 1073741823 ]`. Max range is 1073741823 maybe. – Grim Nov 09 '22 at 11:47
Any idea how to get this to work in Tomcat? I tried `JAVA_OPTS=" -XX:MaxJavaStackTraceDepth=2000 "` and `CATALINA_OPTS=" -XX:MaxJavaStackTraceDepth=2000 "` but neither worked. – Sridhar Sarnobat Jun 21 '23 at 20:45

score 22 · Answer 3 · edited Sep 05 '14 at 08:55

22

Apache's Commons Lang provides a nice util method ExceptionUtils.printRootCauseStackTrace() which prints a nested stacktrace 'upside down'. The result is much more intuitive.

If you see the result next to the original out of the printStackTrace() method, it will be clear where the '113 more' lines went.

edited Sep 05 '14 at 08:55

seanf

6,504
3
42
52

answered Jan 13 '09 at 09:41

Hes Siemelink

459
2
4

score 14 · Answer 4 · answered Dec 20 '14 at 14:09

I like the example found here:

HighLevelException: MidLevelException: LowLevelException
         at Junk.a(Junk.java:13)
         at Junk.main(Junk.java:4)
 Caused by: MidLevelException: LowLevelException
         at Junk.c(Junk.java:23)
         at Junk.b(Junk.java:17)
         at Junk.a(Junk.java:11)
         ... 1 more
 Caused by: LowLevelException
         at Junk.e(Junk.java:30)
         at Junk.d(Junk.java:27)
         at Junk.c(Junk.java:21)
         ... 3 more

Basically in the source code, main calls function a which calls function b which calls ... which calls function e. Function e throws a LowLevelException which causes function c to catch the LowLevelException and throw a MidLevelException (wrapping the LowLevelException instance inside of the MidLevelException instance. The Exception class has a constructor that is capable of taking in a different exception, wrapping it). This causes function a to catch the MidLevelException and throw a HighLevelException which now wraps the previous two Exception instances.

As noted in the other answers, the stack trace isn't really truncated, you are seeing the full stack trace. The .. .3 more in my example is there because it would be redundant otherwise. If you wanted to be redundant and waste output lines, .. 3 more could be substituted with

at Junk.b(Junk.java:17)
at Junk.a(Junk.java:11)
at Junk.main(Junk.java:4)

But there is no need to output these three lines, because they are already implied.

score 0 · Answer 5 · answered Jan 01 '19 at 13:09

I found this useful to get the whole picture. Get a full stack trace of the Exception and the cause (which often shows repeated lines from the main Exception, but can be helpful).

        ... catch( Exception e) ...

        ... catch( NoClassDefFoundError e)
        {

                for(StackTraceElement ste: e.getStackTrace())
                {
                    System.out.println(ste);
                }

                if( e.getCause()!=null )
                {
                    for(StackTraceElement ste: e.getCause().getStackTrace())
                    {
                        System.out.println(ste);
                    }
                }
        }

score -2 · Answer 6 · answered Nov 18 '12 at 23:26

-2

In a blog post I just described how to get more than just "BatchUpdateException: failed batch": set hibernate.jdbc.factory_class=org.hibernate.jdbc.NonBatchingBatcherFactory to disable batching in hibernate. Normally one can use BatchUpdateException.getNextException to get the reason of the failure, but in some cases this may return null. Then it's useful to disable batching completely.

answered Nov 18 '12 at 23:26

MartinGrotzke

1,301
8
13

This does not answer the question. It may solve his situation in real life, so adding it as a comment to his question could be more helpful than posting an answer – Alexander Bird Jan 10 '18 at 20:42

How do I stop stacktraces truncating in logs

6 Answers6

Linked

Related