Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
#112659 - 02/16/18 01:57 PM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Mar 2001
Posts: 15,932
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,932
USA
Alright. Try -sound none on the off chance something's wrong there.

#112670 - 02/17/18 02:07 AM Re: sdl mame64 unresponsive [Re: R. Belmont]  
Joined: Jan 2009
Posts: 42
Procyon Offline
Member
Procyon  Offline
Member

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.

#112671 - 02/17/18 03:01 AM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Mar 2001
Posts: 15,932
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,932
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.

#112672 - 02/17/18 03:36 AM Re: sdl mame64 unresponsive [Re: R. Belmont]  
Joined: Jan 2009
Posts: 42
Procyon Offline
Member
Procyon  Offline
Member

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.
#112673 - 02/17/18 03:41 AM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Jan 2009
Posts: 42
Procyon Offline
Member
Procyon  Offline
Member

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.
#112674 - 02/17/18 04:32 AM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Jan 2009
Posts: 42
Procyon Offline
Member
Procyon  Offline
Member

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.
#112677 - 02/17/18 01:42 PM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Mar 2001
Posts: 15,932
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,932
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.

#112697 - 02/20/18 02:58 AM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Jan 2009
Posts: 42
Procyon Offline
Member
Procyon  Offline
Member

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.
#112698 - 02/20/18 03:20 AM Re: sdl mame64 unresponsive [Re: Procyon]  
Joined: Mar 2001
Posts: 15,932
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,932
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.

#112699 - 02/20/18 03:38 AM Re: sdl mame64 unresponsive [Re: R. Belmont]  
Joined: Jan 2009
Posts: 42
Procyon Offline
Member
Procyon  Offline
Member

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.
Page 2 of 3 1 2 3

Moderated by  R. Belmont 

Who's Online Now
3 registered members (ranger_lennier, AJR, Breiztiger), 12 guests, and 1 spider.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,534
Posts111,537
Members4,793
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.0
Page Time: 0.043s Queries: 14 (0.013s) Memory: 5.0231 MB (Peak: 5.2470 MB) Zlib enabled. Server Time: 2018-05-21 07:19:36 UTC