Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Newcomers » Newcomers » Infamous Source Not Found message debugging(Can no longer step into java files within the same project)
Infamous Source Not Found message debugging [message #1015292] Thu, 28 February 2013 00:13 Go to next message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
I've been using Eclipse for a month or so without problems but recently debugging Java projects no longer works correctly.

I have a single Java project in my workspace.
It has three Java files.
I reference 2 external jar files.
The programs work correctly, but when I try to debug things aren't working correctly.



  • I set a breakpoint in one of the java files the debugger stops at the right place.
  • When I try to step into code in another java file (F5) in the same project I get the "Source Not Found: message.
  • The message window has the title - Launcher$AppClassLoader(ClassLoader).loadClass(String) line 356
  • If I set a breakpoint in the other java file and instead step over (F6) the debugger open the other file and breaks stops at the right place!!
  • I have tried to Edit Source Lookup Path to include Default and also to only include the project Source folder.
  • In the debug configuration - I have also tried to use the Default Source path and I have tried deleting the "Default" setting and adding only the workspace folder that the Java files are in.


I've tried using Google and most solutions involve setting the Source Lookup folder but that hasn't worked.

I am not stepping into the external jar files (even thought they have source attached)

I noticed recently that OpenJDK was upgraded which I think may be causing the problem, but I can't find any information about how to overcome this and get the old (correct) behaviour back i.e. Step into continues and opens the other java file in the same project.

Any advice appreciated.

I am using Juno:
Eclipse SDK
Version: 4.2.1
Build id: M20120914-1800

I'm using Arch linux 64 bit.
Linux 3.7.6-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

OpenJDK 7 :
java version "1.7.0_15"
OpenJDK Runtime Environment (IcedTea7 2.3.7) (ArchLinux build 7.u13_2.3.7-1-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)


Re: Infamous Source Not Found message debugging [message #1015432 is a reply to message #1015292] Thu, 28 February 2013 09:54 Go to previous messageGo to next message
David Wegener is currently offline David Wegener
Messages: 1334
Registered: July 2009
Senior Member
The "Launcher$AppClassLoader(ClassLoader).loadClass(String) line 356" window that you are seeing is the Java class loading processing kicking in to load the class you are stepping into. The Java VM doesn't load classes until it needs to. It uses the current executing thread to load the class when it gets to the point that the class needs to be loaded. In your case, your are stopping because of the step into and the next Java instruction being executed is in the class loader. If you keep performing step into from this point, you should quickly reach the class you wish to debug.

You are using OpenJDK, so I'm not sure what the options are for actually associating the source with this particular class. The class loader will be provided as part of the JRE you are running against. I know that in the Sun/Oracle case, the AppClassLoader class is in the sun.misc package which means that they don't distribute source for the file.

You can avoid stopping in the class loader by turning on Step Filtering and specifying the package/class in the filter list. You will only encounter this the first time the VM loads the class. Subsequent step intos into the same class will not stop in any class loader code.



Re: Infamous Source Not Found message debugging [message #1015439 is a reply to message #1015292] Thu, 28 February 2013 10:12 Go to previous messageGo to next message
Russell Bateman is currently offline Russell Bateman
Messages: 3131
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
> I've been using Eclipse for a month or so without problems but recently
> debugging Java projects no longer works correctly.
>
> I have a single Java project in my workspace.
> It has three Java files.
> I reference 2 external jar files.
> The programs work correctly, but when I try to debug things aren't
> working correctly.
>
>
> I set a breakpoint in one of the java files the debugger stops at the
> right place. When I try to step into code in another java file (F5) in
> the same project I get the "Source Not Found: message.
> The message window has the title -
> Launcher$AppClassLoader(ClassLoader).loadClass(String) line 356
> If I set a breakpoint in the other java file and instead step over (F6)
> the debugger open the other file and breaks stops at the right place!!
> I have tried to Edit Source Lookup Path to include Default and also to
> only include the project Source folder.
> [snip]

What David said explains is what's happening and his is the right answer.

To be very practical, however, I would add that, in this particular
case, you shouldn't seek to get code so that you can wander into and see
what's going on here because it's not interesting. Here's what I do:

1. Click the down arrow or press the function key to step into the class
I want to debug.
2. Find myself in the loader code (what's making you complain).
3. Click the yellow up arrow (or press the function key) to return out.
4. Continue at step #1.

What's in the loader code isn't interesting and this methodology I've
just given you will serve in other circumstances too such as loading
strings. When you find yourself in missing code, don't panic, just think
about why you got there and whether you can just step back out, then
step down again.

If you want to skip doing this because it's too much of a hassle, you can...

1. Just set a breakpoint down inside the code you want to go to and use
the resume (green arrow or function key) to get there (instead of
stepping); this by-passes what's making you complain here. Of course,
you actually have to know where execution will be going.

2. Write your code such that you don't make method calls or perform
menial actions (like string concatentation) in the argument list to
methods you wish to step down inside of. Later, when you're not so keen
to debug, you can restore your coded method calls to the way you usually
do it.

Hope this helps.
Re: Infamous Source Not Found message debugging [message #1015755 is a reply to message #1015432] Sat, 02 March 2013 04:36 Go to previous messageGo to next message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
David Wegener wrote on Thu, 28 February 2013 09:54
The "Launcher$AppClassLoader(ClassLoader).loadClass(String) line 356" window that you are seeing is the Java class loading processing kicking in to load the class you are stepping into. The Java VM doesn't load classes until it needs to. It uses the current executing thread to load the class when it gets to the point that the class needs to be loaded. In your case, your are stopping because of the step into and the next Java instruction being executed is in the class loader. If you keep performing step into from this point, you should quickly reach the class you wish to debug.

You are using OpenJDK, so I'm not sure what the options are for actually associating the source with this particular class. The class loader will be provided as part of the JRE you are running against. I know that in the Sun/Oracle case, the AppClassLoader class is in the sun.misc package which means that they don't distribute source for the file.

You can avoid stopping in the class loader by turning on Step Filtering and specifying the package/class in the filter list. You will only encounter this the first time the VM loads the class. Subsequent step intos into the same class will not stop in any class loader code.





Thanks for the answer - it seems I need to be a bit more careful about stepping into other classes - the tip about using the filtering is also very helpful.

Maybe I'm confused, but I'm sure I was stepping into my own constructors OK before this. To be clear I don't want to step into the platform loader classes, just into my own class constructors.
Re: Infamous Source Not Found message debugging [message #1015756 is a reply to message #1015439] Sat, 02 March 2013 04:40 Go to previous messageGo to next message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
Russell Bateman wrote on Thu, 28 February 2013 10:12
On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
> I've been using Eclipse for a month or so without problems but recently
> debugging Java projects no longer works correctly.
>
> I have a single Java project in my workspace.
> It has three Java files.
> I reference 2 external jar files.
> The programs work correctly, but when I try to debug things aren't
> working correctly.
>
>
> I set a breakpoint in one of the java files the debugger stops at the
> right place. When I try to step into code in another java file (F5) in
> the same project I get the "Source Not Found: message.
> The message window has the title -
> Launcher$AppClassLoader(ClassLoader).loadClass(String) line 356
> If I set a breakpoint in the other java file and instead step over (F6)
> the debugger open the other file and breaks stops at the right place!!
> I have tried to Edit Source Lookup Path to include Default and also to
> only include the project Source folder.
> [snip]

What David said explains is what's happening and his is the right answer.

To be very practical, however, I would add that, in this particular
case, you shouldn't seek to get code so that you can wander into and see
what's going on here because it's not interesting. Here's what I do:

1. Click the down arrow or press the function key to step into the class
I want to debug.
2. Find myself in the loader code (what's making you complain).
3. Click the yellow up arrow (or press the function key) to return out.
4. Continue at step #1.

What's in the loader code isn't interesting and this methodology I've
just given you will serve in other circumstances too such as loading
strings. When you find yourself in missing code, don't panic, just think
about why you got there and whether you can just step back out, then
step down again.

If you want to skip doing this because it's too much of a hassle, you can...

1. Just set a breakpoint down inside the code you want to go to and use
the resume (green arrow or function key) to get there (instead of
stepping); this by-passes what's making you complain here. Of course,
you actually have to know where execution will be going.

2. Write your code such that you don't make method calls or perform
menial actions (like string concatentation) in the argument list to
methods you wish to step down inside of. Later, when you're not so keen
to debug, you can restore your coded method calls to the way you usually
do it.

Hope this helps.


It does - all helpful information. Thanks. Seems I need to be more careful about using Step Into and setting breakpoints. It's strange because I'm sure that I was able to step into my own constructors without going into the platforms loader classes.
Still at least I know what's happening now.
Re: Infamous Source Not Found message debugging [message #1015779 is a reply to message #1015756] Sat, 02 March 2013 12:55 Go to previous messageGo to next message
Russell Bateman is currently offline Russell Bateman
Messages: 3131
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 03/02/2013 02:40 AM, bhrgunatha deva wrote:
> Russell Bateman wrote on Thu, 28 February 2013 10:12
>> On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
>> > [snip]
> It does - all helpful information. Thanks. Seems I need to be more
> careful about using Step Into and setting breakpoints. It's strange
> because I'm sure that I was able to step into my own constructors
> without going into the platforms loader classes.
> Still at least I know what's happening now.

What's happening is that when you are able to step into your
constructors without the loader class getting called first it's because
your class has already been loaded for a reason that's opaque to you
some other class caused it to be loaded for a less than obvious reason
and so it was already there.

Remember that Java execution isn't a sequence of machine instructions as
it is when you're stepping through an application written in C/C++. It's
virtual machine instructions being interpreted by a very intelligent
interpreter, the JVM, that does things very efficiently, loading classes
on demand, garbage-collecting, etc., stuff that's not immediately
obvious until you think really hard about it. Thinking really hard about
it rather misses the point today when we're concerned with writing code
whose only goal is to accomplish something cool. We usually no longer
have to worry, as I had to 30+ years ago in my first job, about code
size, memory overlays, resident TEXT, page faults, etc.

Life's good now!
Re: Infamous Source Not Found message debugging [message #1015810 is a reply to message #1015779] Sun, 03 March 2013 02:02 Go to previous message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
Russell Bateman wrote on Sat, 02 March 2013 12:55
On 03/02/2013 02:40 AM, bhrgunatha deva wrote:
> Russell Bateman wrote on Thu, 28 February 2013 10:12
>> On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
>> > [snip]
> It does - all helpful information. Thanks. Seems I need to be more
> careful about using Step Into and setting breakpoints. It's strange
> because I'm sure that I was able to step into my own constructors
> without going into the platforms loader classes.
> Still at least I know what's happening now.

What's happening is that when you are able to step into your
constructors without the loader class getting called first it's because
your class has already been loaded for a reason that's opaque to you

some other class caused it to be loaded for a less than obvious reason
and so it was already there.

Remember that Java execution isn't a sequence of machine instructions as
it is when you're stepping through an application written in C/C++. It's
virtual machine instructions being interpreted by a very intelligent
interpreter, the JVM, that does things very efficiently, loading classes
on demand, garbage-collecting, etc., stuff that's not immediately
obvious until you think really hard about it. Thinking really hard about
it rather misses the point today when we're concerned with writing code
whose only goal is to accomplish something cool. We usually no longer
have to worry, as I had to 30+ years ago in my first job, about code
size, memory overlays, resident TEXT, page faults, etc.

Life's good now!


Aha! That's what I was missing!

I'm still new to Eclipse so it's difficult to reason about what might cause these problems.
Thanks for your explanations.
Re: Infamous Source Not Found message debugging [message #1015814 is a reply to message #1015779] Sun, 03 March 2013 02:02 Go to previous message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
Russell Bateman wrote on Sat, 02 March 2013 12:55
> On 03/02/2013 02:40 AM, bhrgunatha deva wrote:
> > Russell Bateman wrote on Thu, 28 February 2013 10:12
> >> On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
> >> > [snip]
> > It does - all helpful information. Thanks. Seems I need to be more
> > careful about using Step Into and setting breakpoints. It's strange
> > because I'm sure that I was able to step into my own constructors
> > without going into the platforms loader classes.
> > Still at least I know what's happening now.
>
> What's happening is that when you are able to step into your
> constructors without the loader class getting called first it's because
> your class has already been loaded for a reason that's opaque to you
> some other class caused it to be loaded for a less than obvious reason
> and so it was already there.
>
> Remember that Java execution isn't a sequence of machine instructions as
> it is when you're stepping through an application written in C/C++. It's
> virtual machine instructions being interpreted by a very intelligent
> interpreter, the JVM, that does things very efficiently, loading classes
> on demand, garbage-collecting, etc., stuff that's not immediately
> obvious until you think really hard about it. Thinking really hard about
> it rather misses the point today when we're concerned with writing code
> whose only goal is to accomplish something cool. We usually no longer
> have to worry, as I had to 30+ years ago in my first job, about code
> size, memory overlays, resident TEXT, page faults, etc.
>
> Life's good now!


Aha! That's what I was missing!

I'm still new to Eclipse so it's difficult to reason about what might cause these problems.
Thanks for your explanations.
Re: Infamous Source Not Found message debugging [message #1015816 is a reply to message #1015779] Sun, 03 March 2013 02:02 Go to previous message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
Russell Bateman wrote on Sat, 02 March 2013 12:55
> On 03/02/2013 02:40 AM, bhrgunatha deva wrote:
> > Russell Bateman wrote on Thu, 28 February 2013 10:12
> >> On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
> >> > [snip]
> > It does - all helpful information. Thanks. Seems I need to be more
> > careful about using Step Into and setting breakpoints. It's strange
> > because I'm sure that I was able to step into my own constructors
> > without going into the platforms loader classes.
> > Still at least I know what's happening now.
>
> What's happening is that when you are able to step into your
> constructors without the loader class getting called first it's because
> your class has already been loaded for a reason that's opaque to you
> some other class caused it to be loaded for a less than obvious reason
> and so it was already there.
>
> Remember that Java execution isn't a sequence of machine instructions as
> it is when you're stepping through an application written in C/C++. It's
> virtual machine instructions being interpreted by a very intelligent
> interpreter, the JVM, that does things very efficiently, loading classes
> on demand, garbage-collecting, etc., stuff that's not immediately
> obvious until you think really hard about it. Thinking really hard about
> it rather misses the point today when we're concerned with writing code
> whose only goal is to accomplish something cool. We usually no longer
> have to worry, as I had to 30+ years ago in my first job, about code
> size, memory overlays, resident TEXT, page faults, etc.
>
> Life's good now!


Aha! That's what I was missing!

I'm still new to Eclipse so it's difficult to reason about what might cause these problems.
Thanks for your explanations.
Re: Infamous Source Not Found message debugging [message #1015818 is a reply to message #1015779] Sun, 03 March 2013 02:02 Go to previous message
bhrgunatha deva is currently offline bhrgunatha deva
Messages: 7
Registered: February 2013
Junior Member
Russell Bateman wrote on Sat, 02 March 2013 12:55
> On 03/02/2013 02:40 AM, bhrgunatha deva wrote:
> > Russell Bateman wrote on Thu, 28 February 2013 10:12
> >> On 2/28/2013 5:04 AM, bhrgunatha deva wrote:
> >> > [snip]
> > It does - all helpful information. Thanks. Seems I need to be more
> > careful about using Step Into and setting breakpoints. It's strange
> > because I'm sure that I was able to step into my own constructors
> > without going into the platforms loader classes.
> > Still at least I know what's happening now.
>
> What's happening is that when you are able to step into your
> constructors without the loader class getting called first it's because
> your class has already been loaded for a reason that's opaque to you
> some other class caused it to be loaded for a less than obvious reason
> and so it was already there.
>
> Remember that Java execution isn't a sequence of machine instructions as
> it is when you're stepping through an application written in C/C++. It's
> virtual machine instructions being interpreted by a very intelligent
> interpreter, the JVM, that does things very efficiently, loading classes
> on demand, garbage-collecting, etc., stuff that's not immediately
> obvious until you think really hard about it. Thinking really hard about
> it rather misses the point today when we're concerned with writing code
> whose only goal is to accomplish something cool. We usually no longer
> have to worry, as I had to 30+ years ago in my first job, about code
> size, memory overlays, resident TEXT, page faults, etc.
>
> Life's good now!


Aha! That's what I was missing!

I'm still new to Eclipse so it's difficult to reason about what might cause these problems.
Thanks for your explanations.
Previous Topic:diffrance between VARIABLE and EXPRESSION
Next Topic:Problem extracting Eclipse RCP Juno SR2 Win32
Goto Forum:
  


Current Time: Mon Jul 28 18:35:22 EDT 2014

Powered by FUDForum. Page generated in 0.01967 seconds