search

mamedev / mame

MAME
https://www.mamedev.org/
Other
8.43k stars 2.04k forks source link

Final Tetris Corruption, possible regression #3004

Closed katananja closed 6 years ago

katananja commented 6 years ago

mame0193-265-gd4f4673045-dirty Debian Linux 9 snowbros.cpp, finalttr It was fine with 0.193.

0001

Tafoid commented 6 years ago

MAME v0.193 (mame0193-261-g590872f2a0) clean build in AM both 32 and 64-bit works fine, MAME v0.193 (mame0193-270-g4afcdbcda3-dirty) just updated build 32 and 64-bit works fine. gcc 7.2.0 - Windows 7 0000

ghost commented 6 years ago

can't confirm.

if you're still messing around with custom compile options before reporting bugs, please stop doing that.

katananja commented 6 years ago

Define "custom compile", I'm doing nothing the settings don't allow it. I ALWAYS compile mame with:

Windows make REGENIE=1 TARGETOS=windows CROSS_BUILD=1 DEBUG=1 SYMBOLS=1 SYMLEVEL=1 STRIP_SYMBOLS=1 PTR64=1 OPTIMIZE=3 SSE2=1 OPT_FLAGS="-march=native -mtune=native -funroll-loops -m64" -j8

Linux make REGENIE=1 DEBUG=1 SYMBOLS=1 SYMLEVEL=1 STRIP_SYMBOLS=1 PTR64=1 OPTIMIZE=3 SSE2=1 OPT_FLAGS="-march=native -mtune=native -funroll-loops -m64" -j8 This is the EXACT same settings used to compile the clean, final source. Tested with -video accel, soft, opengl and bgfx

Using gdb this is shown: [:screen] :screen: Deprecated legacy Old Style screen configured (MCFG_SCREEN_VBLANK_TIME), please use MCFG_SCREEN_RAW_PARAMS instead.

Still happens with mame0193-265-gd4f4673045-dirty

Robbbert commented 6 years ago

Works perfectly fine here, GCC 5.3.0, 32-bit, latest git, Windows 7.

That gdb message is irrelevant and should be ignored.

Maybe someone with your particular version of Linux will be able to report.

katananja commented 6 years ago

Still happens with GCC 6.3.0 20170516 (Debian 6.3.0-18) and lastest git.

cuavas commented 6 years ago

We don't support the use of -mtune options as it tends to trigger bugs in GCC's optimiser.

katananja commented 6 years ago

Understood. But this doesn't fix the issue @cuavas.

katananja commented 6 years ago

mame0193-274-ga8308ca31c-dirty make DEBUG=1 SYMBOLS=1 SYMLEVEL=1 STRIP_SYMBOLS=1 -j8

Bug still valid and is not caused by GCC optimization.

cuavas commented 6 years ago

Did you remove the build directory in between to ensure it rebuilt properly? Do you have anything setting CFLAGS or other variables that affect the build in your environment? The trouble is, no-one else has reproduced this, so you need to isolate what it is or provide better steps to reproduce it.

rb6502 commented 6 years ago

I can't reproduce this on either Fedora 27 (GCC) or macOS 10.12.6 (Clang). If there are steps other than just "boot the game and see a bad title screen" it would be helpful to include them.

katananja commented 6 years ago

The only step I've found is to run mame inside gbd with debug, this causes the graphics become finalttr normal.

  1. gbd mame64d 
    gdb mame64d
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mame64d...done.
  2. run the game with debug 
    
>>> run -debug finalttr
Available videodrivers: x11 wayland dummy 
Current Videodriver: x11
Display #0
    Renderdrivers:
            opengl (0x0)
         opengles2 (0x0)
          software (0x0)
Available audio drivers: 
pulseaudio          
alsa                
sndio               
dsp                 
disk                
dummy               
Build version:      0.193 (mame0193-274-ga8308ca31c-dirty)
Build architecure:  
Build defines 1:    SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1 
Build defines 1:    LSB_FIRST=1 PTR64=1 MAME_DEBUG=1 
SDL/OpenGL defines: SDL_COMPILEDVERSION=2005 USE_OPENGL=1 
Compiler defines A: __GNUC__=6 __GNUC_MINOR__=3 __GNUC_PATCHLEVEL__=0 __VERSION__="6.3.0 20170516" 
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1 
Compiler defines C: __USE_FORTIFY_LEVEL=0 
Enter init_monitors
Adding monitor screen0 (1920 x 1080)
Leave init_monitors
Enter sdlwindow_init
Using SDL multi-window OpenGL driver (SDL 2.0+)

Hints: SDL_FRAMEBUFFER_ACCELERATION (null) SDL_RENDER_DRIVER (null) SDL_RENDER_OPENGL_SHADERS (null) SDL_RENDER_SCALE_QUALITY (null) SDL_RENDER_VSYNC (null) SDL_VIDEO_X11_XVIDMODE (null) SDL_VIDEO_X11_XINERAMA (null) SDL_VIDEO_X11_XRANDR (null) SDL_GRAB_KEYBOARD (null) SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS (null) SDL_IOS_IDLE_TIMER_DISABLED (null) SDL_IOS_ORIENTATIONS (null) SDL_XINPUT_ENABLED (null) SDL_GAMECONTROLLERCONFIG (null) SDL_JOYSTICK_ALLOW_BACKGROUND_EVENTS (null) SDL_ALLOW_TOPMOST (null) SDL_TIMER_RESOLUTION (null) SDL_RENDER_DIRECT3D_THREADSAFE (null) SDL_VIDEO_ALLOW_SCREENSAVER (null) SDL_ACCELEROMETER_AS_JOYSTICK (null) SDL_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK (null) ─── Output/messages ──────────────────────────────────────────────────────────── Audio: frequency: 48000, channels: 2, samples: 256 sdl_create_buffers: creating stream buffer of 25600 bytes Audio: End initialization Debug Build: Disabling input grab for -debug Keyboard: Start initialization ─── Output/messages ──────────────────────────────────────────────────────────── [MAME]> Region ':maincpu' created unzip: opened archive file /Mame/roms/finalttr.zip unzip: found /Mame/roms/finalttr.zip ECD unzip: /Mame/roms/finalttr.zip has no ZIP64 ECD locator unzip: read /Mame/roms/finalttr.zip central directory unzip: closing archive file /Mame/roms/finalttr.zip and sending to cache unzip: found /Mame/roms/finalttr.zip in cache unzip: opened archive file /Mame/roms/finalttr.zip unzip: closing archive file /Mame/roms/finalttr.zip and sending to cache Region ':soundcpu' created unzip: found /Mame/roms/finalttr.zip in cache unzip: opened archive file /Mame/roms/finalttr.zip unzip: closing archive file /Mame/roms/finalttr.zip and sending to cache Region ':cpu2' created unzip: found /Mame/roms/finalttr.zip in cache unzip: opened archive file /Mame/roms/finalttr.zip unzip: closing archive file /Mame/roms/finalttr.zip and sending to cache Region ':user1' created unzip: found /Mame/roms/finalttr.zip in cache unzip: opened archive file /Mame/roms/finalttr.zip unzip: closing archive file /Mame/roms/finalttr.zip and sending to cache Region ':oki' created unzip: found /Mame/roms/finalttr.zip in cache ─── Output/messages ──────────────────────────────────────────────────────────── Optional shared pointer ':spriteram16b' not found Optional memory region ':palette:finder_dummy_tag' not found Starting Final Tetris ':' (missing dependencies; rescheduling) Starting M68000 ':maincpu' Starting Timer ':scantimer' Starting Watchdog Timer ':watchdog' Starting Z80 ':soundcpu' Starting Video Screen ':screen' (missing dependencies; rescheduling) Starting gfxdecode ':gfxdecode' Starting palette ':palette' Starting Kaneko PANDORA GFX ':pandora' (missing dependencies; rescheduling) Starting Speaker ':mono' (missing dependencies; rescheduling) Starting Generic 8-bit latch ':soundlatch' Starting Yamaha YM2151 OPM ':ymsnd' Starting OKI MSM6295 ADPCM ':oki' Starting Final Tetris ':' (missing dependencies; rescheduling) Starting Video Screen ':screen' [:screen] :screen: Deprecated legacy Old Style screen configured (MCFG_SCREEN_VBLANK_TIME), please use MCFG_SCREEN_RAW_PARAMS instead. Starting Kaneko PANDORA GFX ':pandora' Starting Speaker ':mono' Starting Final Tetris ':' un7z: opened archive file cheat.7z un7z: closing archive file cheat.7z and sending to cache Loading cheats file from cheat un7z: found cheat.7z in cache un7z: closing archive file cheat.7z and sending to cache Attempting to parse: default.cfg Attempting to parse: finalttr.cfg Soft reset GL texture: copy 1, shader 0, dynamic 1, 256x224 256x224 [PALETTE16, Equal: 0, Palette: 1, scale 1x1, border 0, pitch 256,256/16384], bytes/pix 4

MAME debugger version 0.193 (mame0193-274-ga8308ca31c-dirty) Currently targeting finalttr (Final Tetris)

katananja commented 6 years ago

If there is something else I can do, please advise. I don't want to go over this all over again when I report something and @cuavas - by guessing - close my ticket, assume it was my fault and it wasn't.

JoakimLarsson commented 6 years ago

No one said it was your fault. The custom build command used a switch known to cause problems and none seems to be able to reproduce it. I think you should attach you build command with switches to all your reports so people don't have to waste time trying to reproduce your problem with the wrong switches.

Did you delete your build catalog and rebuild the whole thing using only standard switches? Did you add any other switches before loading it in GDB? Sometimes compilers disables optimization when doing debug builds because the debugger can't cope with the optimized code. Did you try the binary that you loaded into GDB standalone? If the problem still exists after these checks it sounds like uninitialized data and can be very hard to reproduce as it is random.

katananja commented 6 years ago

Thanks Joakim, I know no one said it's my fault but @cuavas is well known to do this stuff and it's not the first time, nobody likes to waste time, do you think I have time to spare or like to fill a report and deal with people with an ego? I don't know what @cuavas think, but this is not free, I'm using my time, my electricity, my internet and my money every single time I've to compile something and fill in a report. And I do it because I want to learn this, and I will, you can bet on it! So I'm willing to pay the price for it and I'll stand my ground unless proven otherwise.

I not only deleted the whole catalog but got a fresh copy from git, witch means I've deleted everything and got a new copy, just to make sure I know how to delete a catalog right.

My build command is this and nothing else, not even SSE2: make REGENIE=1 DEBUG=1 SYMBOLS=1 SYMLEVEL=1 -j8

Yes, I've used the same binary with gdb and the problem persist with different -video options, with the right directions I cant look in to this uninitialized data and make a report about it since it is happening on my side.

Thank you.

JoakimLarsson commented 6 years ago

We all are in the same position so I think you should not be so harsh about people not working on your problems because unless you can show that it is a generic problem people end up working for you and not for the project. It is up to you if you want to do that or not of course but you can't expect people to drop their projects and start guessing what caused your problems.

So it is good to have solid facts on the table in the first post and not complain about the time you spend on MAME, because we all are and it will only make people annoyed and ignore your issues, imho

katananja commented 6 years ago

Joakim, A software bug is not my problem at all, financially, I gain nothing with this, I don't even use my real name to use the project as a platform, I'm really not here for this. What I gain from it is knowledge, when it got fixed I learn. I'm doing this for the project, if it will be fixed now or latter I'll learn it one way or the other.

My day job is related with quality control and I have a neck for it, the project need people to develop and also need people that keep poking the code until it find a weakness or problem, our goal is the same, it's not to annoy people but to make the project stable as possible.

I'm never harsh with people around here or anywhere, I don't push my reports up or tell people to fix my reports "right away". My main issue is with @cuavas because he is a prejudice person, it got to a point that I had to ask for a administrator to deal with it, me and other MAME members tried to contact him before it got to this point be he think he is better than everybody else, this is not just with me, you can look at the commits he does and how he comments when someone don't use tabs, or use spaces, or does something he doesn't agree upon.

This ticket is a perfect example, why close it so fast? Why not wait some one else outside Windows run some tests, or wait for me to read his reply, compile a new version without -mtune or whatever? Or at least give 48 Hrs to respond, you know, people has to work, we live in a different time zone, etc. Developers also has to do his things before it can look at it.

Instead @cuavas decide that the issue is "mtune" and without any further discussions, close the ticket before 24 Hrs??

Don't get me wrong, I make mistakes, I have no problems to accept then and to apologize when it's necessary. I can provide any solid evidence that something happen between the final 0.193 and the latest git, the machine works 100% in 0.193 compiled here and still broken with the latest git.

If there is something I can do I do it, but I will stand my ground and don't agree with the position @cuavas gave to close the ticket, this is not my fault, something broke after 0.193.

bmcphail commented 6 years ago

If you're asking for advice on how to make better reports (I think you are) why not debug it a little first. So for example you posted a divide by zero error and listed this line:

result = s64(result - m_joystick_deadzone) * s64(INPUT_ABSOLUTE_MAX) / s64(m_joystick_saturation - m_joystick_deadzone);

So sure - if saturation and deadzone are the same value or are 0 themselves

For the bad graphics - you can see it's a palette problem in some way - go in and alter the palette code as a hack - force every pen to be blue for example (by patching palette_device write()). Does blue show up or it that corrupt too? Or check in the F4 graphics viewer - are colors wrong there also? If yes, then it's probably not an emulator code bug, but a display bug, perhaps even in OpenGL or your graphics driver.

As someone who has shipped a commercial game on Linux I don't mind saying all Linux OpenGL/graphics drivers are buggy pieces of crap so all bets are off :)

On Thu, Jan 4, 2018 at 2:52 PM, Wellington Uemura notifications@github.com wrote:

Joakim, A software bug is not my problem at all, financially, I gain nothing with this, I don't even use my real name to use the project as a platform, I'm really not here for this. What I gain from it is knowledge, when it got fixed I learn. I'm doing this for the project, if it will be fixed now or latter I'll learn it one way or the other.

My day job is related with quality control and I have a neck for it, the project need people to develop and also need people that keep poking the code until it find a weakness or problem, our goal is the same, it's not to annoy people but to make the project stable as possible.

I'm never harsh with people around here or anywhere, I don't push my reports up or tell people to fix my reports "right away". My main issue is with @cuavas https://github.com/cuavas because he is a prejudice person, it got to a point that I had to ask for a administrator to deal with it, me and other MAME members tried to contact him before it got to this point be he think he is better than everybody else, this is not just with me, you can look at the commits he does and how he comments when someone don't use tabs, or use spaces, or does something he doesn't agree upon.

This ticket is a perfect example, why close it so fast? Why not wait some one else outside Windows run some tests, or wait for me to read his reply, compile a new version without -mtune or whatever? Or at least give 48 Hrs to respond, you know, people has to work, we live in a different time zone, etc. Developers also has to do his things before it can look at it.

Instead @cuavas https://github.com/cuavas decide that the issue is "mtune" and without any further discussions, close the ticket before 24 Hrs??

Don't get me wrong, I make mistakes, I have no problems to accept then and to apologize when it's necessary. I can provide any solid evidence that something happen between the final 0.193 and the latest git, the machine works 100% in 0.193 compiled here and still broken with the latest git.

If there is something I can do I do it, but I will stand my ground and don't agree with the position @cuavas https://github.com/cuavas gave to close the ticket, this is not my fault, something broke after 0.193.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/3004#issuecomment-355381596, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzGnm-j_OjKC9UystGB7cG8COV_29ynks5tHSwLgaJpZM4RSYhV .

katananja commented 6 years ago

Thank you bmcphail!!!! I'll do that.

Thank you for helping out.

vadosnaprimer commented 6 years ago

I can provide any solid evidence that something happen between the final 0.193 and the latest git, the machine works 100% in 0.193 compiled here and still broken with the latest git.

Why don't you try the thing that requires no programming skills or social interaction - bisect? As long as you can invest a bit of time into compiling a few revisions, it's easy to do and yields solid results that can be reported directly, so that afterwards everybody knows what part to inspect. Or you could reapply parts of the commit that breaks it and learn what exact change is to blame.

rb6502 commented 6 years ago

To be honest, given a commit that breaks it we can probably find the issue rather quickly. bisect is a very powerful tool.

katananja commented 6 years ago

Thank you guys! I'll look in to that!

Thank you very much!

katananja commented 6 years ago

I've identify what trigger the issue, looks like is caused by non C locales like the one I use, pt_BR. Switching from non C to C the sprites goes back to normal, this doesn't affect 0.193.

Check your environment with: env |egrep -e 'LC_ALL|LANG'

I'm using this to switch from one to another, add this at the end of your ~/.bashrc

function set_locale() { # [profile]
    local profile=${1:-BR}
    case ${profile} in
        BR|pt_BR|pt_BR)
            LC_ALL="pt_BR.UTF-8"
            LANG="pt_BR.UTF-8"
            LANGUAGE="pt_BR:pt"
            ;;
        EN|EN_US|en|en_US)
            LC_ALL="C"
            LANG="en_US.UTF-8"
            LANGUAGE="en_US:en"
            ;;
        CLR|DF)
            unset LC_ALL
            unset LANG
            unset LANGUAGE
            ;;
    *)
            echo "ALERT" "${FUNCNAME}: unknown profile '${profile}'"
            ;;
    esac
    echo "locale settings" "${LANG}";
    export LC_ALL LANG LANGUAGE 
}

Use "set_locale XX" to change, again, this do not affect 0.193. Still looking in to this.

Thanks.

rb6502 commented 6 years ago

Ok, that's something I wouldn't have expected. I'm looking forward to finding out exactly what's wrong.

katananja commented 6 years ago

Thank you!