Previous Thread
Next Thread
Print Thread
Page 1 of 3 1 2 3
sdl mame64 unresponsive #112642
02/16/18 02:41 AM
02/16/18 02:41 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Hi guys, I'm encountering a problem, dunno if it's just me or not. I'm on Ubuntu 17.10, with an nVidea GeForce GTX 970M. I doubt that matters much, but basically, if I launch mame64, the program will hang and never get to the menu. I did the following:

Code
git checkout mame0194
make clean
make -j 7
./mame64 -w


The very first time I do this, it will take a long time, but it will eventually come up with the UI. Then if I reboot my laptop and try again, it will launch, and it may say "Initializing" but it will never bring up the menu or accept input. (I'm using -w so that I don't go fullscreen and lose control of the laptop.) If I try
Code
mame64 -w pacman
, it will also say "Initializing" and never come back. I always have to Force Quit the app, it won't respond to anything else.

I don't know if I've provided enough detail, but this did not used to be a problem. I only noticed it recently, so just to be on the safe side, I tried checking out mame0193 instead and trying that instead. I got the same results. Is there a verbose debug mode that logs out what's going on and why it's getting stuck?

Thanks very much for your help.

Last edited by Procyon; 02/16/18 02:56 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112643
02/16/18 02:50 AM
02/16/18 02:50 AM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
Try -verbose.

Re: sdl mame64 unresponsive [Re: R. Belmont] #112644
02/16/18 02:58 AM
02/16/18 02:58 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Thank you, shoulda thought of that. Here we go:
Code
Available videodrivers: x11 mir 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)
Build architecure:  
Build defines 1:    SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1 
Build defines 1:    LSB_FIRST=1 PTR64=1 
SDL/OpenGL defines: SDL_COMPILEDVERSION=2006 USE_OPENGL=1 
Compiler defines A: __GNUC__=7 __GNUC_MINOR__=2 __GNUC_PATCHLEVEL__=0 __VERSION__="7.2.0" 
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

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)
	SDL_VIDEO_WIN_D3DCOMPILER                (null)
	SDL_VIDEO_WINDOW_SHARE_PIXEL_FORMAT      (null)
	SDL_VIDEO_MAC_FULLSCREEN_SPACES          (null)
	SDL_MOUSE_RELATIVE_MODE_WARP             (null)
	SDL_RENDER_DIRECT3D11_DEBUG              (null)
	SDL_VIDEO_HIGHDPI_DISABLED               (null)
	SDL_WINRT_PRIVACY_POLICY_URL             (null)
	SDL_WINRT_PRIVACY_POLICY_LABEL           (null)
	SDL_WINRT_HANDLE_BACK_BUTTON             (null)
Leave sdlwindow_init
Enter sdl_info::create
Audio: Start initialization
Audio: Driver is pulseaudio
Audio: frequency: 48000, channels: 2, samples: 512
sdl_create_buffers: creating stream buffer of 25600 bytes
Audio: End initialization
Keyboard: Start initialization
Input: Adding keyboard #0: System keyboard (device id: System keyboard)
Keyboard: Registered System keyboard
Keyboard: End initialization
Mouse: Start initialization
Input: Adding mouse #0: System mouse (device id: System mouse)
Mouse: Registered System mouse
Mouse: End initialization
Joystick: Start initialization
Joystick: End initialization
Searching font Liberation Sans in -. path/s
Matching font: /usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf
Region ':user1' created
Killed


It reached that "Region ':user1' created" line and sat there for a good two minutes before I killed it.

Last edited by Procyon; 02/16/18 03:00 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112645
02/16/18 02:59 AM
02/16/18 02:59 AM
Joined: Apr 2006
Posts: 700
USA
Tafoid Offline
Senior Member
Tafoid  Offline
Senior Member
Joined: Apr 2006
Posts: 700
USA
Originally Posted by Procyon
Hi guys, I'm encountering a problem, dunno if it's just me or not. I'm on Ubuntu 17.10, with an nVidea GeForce GTX 970M. I doubt that matters much, but basically, if I launch mame64, the program will hang and never get to the menu. I did the following:

Code
git checkout mame0194
make clean
make -j 7
./mame64 -w


The very first time I do this, it will take a long time, but it will eventually come up with the UI. Then if I reboot my laptop and try again, it will launch, and it may say "Initializing" but it will never bring up the menu or accept input. (I'm using -w so that I don't go fullscreen and lose control of the laptop.) If I try
Code
mame64 -w pacman
, it will also say "Initializing" and never come back.

I don't know if I've provided enough detail, but this did not used to be a problem. I only noticed it recently, so just to be on the safe side, I tried checking out mame0193 instead and trying that instead. I got the same results. Is there a verbose debug mode that logs out what's going on and why it's getting stuck?

Thanks very much for your help.


A few things to try:

First of, use -verbose trigger. This will detail a lot fo the initialization process and may help you discover an issue.
Try alternative video modes: -video opengl -video bgfx -video soft
Check other running programs. I've come across an issue with another person having problems using "vjoy".
Unplug, one at a time, your USB devices. There could be a possible conflict or inability to read a controller or other.




Re: sdl mame64 unresponsive [Re: Tafoid] #112646
02/16/18 03:04 AM
02/16/18 03:04 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Originally Posted by Tafoid
First of, use -verbose trigger. This will detail a lot fo the initialization process and may help you discover an issue.
Try alternative video modes: -video opengl -video bgfx -video soft
Check other running programs. I've come across an issue with another person having problems using "vjoy".
Unplug, one at a time, your USB devices. There could be a possible conflict or inability to read a controller or other.


Thanks Tafoid, verbose output provided above. I had tried opengl and bgfx, hadn't tried soft, but I got the same thing. No other running programs, this will happen right after a reboot. No vjoy either (isn't that a Windows only thing? Or is there vjoy for linux?) Nothing plugged into USB.

Re: sdl mame64 unresponsive [Re: Procyon] #112647
02/16/18 03:36 AM
02/16/18 03:36 AM
Joined: Apr 2006
Posts: 700
USA
Tafoid Offline
Senior Member
Tafoid  Offline
Senior Member
Joined: Apr 2006
Posts: 700
USA
Originally Posted by Procyon
Originally Posted by Tafoid
First of, use -verbose trigger. This will detail a lot fo the initialization process and may help you discover an issue.
Try alternative video modes: -video opengl -video bgfx -video soft
Check other running programs. I've come across an issue with another person having problems using "vjoy".
Unplug, one at a time, your USB devices. There could be a possible conflict or inability to read a controller or other.


Thanks Tafoid, verbose output provided above. I had tried opengl and bgfx, hadn't tried soft, but I got the same thing. No other running programs, this will happen right after a reboot. No vjoy either (isn't that a Windows only thing? Or is there vjoy for linux?) Nothing plugged into USB.


Your verbose output mentions that you are using MAME 0.193, not MAME 0.194.
Can you try 0.193 here? http://sdlmame.wallyweek.org/download




Re: sdl mame64 unresponsive [Re: Tafoid] #112648
02/16/18 03:57 AM
02/16/18 03:57 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Yeah, like I said, I synced to 0.193 recently to see if it was a new problem with 0.194, or something I was experiencing across all versions of MAME. Do you want me to download your source and compile from that? Or install the .deb? I'm sort of leery about doing that because I have things tuned to work well in a dual-boot environment and I don't want to screw that up, but I'll try it if you think it will help.

Re: sdl mame64 unresponsive [Re: Procyon] #112649
02/16/18 04:44 AM
02/16/18 04:44 AM
Joined: Apr 2006
Posts: 700
USA
Tafoid Offline
Senior Member
Tafoid  Offline
Senior Member
Joined: Apr 2006
Posts: 700
USA
I'm honestly not sure. The person who packages them has done it for a long time so it is a reliable source and linked from the mamedev.org downloads page. Since I am only using Windows, I can't really advise further. I'll leave you to other non-Windows Dev and Users who may have experience with your issues.

Good Luck!




Re: sdl mame64 unresponsive [Re: Procyon] #112654
02/16/18 01:04 PM
02/16/18 01:04 PM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
Does your ROM path point to an NFS or other remote server? That's one thing that could be consistent with what you're seeing if there's some network problem accessing the ROMs.

Re: sdl mame64 unresponsive [Re: R. Belmont] #112655
02/16/18 01:30 PM
02/16/18 01:30 PM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Originally Posted by R. Belmont
Does your ROM path point to an NFS or other remote server? That's one thing that could be consistent with what you're seeing if there's some network problem accessing the ROMs.


No, they're on my NTFS partition, which is mounted to Ubuntu through /media/procyon/Data. Here's the verbose output of when I try to load pacman from the command line. As you can see, it doesn't seem to have any problems finding the files.

Code
Available videodrivers: x11 mir 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)
Build architecure:  
Build defines 1:    SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1 
Build defines 1:    LSB_FIRST=1 PTR64=1 
SDL/OpenGL defines: SDL_COMPILEDVERSION=2006 USE_OPENGL=1 
Compiler defines A: __GNUC__=7 __GNUC_MINOR__=2 __GNUC_PATCHLEVEL__=0 __VERSION__="7.2.0" 
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

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)
	SDL_VIDEO_WIN_D3DCOMPILER                (null)
	SDL_VIDEO_WINDOW_SHARE_PIXEL_FORMAT      (null)
	SDL_VIDEO_MAC_FULLSCREEN_SPACES          (null)
	SDL_MOUSE_RELATIVE_MODE_WARP             (null)
	SDL_RENDER_DIRECT3D11_DEBUG              (null)
	SDL_VIDEO_HIGHDPI_DISABLED               (null)
	SDL_WINRT_PRIVACY_POLICY_URL             (null)
	SDL_WINRT_PRIVACY_POLICY_LABEL           (null)
	SDL_WINRT_HANDLE_BACK_BUTTON             (null)
Leave sdlwindow_init
Enter sdl_info::create
Audio: Start initialization
Audio: Driver is pulseaudio
Audio: frequency: 48000, channels: 2, samples: 512
sdl_create_buffers: creating stream buffer of 25600 bytes
Audio: End initialization
Keyboard: Start initialization
Input: Adding keyboard #0: System keyboard (device id: System keyboard)
Keyboard: Registered System keyboard
Keyboard: End initialization
Mouse: Start initialization
Input: Adding mouse #0: System mouse (device id: System mouse)
Mouse: Registered System mouse
Mouse: End initialization
Joystick: Start initialization
Joystick: End initialization
Searching font Liberation Sans in -. path/s
Matching font: /usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf
Region ':maincpu' created
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: found /media/procyon/Data/MAME/roms/puckman.zip ECD
unzip: /media/procyon/Data/MAME/roms/puckman.zip has no ZIP64 ECD locator
unzip: read /media/procyon/Data/MAME/roms/puckman.zip central directory
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
Region ':gfx1' created
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
Region ':proms' created
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
Region ':namco' created
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
Killed

Re: sdl mame64 unresponsive [Re: Procyon] #112659
02/16/18 01:57 PM
02/16/18 01:57 PM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
Alright. Try -sound none on the off chance something's wrong there.

Re: sdl mame64 unresponsive [Re: R. Belmont] #112670
02/17/18 02:07 AM
02/17/18 02:07 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Thanks for the suggestion arbee, but it made no difference frown I ran
Code
mame64 -w -verbose -sound none pacman
but the verbose output was identical to my previous post. It dies in the same spot. I can modify the source if you'd like me to pepper more logging into useful locations if you have any more ideas. On the plus side, mame works fine on this laptop if I boot into Windows. The problem is I prefer running in Ubuntu, mame included.

Re: sdl mame64 unresponsive [Re: Procyon] #112671
02/17/18 03:01 AM
02/17/18 03:01 AM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
Alright, let's take everything Linux specific out of the conversation:

mame64 pacman -verbose -sound none -video none -seconds_to_run 5

That should show a blank window for 5 seconds and then exit and report on the average frame rate.

Re: sdl mame64 unresponsive [Re: R. Belmont] #112672
02/17/18 03:36 AM
02/17/18 03:36 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
I get what you were thinking there, but sadly, no change. It didn't time out after 5 seconds, it remained hung until I was able to terminate the process. Verbose output was the same, the last little bit was:
Code
Region ':namco' created
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
unzip: found /media/procyon/Data/MAME/roms/puckman.zip in cache
unzip: opened archive file /media/procyon/Data/MAME/roms/puckman.zip
unzip: closing archive file /media/procyon/Data/MAME/roms/puckman.zip and sending to cache
Killed

Last edited by Procyon; 02/17/18 03:42 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112673
02/17/18 03:41 AM
02/17/18 03:41 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
I have one more bit of info if it helps. I'm on a Core i7, so four hyperthreaded cores. As long as I let mame run, one core remains at 100% constantly until I shut it down. It's definitely trying to do something.

UPDATE: Got another nugget here that may or may not be useful.

So I ran "mame64 pacman -sound none -video none -seconds_to_run 5 -w &" with the ampersand to run it detached from the terminal. Then as quickly as I could, I tried running strace on the process. Whenever I do that, all I get is a never ending spew of:

Code
pread64(20, "", 512, 76)                = 0
pread64(20, "\0", 512, 75)              = 1
pread64(20, "", 512, 76)                = 0
pread64(20, "\0", 512, 75)              = 1


on and on and on. That never changes. I wish I was able to type it out faster to get something more useful, but I have to enter the new process id every time, so I can't script it.

UPDATE 2: Well, I may not be getting any closer to fixing my build of MAME, but I am learning a ton about linux's live debugging capabilities. Here is GDB's backtrace at the time of the hang:

Code
(gdb) bt
#0  0x00007f71ec78a7f3 in __pread64_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1  0x00005641b917a874 in (anonymous namespace)::posix_osd_file::read(void*, unsigned long, unsigned int, unsigned int&) ()
#2  0x00005641b8e8f70f in util::(anonymous namespace)::core_osd_file::osd_or_zlib_read(void*, unsigned long, unsigned int, unsigned int&) ()
#3  0x00005641b8e9005e in util::(anonymous namespace)::core_osd_file::read(void*, unsigned int) ()
#4  0x00005641b8e90a02 in util::(anonymous namespace)::core_text_file::gets(char*, int) ()
#5  0x00005641b67a4009 in inifile_manager::init_category(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, emu_file&) ()
#6  0x00005641b67a5616 in inifile_manager::inifile_manager(running_machine&, ui_options&) ()
#7  0x00005641b6794032 in mame_machine_manager::create_custom(running_machine&) ()
#8  0x00005641b8ae8f85 in running_machine::start() ()
#9  0x00005641b8aea702 in running_machine::run(bool) ()
#10 0x00005641b679541d in mame_machine_manager::execute() ()
#11 0x00005641b6830a68 in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) ()
#12 0x00005641b6830f6e in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#13 0x00005641b6793065 in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#14 0x00005641b4306624 in main ()

Last edited by Procyon; 02/17/18 04:09 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112674
02/17/18 04:32 AM
02/17/18 04:32 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
So before I begin again, I apologize for the spew of posts, I've become incredibly curious about this problem. Second, things just got weirder, and this may be a problem entirely of my own making, although I've had it set up like this for years.

So if I go to the folder where I built mame (which happens to be ~/dev/mame) and I just do a "./mame64"... everything is fine. No hang. However, if I try typing dev/mame/mame64 from my home dir, I get the hang.

The way I normally invoke mame is to symbolically link the output of the build to a file named /usr/bin/mame64. That way it's in my path and I don't have to ever copy anything over when I make a new build. Like I said, this has been working for me for years. Today, not so much.

So it's sort of a "problem solved" if we're willing to accept that I must cd into ~/dev/mame and run ./mame64 . If you have any thoughts why I might be running into this, I'd love to know.

Last edited by Procyon; 02/17/18 04:42 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112677
02/17/18 01:42 PM
02/17/18 01:42 PM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
That shouldn't matter. All I can think of is that changes (slightly) where it looks for mame.ini, but since it's finding the ROMs that means it's finding a valid mame.ini.

Re: sdl mame64 unresponsive [Re: Procyon] #112697
02/20/18 02:58 AM
02/20/18 02:58 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
So I spent a little more time on this tonight. Based on the backtrace that I posted, I went into src/frontend/mame/ui/inifile.cpp, and added the following line to the beginning of inifile_manager::init_category:

Code
	osd_printf_verbose("procyon: init_category %s", file.fullpath());


What I found was interesting. If I launch ./mame64 from within ~/dev/mame, I never see my line printed. However, if I'm in my home directory and launch dev/mame/mame64, I see the following output before it hangs (last 5 lines):

Code
Joystick: End initialization
Searching font Liberation Sans in -. path/s
Matching font: /usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf
Region ':user1' created
procyon: init_category folders/Favorites.ini


The same is true whether I include a game to launch with or not. So the question is, why does mame only try to load a Favorites.ini when I'm outside of the directory that mame was built in, and why does it not try to load this file when I'm in the build directory?

UPDATE: Kept digging in, found the culprit, but I don't understand the cause. Commenting out the following line in src/frontend/mame/mame.cpp made the hang go away. In mame_machine_manager::create_custom,

Code
m_inifile = std::make_unique<inifile_manager>(machine, m_ui->options());


I'm not familiar with std::make_unique, but I'll do some research to see if anything makes sense.

Last edited by Procyon; 02/20/18 03:18 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112698
02/20/18 03:20 AM
02/20/18 03:20 AM
Joined: Mar 2001
Posts: 15,964
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,964
USA
It means that the mame.ini it's accessing in one place is poisoned in some way and the one it gets elsewhere isn't.

Re: sdl mame64 unresponsive [Re: R. Belmont] #112699
02/20/18 03:38 AM
02/20/18 03:38 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
That's interesting. I tried backing up and blowing away my ~/.mame/mame.ini, and it didn't seem to make a difference.

A bit more digging in, for this line at the top of the inifile_manager constructor:

Code
	file_enumerator path(m_options.categoryini_path());


When I run from the build dir, path is NULL, so the for loop below doesn't run and I don't hang. When I run from my home dir, path is apparently "folders"... Checking my mame.ini

Last edited by Procyon; 02/20/18 03:40 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112700
02/20/18 03:53 AM
02/20/18 03:53 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Solved.

OK, it was this line in the ui.ini that was screwing me up:

Code
categorypath              folders


I changed it to look in the MAME dir on my NTFS drive and the hang went away. This is a pretty odd thing though, I don't have a ui.ini anywhere else, so I don't understand why running .mame64 from within ~/dev/mame didn't reproduce the hang as well. I would imagine it was referring to the same ~/.mame/ui.ini file.

Not sure if I uncovered something that will help the community at large, or if this is something unique to the way I set MAME up. But as soon as I pointed categorypath to a valid location, mame was happy.

Last edited by Procyon; 02/20/18 03:53 AM.
Re: sdl mame64 unresponsive [Re: Procyon] #112701
02/20/18 05:06 AM
02/20/18 05:06 AM
Joined: Feb 2004
Posts: 1,968
Sydney, Australia
Vas Crabb Offline
Very Senior Member
Vas Crabb  Offline
Very Senior Member
Joined: Feb 2004
Posts: 1,968
Sydney, Australia
Originally Posted by Procyon
That's interesting. I tried backing up and blowing away my ~/.mame/mame.ini, and it didn't seem to make a difference.

A bit more digging in, for this line at the top of the inifile_manager constructor:

Code
	file_enumerator path(m_options.categoryini_path());


When I run from the build dir, path is NULL, so the for loop below doesn't run and I don't hang. When I run from my home dir, path is apparently "folders"... Checking my mame.ini


path is an object, not a pointer - it can't be NULL. But that aside, if walking a directory causes a hang, you have bigger problems with your setup.

Re: sdl mame64 unresponsive [Re: Vas Crabb] #112702
02/20/18 12:53 PM
02/20/18 12:53 PM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
Originally Posted by Vas Crabb
path is an object, not a pointer - it can't be NULL. But that aside, if walking a directory causes a hang, you have bigger problems with your setup.


My apologies, you are correct. What I should have said was that path.next() was NULL. But as soon as I set the categorypath to an valid non-relative directory, I was fine.

Last edited by Procyon; 02/20/18 01:08 PM.
Re: sdl mame64 unresponsive [Re: Procyon] #112710
02/21/18 01:42 AM
02/21/18 01:42 AM
Joined: Jan 2009
Posts: 42
Maryland, USA
P
Procyon Offline OP
Member
Procyon  Offline OP
Member
P
Joined: Jan 2009
Posts: 42
Maryland, USA
A little more egg on my face about this. I wondered why, despite everything, mame would return osd_file::error::NONE instead of osd_file::error::NOT_FOUND when it used the relative "folders" path to look for Favorites.ini. I was entirely unaware that I did in fact have a ~/folders path with a busted Favorites.ini file inside. I don't really know where it came from or when it got there (I forgot to check the timestamp before I deleted it). Once I blew it away, everything worked fine with the categorypath set to "folders". So ultimately this was entirely my problem. The code is doing things correctly. Sorry for any headaches or confusion I caused. And thank you to those who tried to lend a hand anyway.

Last edited by Procyon; 02/21/18 01:44 AM.
Page 1 of 3 1 2 3

Moderated by  R. Belmont 

Who's Online Now
0 registered members (), 19 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,553
Posts111,744
Members4,800
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.113s Queries: 14 (0.067s) Memory: 5.8753 MB (Peak: 6.1754 MB) Zlib enabled. Server Time: 2018-07-16 21:50:50 UTC