(Unknown Source) in Exception stack trace

Question

Background

This question is related to Why does String.valueOf(null) throw a NullPointerException?

Consider the following snippet:

public class StringValueOfNull {
    public static void main(String[] args) {
        String.valueOf(null);

        // programmer intention is to invoke valueOf(Object), but instead
        // code invokes valueOf(char[]) and throws NullPointerException
    }
}

As explained in the answer to the linked question, Java's method overloading resolves the above invokation to String.valueOf(char[]), which rightfully results in a NullPointerException at run-time.

Compiled in Eclipse and javac 1.6.0_17, this is the stack trace:

Exception in thread "main" java.lang.NullPointerException
        at java.lang.String.<init>(Unknown Source)
        at java.lang.String.valueOf(Unknown Source)
        at StringValueOfNull.main(StringValueOfNull.java:3)

Note that the stack trace above is missing the KEY information: it does NOT have the full signature of the valueOf method! It just says String.valueOf(Unknown Source)!

In most situations I've encountered, exception stack traces always have the complete signature of the methods that are actually in the stack trace, which of course is very helpful in identifying the problem immediately and a major reason why the stack trace (which needless to say is rather expensive to construct) is provided in the first place.

And yet, in this case, the stack trace does not help at all. It has failed miserably in helping the programmer identify the problem.

As is, I can see 3 ways that a programmer can identify the problem with the above snippet:

Programmer realizes on his/her own that the method is overloaded, and by resolution rule, the "wrong" overload gets invoked in this case
Programmer uses a good IDE that allows him/her to quickly see which method is selected
- In Eclipse, for example, mouse-hovering on the above expression quickly tells programmer that the String valueOf(char[] data) is indeed the one selected
Programmer examines the bytecode (ugh!)

The last option is probably the least accessible, but of course is the Ultimate Answer (a programmer may misunderstood the overloading rule, IDE may be buggy, but bytecodes always(?) tell the truth on what's being done).

The questions

Why is the stack trace so uninformative in this case with regards to the signatures of the methods that are actually in the stack trace?
- Is this due to the compiler? The runtime? Something else?
In what other (rare?) scenarios can the stack trace fail to capture essential information like these?

Note that the exact content of a stack trace is not specified in the JVM spec or the JLS, so implementors are pretty free on what they provide. Also: my installation provides the source file and line numbers in the stacktrace (it's the OpenJDK, however), so I think it depends on what you use to run your code (JRE vs. JDK). — Joachim Sauer, Jun 28 '10 at 12:34
Whoa I just realized that I may have made a fool out of myself here; exception stack traces NEVER includes the signature of the method, apparently(?). It includes only filename and line number at best. I swear I've seen signatures too before, but maybe I was mistaken somehow. Would've been nice, though (and should be easy to implement too, since information about signature is more available than source file name and line number). — polygenelubricants, Jun 28 '10 at 12:35
including full method signatures would make stack traces really hard to read. — unbeli, Jun 28 '10 at 12:36

score 111 · Answer 1 · answered Dec 29 '11 at 06:54

111

Note that if you are using Ant build and if the debug attribute set to false in javac command this could happen.

ex : if you need proper location in trace set debug = true in Ant build,

    <javac verbose="false" srcdir="${src}" destdir="${classdir}" debug="true" includes="**/*.java">
        <classpath refid="compile.classpath" />
    </javac>

answered Dec 29 '11 at 06:54

Supun Sameera

2,683
3
17
14

1

In NetBeans, right click on properties, then in Build/Compiling tab, make sure "Generate Debugging Information" is ticked. – FreewheelNat Feb 11 '13 at 10:09
2

Didn't work for me, added debug="true" debuglevel="lines,vars,source" – JoeManiaci Feb 23 '16 at 18:52
I have a maven project. Project java build path uses JDK library. I see the unknown source error in the code of a non-jdk library. How do I fix it ? – MasterJoe Jul 12 '17 at 18:30

score 30 · Accepted Answer · answered Jun 28 '10 at 12:31

30

This is normally related to missing debug information. You are probably using JRE (not JDK), which does not include debug information for rt.jar classes. Try using full JDK, you'll get proper locations in the stack trace:

Exception in thread "main" java.lang.NullPointerException
    at java.lang.String.<init>(String.java:177)
    at java.lang.String.valueOf(String.java:2840)
    at StringValueOfNull.main(StringValueOfNull.java:3)

answered Jun 28 '10 at 12:31

unbeli

29,501
5
55
57

8

Hi guys! I know it's been a few years but... I'm using ant's javac, without any special (anti-debugging) arguments, and all of my system and project paths are pointing to my JDK, not the JRE installation. What else could be producing the "Unknown source?" – justian17 Feb 18 '14 at 00:40
This did not work for me. I have a maven project. Project java build path uses JDK library. I see the unknown source error in the code of a non-jdk library. How do I fix it ? – MasterJoe Jul 12 '17 at 18:29
If you're just using `javac` to compile your sources, you can enable debug infos with `-g` command line flag. – huch Jun 13 '18 at 07:47
Please note that javac does generate line number and source file debug info, without the need to add `-g` flag. All kinds of IDEs and build tools (eg. mvn, ant, gradle) may have different means to enable or disable the debug info. – huch Jun 13 '18 at 08:39

score 6 · Answer 3 · answered Feb 19 '14 at 20:19

I had the same problem, I'm using spring and apache ant for continuous integration.

The error I had was in the build.xml file.

The gender change log with more precise content was:

build.xml with the error:

    <javac srcdir="${src.home}" destdir="${work.home}/WEB-INF/classes">
        <classpath refid="compile.classpath" />
    </javac>

build.xml without error:

    <javac srcdir="${src.home}" destdir="${work.home}/WEB-INF/classes"  debug="true">
        <classpath refid="compile.classpath" />
    </javac>

Within the structure I lacked the courage debug = "true"

score 3 · Answer 4 · answered Jun 28 '10 at 12:34

I ran the code in Eclipse and I got the following output,

public class Aloof {
    public static void main(String[] args) {
        String.valueOf(null);
    }
}

Exception in thread "main" java.lang.NullPointerException
    at java.lang.String.<init>(String.java:177)
    at java.lang.String.valueOf(String.java:2840)
    at mysql.Aloof.main(Aloof.java:19)

If you include the full source (from JDK), you can actually debug to the line 177 in String.java

How do you include full source from JDK ? – MasterJoe Nov 21 '17 at 03:19 — MasterJoe, Nov 21 '17 at 03:19

score 1 · Answer 5 · answered May 13 '14 at 01:48

1

In Eclipse: Preferences > Java > Installed JREs. The checked entry should have a path inside the JDK, e.g. C:\Program Files (x86)\Java\jdk1.7.0_55\jre.

answered May 13 '14 at 01:48

Peter Tseng

13,613
4
67
57

score 1 · Answer 6 · answered Jun 28 '10 at 12:38

1

This happens when there is no debug (line) information in the source or the VM is told to throw that information away at class loading time. Since you have some line numbers, it's not the VM setting but the class String is missing debug information.

answered Jun 28 '10 at 12:38

Aaron Digulla

321,842
108
597
820

(Unknown Source) in Exception stack trace

Background

The questions

6 Answers6

Linked

Related