-
Notifications
You must be signed in to change notification settings - Fork 8
Reporting Bugs
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 changingdebug-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 usescreen
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 anative
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.
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.