0

As I'm currently ironing out the creases of my knowledge with Libgdx, Before I start a project, I feel like I should know how to debug specific 'standard' run time errors whilst debugging Android application(s). It would save me a-lot of time pondering on why my application doesn't seem to run when loading the game. The documentation is very scattered as for most Open-Source projects, but every coin has two sides; where Libgdx bathes in freedom of development, it lacks in documentation. The aim of this post is to answer the very simple, but beneficial question.

How do I debug my Libgdx Project in Eclipse?

BradleyIW
  • 1,338
  • 2
  • 20
  • 37

1 Answers1

0

The answer to some may be very simple, but to others not so much but highly necessary. I'm using Libgdx 1.5.5 and Eclipse 4.4 (Luna) for this.

When you're in eclipse and your application crashes, you'll want to go over and jump into Debug perspective.

Window > Open Perspective > Debug

Once there with a few simple clicks you should be able to get some information about the error you've found, the next time you run it. See image below:

enter image description here

In my case, I've purposely used an old packed texture without the frames for one animation, so I know i'd get a NullPointerException. This is a very common error and a good example to start with.

Libgdx Android - GL Thread (NullPointerException) & Missing Class File

Lets further break down the image:

  1. This is where you can analyze the threads and see how they're running when the application is going. It's essentially a timeline of the interactions the threads make throughout the application. you can use this look for leaks and better to spot which thread your error occurs on, in the image it shows an error has been caught on the GL Thread. NullPointerException (as mentioned above).

    if you wish to look deeper into the APIs way of threading, have a look here.

  2. This is where you'll be setting up your breakpoints, as you can see already from the image I've got mine setup. This just shows you what area you'll be looking for in regards to the exceptions, in this case you'll be adding breakpoints to the GdxRuntimeException, this allows the system to stop debugging and display the problem when they catch an exception from the GdxRuntime family.

    more on breakpoints here.

    3: http://www.vogella.com/tutorials/EclipseDebugging/article.html

    In order to set these up you'll need to click on the button right next to the 2 area of the image it looks almost like J! and when hovered over it'll say "add Java Exception Breakpoint", click on that and then 3 will pop up.

  3. This is the dialog box thats opens when you add a new Java Exception breakpoint, there will be numerous options and a search bar, time in Gdx into the search bar and you'll find GdxRuntimeException, click on that, click ok. Now you have a breakpoint set for the 'standard' Gdx runtime exceptions. It'll make it alot easier to find errors in your code.

  4. Logcat: The final clue in the puzzle to finding out where the error is. This is Logcat, this will log any errors coming from the Android device, I normally filter the errors tab and concentrate on the red. You'll need to spend a little time getting to know what are 'common' errors and what are actual errors. Then you should be able to work out what the error is. Obviously, fixing things is always trial and error [pun intended].

    The logcat tells me that theres something wrong the Libgdx library that imports the TextureRegion and using that information with the threads we can see that somewhere a texture region is being passed over with a null value, with a bit of luck you'll be able to go straight to your Assets manager and get it sorted.

Note: In the top left corner of the image, you'll notice how you can change perspectives (not sure how updated this in regards to what version of Eclipse has it) but it comes in very handy when you're doing the trial and error.

Community
  • 1
  • 1
BradleyIW
  • 1,338
  • 2
  • 20
  • 37