Skip to content
Levi Webb edited this page Nov 2, 2015 · 10 revisions

Consoles is a massive project, and further more the consoles-computers plugin adds so much functionality that I cannot possibly test everything when I push out new builds.

So, if you run into an issue, you should collect all the information you can and create an issue.

###Exceptions

If one of the plugins throws an exception, you should report it (and what you did to cause it). Keep in mind the consoles-computers debug mode also allows you to see internal exceptions that happen in Lua programs, most of which are likely caused by misusing an internal function or a runtime error, so try not to falsely report those.

###Unintended Behaviour

This involves issues with calling certain Lua functions and working with certain types, working with the core Java API, or anything else that is not working the way you think it should be, report it with lots of information.

###JVM Crashes (Linux)

consoles-computers is special, since a portion of the code is run outside of the JVM. You can run into much more severe exceptions because of this, notably segmentation faults (SIGSEGV) - causing your entire JVM to crash. There are three things you can do to help me fix these issues:

  • Debug the application with GDB. You can actually do this by enabling debug-hook and changing debug-command to your liking, the default command will open a new terminal with a GDB session attached. If you are on a server with no X environment, then you will probably will want to change it to use screen or some other terminal multiplexer. Once you are attached, you should:

    • type cont to make the server resume (GDB automatically halts the application upon attaching)

    • do whatever you normally do to cause the server to crash

    • when the server crashes, GDB will catch it and halt the application again. Type bt to get a backtrace, then submit an issue with the contents of your backtrace, and everything you did to cause it.

  • Run the server with -Xcheck:jni. This will cause your JVM to check for issues with JNI calls, and will throw an exception if it finds an issue (and will likely send a SIGABRT). While the stack trace is generally unhelpful (it will only trace up to a native method call), the type and message from the exception can be.

  • Provide a core dump (the JVM will produce one). The location of a core dump after a crash entirely depends on your platform. Most linux distributions actually have some system for handling application crashes and core dumps (like Ubuntu), so you may actually have to change some settings to produce and find core dumps.

Providing all of the above is a sure way to get the issue fixed.

JVM Crashes (Windows/OSX)

If you are running into JVM crashes on another platform (there are some consoles-computers builds for other platforms), revert to using the luaj interpreter instead of luajit or lua. Issues with the native layer for non-linux platforms will be closed.