Jikes FAQ Links
Something wrong or missing?
So you think you've found a bug?
Well, ya know what... we're all just human, and compilers for any language are very difficult beasties to write so you may very well have done just that. Here's what we need you to do in order to correct this problem, without your help the odds of this bug being fixed are infinitesimally small.
Overview of process from here:
Verify that this isn't a WKB
Anytime we have a brown paper bag incident it will be listed here, if your bug is listed here and you still report it, expect to be ignored unless you have some new information; in which case you should append your information to the existing bug. (Please don't append "me too, you should fix this" type of messages.) Current status is indicated thusly.
If your bug wasn't listed above, move on to the next check.
Verify that this is in fact a Jikes bug
This is basically a sanity check, and a chance for you to prevent embarrassment. Some things to check:
If you're still seeing this as a bug in Jikes, move on to the next check.
Check that this bug is not already reported
Like I said, we're all human and compilers are inherently difficult pieces of code. As a result there are bugs in Jikes, to say otherwise would be a lie. A fair number of bugs have already been identified and are in the Jikes Bug Collection. The purpose of this step is to take a look at some of the existing bugs and see if yours is a duplicate of one of these already existing bugs. The bugs in the collection are generally divided into the following categories, you should read the description of each and decide which your bug belongs in (maybe two, but probably not three or more). Once you've decided then take the link with each and skim the list of bugs returned, you may need to read the details of a bug before determining if it is yours or not.
If you do find your bug in one of the above categories already then you should evaluate if you have any additional information you can add to the existing bug, such as a simpler testcase, or a backtrace of a core fault or assertion. See the next section for some of the common information we need to properly deal with a bug, if the original report doesn't contain some of that info, can you supply it? If so please append it to the existing bug. If, on the other hand, you do not see your bug in any of the existing ones, please continue to the next step and collect the information needed for your new bug.
Collect the information needed for a Jikes bug report
There are some basic pieces of information that are needed for a bug report, surprisingly a number of bugs come it that lack this basic information. I say this is surprising because of the target audience of the project... developers. You're a Java developer right, how would you like a defect from your users that just says: "it dumped core, you should fix it"?
All bug reports must include the following basic information:
Gathering useful information after a crash
If Jikes crashes, it's best if you can provide a small test case that repeatably causes Jikes to crash. Doing this gives you the best chance of having the bug fixed.
If you can't come up with a small repeatable test case, we'll want a stack trace. When a C++ program such as Jikes crashes, you don't automatically get a stack trace as you would with Java. Here are the steps for collecting a stack trace:
You can use the information from steps 6 and 7 to look at the existing bugs for any similar ones, or open a new one. Sometimes knowing where it died will help in writing a smaller test case that you can post in your bug report. Looking at the stack traces can also help you recognize if you're hitting the same problem over and over, or if you keep finding new ones (and crashing in very different places).
Report the bug
This is the easy part. Just go to the submission page
and put all the information above into the form in some nice coherent fashion. The first thing you'll need to supply is your email
address, be sure to put a VALID address, you'll also need to decide if you want this address to be publicly visible on this bug.
Reference the IBM Privacy Guidelines at the bottom of that page for details, but the general gist of this switch is that the dW staff,
and (in theory) the Jikes project administraitors and registered developers will be able to see your address either way (although this
is currently broken such that only the deverloperWorks staff can retrieve all addresses) but the general public will ONLY be
able to see your address if you check the box. Note that this is the address where the system will mail updates about the status of
your bug as it changes. The next option you need to provide is what category your bug belongs in. Reference the set of categories
above for details, or leave it as
After you click submit there is one last very important step you'll have to do: confirm your address. A message will be sent to your email address which contains a URL... until you visit that URL your bug will NOT be seen, you must visit the URL that is sent to you in order to confirm your address is valid.
Assist in the elimination of the bug
Having reported the bug many people think that their job is finished, ideally this maybe the case, but out here in the real world it never is. As developers and other users are working on your bug they may need information, they'll post questions, or suggestions to work around the bug into it's record in the database. If we never hear from you again then odds are very good that the bug will never move forward. You have got to stick around a help with the debug process.
Verify the bug has been fixed
The last step. By now the bug has been cornerd and eradicated, a patch has been developed, and commited, possibly even shipped. This last step is the most important from your end... verify that the fix works on your machine, with your project in your environment. This can be especially important with bugs where you had to reduce any enviroment of input inorder to produce a testcase. Once a bug is verified as fixed either in a cvs build or in an official production release.