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.
Also, review the Rules & Guidelines to ensure you are posting a valid bug.
- "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.
- 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
A new bug submission form opens....
3) Filling out report items
Now fill out each item as applicable. Items with * are necessary fields.
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.
This is to be set at ALWAYS, unless it's a randomly occuring or intermittent (sometimes) bug.
Based on the category selected, your bugs are given certain severity levels. Check this page for descriptions of options.
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.
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.
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.
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.
Describes what kind of MAME build was used for testing.
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".
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
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.
- 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.
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
- 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.
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
|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
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.
- Create a clean compile of Mame with symbols turned on in the Makefile
- Download / Install GDB to your mingw directory if it isn't already there (I think its in the big mingw package tho)
- go to your mame directory and at the command prompt type
then in gdb
run gamename -window
(window is important or you may not be able to get back to the debugger)
- play the game until it crashes, it should pause rather than exiting mame.
- look at the gdb window, there should be something sort of sigsev type message there
- 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
Close This Window