Tutorial - Posting a New Bug

Written by Fujix, Tafoid. September 18, 2014

This page explains how to post a new bug on MAME Testers.

1) Before you post

Before you post a new bug, please check the following:

• Is the bug already posted?
  Use the View & Search page and in the field marked "Search: ", you first start with the setname of the game you are going to report about. If you find nothing, be sure to also search using the MAME source driver.c of that set. For example, you have a bug you want report for the game XEVIOUS. First you search, xevious. After that, check the driver galaga.c. If you don't find any of the bugs mentioning anything to do with what you have, proceed to entering your bug.
  
• Check MAME's warning screen.
  When you start MAME, if there is a problem with a particular set, you will be given a screen which lists the problems out that you must type "OK" to. Based on the message(s), posting a new bug is not desired.
  
  • "THIS GAME DOES NOT WORK PROPERLY" - Do not submit ANY bugs except heavy regression.
  • "THE SOUND EMULATION IS NOT 100% ACCURATE" - Do not submit sound bugs except heavy regression.
  • "THE VIDEO EMULATION IS NOT 100% ACCURATE" - Do not submit video bugs except heavy regression.
  • "THIS GAME LACKS SOUND" - Do not submit sound bugs.
  Also, review the Rules & Guidelines to ensure you are posting a valid bug.
• Check MAME Frequent Asked Questions.
  If you are a rather new tester who is not familiar with various circumstances of MAME and testing, you should refer the official MAME FAQ. It covers any and every kind of questions and answers, such as setup, ROMs, features, controls, video, audio, performance, game-specific problems, tools etc. It is guaranteed that the page will help you to form comprehensive background for MAME and its testing.

2) Opening bug submit form

Open the drop down list and select "New MAME bug" if you wish to submit a MAME bug, select "New MESS bug" for MESS-specific bug. If your bug report is common both in MAME and MESS field, please select "New MAME bug". A new bug submission form opens....

3) Filling out report items

Now fill out each item as applicable. Items with * are necessary fields.

• Category*
  This is where you classify your bug as to it's type. This is the primary criteria used in sorting all bugs. Please check the Legend and attributes page for specific details.
• Reproducibility
  This is to be set at ALWAYS, unless it's a randomly occuring or intermittent (sometimes) bug.
• Severity
  Based on the category selected, your bugs are given certain severity levels. Check this page for descriptions of options.
• Version*
  Select the version number of MAME you used for testing, NOT the version where you find the bug first. Please be sure to use the latest version as far as possible to avoid duplicating an already-fixed bug report. If you are compelled to use a previous version, please mention it in your report.
• Driver
  Specifies the driver source name that the game belongs to. If multiple drivers are affected, please leave this field blank. You can look up driver name at the ProgettoEMMA database. If you are familiar with a command prompt, use the "-listsource" option.
• Affected Sets / System
  For MAME bug reports, specifies the target game's ZIP name. And for MESS, write down the system name rather than signle game zips. This will appear in the head of the summary text and be used for reference of the bug throughout MANTIS.
• Platform
  Describes what kind of MAME binary was used for testing. We accept bugs from SDLMAME or MAMEUI, but they have to be re-confirmed with the official MAME binary to be authentic bug reports.
• OS
  Describes what kind of OS was used for testing. This is important especially when you use a 64-bit OS such as Windows 7/Vista/XP 64-bit because some bugs come up only on a 64-bit OS. Windows 98 and Me are not supported by MAME anymore, and they may cause an OS-specific problem. Please do not use them for testing.
• Build
  Describes what kind of MAME build was used for testing.
• Summary*
  A brief description of the bug. This text will be used in various places to refer to the bug, so make it specific and pithy. It is NOT PROPER to writing only "Crash" or "Incorrect boss behaviour" or "Graphic is bad" or "The game has a problem". Please add WHEN, HOW and WHERE at least, like "MAME Crash on Startup" or "The boss in the second stage moves incorrectly".
• Description*
  Main description of the bug. Take your time and please state what is exactly wrong, when it happens and how it should react. You can embed a YouTube and LiveVideo movie clip by pasting embedding code provided by respective service. Supported html tags are <b>, <i>, <b>, <strike>, <u>, <ol>, <ul>, <li>, <dd>, <dl>, <pre> and <blockquote>. You can keep tab indent of source code and screen output with the <pre> tag. Also use <blockquote> to quote text.
• Step to Reproduce
  This is an optional field to detail steps to reproduce a bug. If it is too obvious to describe (For Example: "Just run the game" or "See the attract mode"), you can leave this blank. When it is not easy or it takes long time to reach the point of a bug, please consider adding a save state for ease of confirmation (See below for adding a file). No one will look into a bug like "The final boss after 99 stages without continue has a problem infrequently."
• Additional Information
  This is the postscript of the bug. Useful observations regarding the bug as well as noting related problems from other bugs might be helpful in determining it's cause.
• Flag
  
  • 64-bit specific
    Check this if the bug is confirmed only on 64-bit operating system..
  • Debug build specific
    If you are running a Debug build (not to be confused with the debugger (-debug) in a normal build), check this flag.
  • Possible
    This flag is for bugs which you do not have any direct proof of being a bug.. but the behaviour is unexpected. In general, reports with this label require an original reference from the PCB.
  • Verified with PCB
    Check this if you confirmed the bug with original materials derived from the original cabinet or PCB (schematics, technical documents, original soundtrack).
  • Noted in Source
    Check this if the bug being added is either mentioned or alluded to in the driver source file.
  • Verified with Code
    Check this if, after a direct examination of the game's assembly, you note the behavior, for sure, is supposed to happen a certain way and that this bug report explains the difference between what is being shown in emulation and the actual case of output from an original game PCB.
• File Upload
  You can add file related to the bug. If you wish to add multiple files, please submit the report and reopen it. Extensions for images that can be expanded inline are png, gif, jpg and jpeg. Extensions for text files that can be expanded inline are txt, diff, patch, c, h, dif, ini and cfg. Please compress save states (.sta), input files (.inp) or any other large files before you add them as they can be compressed to small size.
• View Status
  The default view status is always Public.

4) Submitting

Click the "Submit Report" button and the report will be assigned a number and added to the bug list. Please confirm that your submission is correctly listed in the View & Search page. The initial state of bug report is always New. The paper clip icon means that the report has attached files. Congratulations! Your bug submission has been completed.

5) What's next?

Your report will be checked by other Testers, Developers and Moderators for validity, reproducibility and regression version if necessary. When the report is confirmed as a proper bug, Status will be changed to Confirmed and will wait for a Developer to claim or fix it.

If a Developer wishes to address the bug, he can assign himself to it. In this case, the status will become Assigned. Please remember that this is an optional status, so not all bugs are assigned to someone before they are fixed.

Some reports may need more proof and inspection to make a final determination. These bugs are set as Acknowledged.

When a Resolution is taken, the status will be changed to Resolved. This is a list of possible resolutions:

• Open - No resolution is taken yet. The default value.
• Fixed - The bug has been fixed.
• Reopened - The bug is again present or was never fixed.
• Unable to reproduce - Testers were unable to confirm the bug.
• Not fixable - A bug which "cannot be fixed" according to Developers.
• Duplicate - A bug which has already been entered and dealt with.
• Suspended - Reserved for completely invalid and unconfirmed reports.
• Won't fix - Developers, for whatever reason, will not fix this bug.

If the report is invalid (unreproducable, not a MAME bug etc.), the status will be Closed. You can't add comment to Closed bugs.

Recapitulating the status:

Value	Description
New	Comprehensive testing/validiation has not been done yet.
Direction Needed	Situation is deadlocked. Requires official position of Dev Team to be handled.
Acknowledged	Has been processed and some testing has been done, but there has been no final determination made as to it's status.
Confirmed	Another tester or moderator has determined the bug to be valid.
Assigned	Has been assigned to a Developer who is willing to research/correct the bug.
Resolved	A Bug which has been either Fixed, Won't be fixed or is a BTANB.
Closed	Bugs which have been Invalidated, Duplicated, Suspended or Unable to be reproduced.

Note: Some of them have different meaning in MAME Testers from the original Mantis system.

6) Editing own report

You can edit/fix/update your own report after you submit it. Click the "Edit Report" button in the bug view page to open the edit form.

7) Monitoring report

You can monitor a bug report to know updates. Please click the "Monitor Report" button in the bug view page to start monitoring it. When you are monitoring a bug report and the status of the bug is changed or someone adds a note, you should receive a notification e-mail. Click the same button to end monitoring. You can control what event you will receive an e-mail notification on the preference page. Follow Account Setting → Preferences and check the check boxes you want to receive e-mails. If none of boxes are checked, you won't receive any notifications even if you are monitoring a bug.

8) Producing more useful crash reports...

sometimes people report crash bugs here and I'm unable to reproduce them myself.
If a game is crashing it would be useful for us if you did the following.

1. Create a clean compile of Mame with symbols turned on in the Makefile
2. Download / Install GDB to your mingw directory if it isn't already there (I think its in the big mingw package tho)
3. go to your mame directory and at the command prompt type
   

   gdb mame

   then in gdb

   run gamename -window

   (window is important or you may not be able to get back to the debugger)
4. play the game until it crashes, it should pause rather than exiting mame.
5. look at the gdb window, there should be something sort of sigsev type message there
6. type 'bt' to get a backtrace to see where it crashed
   copy the details from this window and post them ...

by following this procedure its easier for us to understand where something is crashing ... and if you're good at getting something to crash then theres more chance we'll be able to fix it (for example I wasn't able to get ssf2x to crash under gdb, and the one time it did it gave no meaningful output... so I'm unable to get any idea of where the bug is)

Close This Window

---