Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

mame_libretro.dll for x86/32-bit windows appears to be broken. #20

Closed
gordon-fish opened this issue Feb 10, 2017 · 64 comments
Closed

mame_libretro.dll for x86/32-bit windows appears to be broken. #20

gordon-fish opened this issue Feb 10, 2017 · 64 comments

Comments

@gordon-fish
Copy link

gordon-fish commented Feb 10, 2017 •
edited by inactive123

I've been able to confirm with others that the 32bit mame_libretro.dll will not start, but will crash RetroArch when attempting to load any rom (arcade or console; tried Coleco Vision games and arcade PacMan and a few others for testing that all run fine under stand alone 0.182.)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@ghost
Copy link

ghost commented Feb 11, 2017

confirmed here. using latest buildbot retroarch_x86 and mame_libretro.dll x86(direct downloads, not from online updater)

@szr8
Copy link

szr8 commented Feb 11, 2017

I'm also seeing the same thing. It just crashes with

Microsoft Visual C++ Runtime Library
Runtime Error!
Program: D:\emu\RetroArch\retroarch.exe
This application has requested the Runtime to terminate it in an unusual way.

32-bit Windows, 32-bit RetroArch 1.4.1 (recent nightly), tried x86 mame_libretro.dll from RA's online updater and directly http://buildbot.libretro.com/nightly/windows/x86/latest/mame_libretro.dll.zip

@szr8
Copy link

szr8 commented Feb 16, 2017

Is there anyone who has any idea what's causing this?

@r-type
Copy link

r-type commented Feb 16, 2017

Soory I Dont have a 32 bit windows. So i need a proper debug backtrace before looking at.

@szr8
Copy link

szr8 commented Feb 22, 2017

How exactly would one get the appropriate backtrace on windows?

@gordon-fish
Copy link
Author

I would like to know this too. I would really like to get the mame core working in 32-bit Windows and if I can help then I'd be more than happy to do so.

@ghost
Copy link

ghost commented Feb 23, 2017

mame is updated to 183 core(latest mame-dev) and the 32bit core in buildbot has been also updated to this version(at least by looking at build date of the mame_libretro.dll). mame-dev notes there 32bit related issues that crash mame so the new commit is worth testing.

sadly it still crashes on my end(retroarch 32bit) im not entirely sure if its related because i am using a 64bit windows(which normally should not be an issue).

@gordon-fish
Copy link
Author

This is the error I get: http://imgur.com/e3z7p9p

How can one get the gdb bt/log when this error occurs?

@ghost
Copy link

ghost commented Feb 24, 2017

this might not be related, but i managed to use a decent android device to run retroarch on. downloaded RA-fortunately its 32bit version good for the test. downloaded latest mame_libretro from online updater and it runs FINE, sadly though it has been updated to 0.183 so probably this previous version has 32-bit related issues. for some reasons(again) windows buildbot has been lazy and builds are always late.

@gordon-fish
Copy link
Author

I've tried the latest buildbot versions (and they say 0.183) and it still crashes. Can anything be done about this? I'd be more than happy to provide debug info if I knew of a viable back trace method for win32.

Also note that retroarch_debug.exe still seems to be unusable on 32-bit windows as well - it's always crashed no matter what version, so I hope there is a method that doesn't require its use.

@Margen67
Copy link

Margen67 commented Apr 1, 2017

What about 0.184?

@szr8
Copy link

szr8 commented Apr 3, 2017

@Margen67 Still crashes for me the same way when loading a rom.

@gordon-fish
Copy link
Author

@Margen67 It still crashes for me as well in the same manner as previously.

@rb6502
Copy link

rb6502 commented May 25, 2017

Fair warning: MAMEdev is likely to deprecate and possibly even remove 32-bit Windows support by the end of the year. You get a free 20% speed boost in MAME by going 64-bit, we don't understand why anyone would turn that down :)

@hizzlekizzle
Copy link

@rb6502
I know you guys have a lot of die-hard WinXP users. Has there been much gnashing of teeth from that group about the news?

@rb6502
Copy link

rb6502 commented May 25, 2017

There's a few, but GroovyMAME largely has moved all the cabinet/15 kHz monitor people to Win 7 so the XP holdouts are few and far between now. I imagine whenever we make it official there'll be some grumbling, but we've been advising people to go 64-bit for a decade now.

@gordon-fish
Copy link
Author

@rb6502

"MAMEdev is likely to deprecate and possibly even remove 32-bit Windows support by the end of the year."

As long as 32-bit MAME exists, could we at least get a working 32-bit windows MAME core for RA? It still crashes in the same way and not just in XP. The stand alone 32-bit MAME runs just fine in 32-bit windows (including XP), just not the corresponding RA cores.

Having at least one working version for the core would be nice as people who are still using such 32-bit windows can at least use an older version later on when 32-bit MAME becomes discontinued. Right now there is nothing that appears to work.

"we've been advising people to go 64-bit for a decade now."

Not everyone has that option though. There are A LOT of people using 32-bit windows for various reasons out there, not to mention there are still new computers sold with 32-bit that I've seen, and frankly just dropping support for it seems a little short sighted.

@inactive123
Copy link

inactive123 commented May 26, 2017 •
edited

Well, the older MAME cores (the non-upstream MAME cores) would still remain a viable option for 32bit x86.

RetroArch and libretro itself will retain backwards compatibility with older architectures and OSes for the record. In fact, our whole motto is to be as backwards-compatible as possible, with @bparker06 even going for Windows 9x/DOS. For upstream MAME core though, we will just go along with the flow of whatever the upstream project does.

@gordon-fish
Copy link
Author

gordon-fish commented May 29, 2017 •
edited

@twinaphex The problem isn't MAME itself, as 0.185 runs on 32-bit Windows just fine, including XP, it's just its RA core counter-part that just crashes no matter what, which is very strange and really should be addressed. It would be nice to have at least one version that works (can actually run) before 32-bit versions cease being released. Has anyone any idea why it just crashes? I'd love to help with debugging but I'd need to know what I need to do that on windows.

@inactive123
Copy link

inactive123 commented May 29, 2017 •
edited

I wasn't talking about MAME itself being a problem or not, not sure where you deduced that.

Anyway, I don't know what the problem is quite honestly. It's also not a current priority, the current priority is getting RA 1.6.0 out of the door.

@r-type
Copy link

r-type commented May 29, 2017 •
edited

that's odd , I’ve just compiled pacman driver using i686-w64-mingw32 from my linux64 and it seem to works fine with wine and the last x86 retroarch.7z .
That said , i can't test it on a real 32 bits machine. but does the current mame core for x86 works also on a windows 64 machine with retroarch for x86 ?

if someone can try it on a real windows ( on real x86 windows and on 64bits with Wow64 )
http://dl.free.fr/kLcfb1jHB

@r-type
Copy link

r-type commented May 29, 2017 •
edited

BTW why recipe for X86 use PTR64=1 ?

https://github.com/libretro/libretro-super/blob/master/recipes/windows/cores-windows-x86_dw2-generic#L81

the above core is compiled using

export MINGW32=/usr
make OSD="retro" verbose=1 RETRO=1 NOWERROR=1  OS="linux" TARGETOS="windows" CONFIG="libretro"  NO_USE_MIDI="1" PTR64=0  GCC="mingw32-gcc"  -j10 SUBTARGET=midyunit SOURCES=src/mame/drivers/midyunit.cpp

@ghost
Copy link

ghost commented May 29, 2017 via email

@r-type
Copy link

r-type commented May 30, 2017

It strange that it dos not works for you on windows 64 with the core i post above,
I've just tested on a windows 10 64bits , launching the mame x86 core with retroarch x86 and it works as expected like with my previous wine experience . have you really try the core i posted above or you talk about the buildbot one ?

pacman

@szr8
Copy link

szr8 commented May 30, 2017

@r-type @retro-wertz I can also confirm the Visual C++ error see here based crash, and this occurs on actual 32-bit windows as well as running 32-bit RA and 32-bit MAME core on 64-bit windows (I tested the latter in a Win 7 VM, the former on a real XP classic gaming machine that can run even the latest stand alone MAME seemingly perfectly.)

As gordon said, it would be really nice to have this working.

@r-type
Copy link

r-type commented May 31, 2017

So the core i upload above does the same crash for you ?
it's odd that it works for me.

Note : it's a only a midyunit drivers core ,so working only with

    * Narc
    * Trog
    * Strike Force
    * Smash TV
    * High Impact Football
    * Super High Impact
    * Terminator 2
    * Mortal Kombat (Y-unit versions)
    * Total Carnage

@gordon-fish
Copy link
Author

@r-type I didn't notice the dl.free.fr link above, I'll test that....

...and I /was/ able to load smashtv.zip with that core (though loading any game not in that list, like puckman.zip, results in a plain "retroarch.exe has encountered a problem and needs to close." box, presumably due to the lack of other drivers in this core as you said.) So there seems to be hope now :)

@r-type
Copy link

r-type commented May 31, 2017

yes it's only a tiny core with just midyunit drivers , so other games will crash .
I think a full build should be fine now with X86 (if the new merge commit didn’t break anything).

Thanks for the feedback.

I think the problem is only on the from buildbot recipe ,
but as they don't have any log about windows build it's hard to know why/where it break. (BTW using PTR64=1 for a X86 build is odd ).

I opened a issue at libretro-super repo maybe @twinaphex could look at when it will be available (but I know that the libretro team is very busy with 1.6 release).
when they have time they will surely look at , if need some help to sort out , just ask .

@r-type
Copy link

r-type commented Jun 1, 2017

in the waiting you can try this one. to tell if it works for you.
https://ufile.io/c2dko

@gordon-fish
Copy link
Author

@r-type Thanks. Seems to work with several random arcade games that I threw at it. I tried to load a coleco vision game (coleco\congo.zip) and it looks like it's starting to load but ends up dying, and I'm guessing this is expected as I'm assuming from the filename of this core that it only contains arcade drivers? Thanks again.

@hizzlekizzle
Copy link

@r-type
The 32-bit builds should use PTR64=0 from now on:
libretro/libretro-super@17e9960

@r-type
Copy link

r-type commented Jun 9, 2017

nice , BTW ,i didn't see a x86 core on builbot , then I suppose it failed at some point , have to see a log to where it break (as x86 compilation working for me).
@twinaphex @hizzlekizzle @hunterk anyway to see the windows build log ?

@inactive123
Copy link

Yes, there is an admin page that lets you see the buildbot update in realtime.

Maybe @bparker06 could give you a user login for it so you can view the buildbots status.

@r-type
Copy link

r-type commented Jun 9, 2017

Ok , thanks ,
if he cant at least if he can posting the resulting log somewhere.

@ghost
Copy link

ghost commented Jun 9, 2017

Here is the log: http://p.0bl.net/39140

@r-type
Copy link

r-type commented Jun 9, 2017

ok this is a know bug with gcc 6.2
#32
mamedev#2347

@szr8
Copy link

szr8 commented Jun 13, 2017

Just for the info, I tried the latest win x86 from buildbot yesterday and it still crashes.

@r-type
Copy link

r-type commented Jun 13, 2017

the mame x86 core from buildbot is dated to 22/05/2017 .
currently it doesn't build due the toolchain used. it build fine with an old toolchain (5.3.1 for example) or with a newer ,but not with 6.2.0. see link above that link to the upstream.
For now , we can't do anything for the x86 core , if there is no update/downgrade of the toolcain used.
@bparker06 anyplan to update/downgrade the mingw32 tc ?

@ghost
Copy link

ghost commented Jun 13, 2017

@r-type I just updated it to 6.3, so hopefully it will work now.

@ghost
Copy link

ghost commented Jun 14, 2017

It appears to work now: http://i.imgur.com/eAGkxzd.png

@r-type
Copy link

r-type commented Jun 14, 2017

nice , we can hopefully close this one !

@gordon-fish
Copy link
Author

I downloaded http://buildbot.libretro.com/nightly/windows/x86/2017-06-13_RetroArch.7z, and the latest http://buildbot.libretro.com/nightly/windows/x86/latest/mame_libretro.dll.zip and it still crashes like before.

@ghost
Copy link

ghost commented Jun 14, 2017

@gordon-fish try to download the full version of Retroarch.7z and re-test. and if possible, re-upload a new log based on it.

@r-type
Copy link

r-type commented Jun 14, 2017

the buildbot one failed also for me with wine.
@bparker06 can you post the buildlog somewhere ?

@ghost
Copy link

ghost commented Jun 14, 2017

@r-type I don't have the buildlog but I also used x86 wine and didn't have any issues, but my OS was set to Windows 10. Is yours perhaps set to XP?

@r-type
Copy link

r-type commented Jun 14, 2017 •
edited

Yes setting to XP , but the strange is that my own build ( mame arcade posted above) work fine with XP setting.

also I use this command line to build , not the Makefile.libretro.

export MINGW32=/usr
make -r OSD="retro" verbose=1 RETRO=1 NOWERROR=1 OS="linux" TARGETOS="windows" CONFIG="libretro" NO_USE_MIDI="1" PTR64=0 GCC="mingw32-gcc" -j10 SUBTARGET=arcade

also i use thread model posix not win32.

@gordon-fish
Copy link
Author

Just to be clear, mamearcade_libretro.dll (https://ufile.io/c2dko that @r-type posted) works fine, I can load and play 1942 or Puckman [is there a way to load clones, like Pac-Man?] just fine, but using the official mame_libretro.dll it crashes just like before with the VC++ box.

@ghost
Copy link

ghost commented Jun 14, 2017 via email •
edited by ghost

@szr8
Copy link

szr8 commented Jun 19, 2017 via email

@ghost
Copy link

ghost commented Jun 20, 2017

@retro-wertz What do you mean? The date on the core is 06-13-2017.

Does anyone have a backtrace of this so we can see what's going on?

@ghost
Copy link

ghost commented Jun 20, 2017 •
edited by ghost

@bparker06 - hmm, this must indeed be new set of compile mame 32bit core based on datestamp inside the zip. im sure this was not the case the last time i posted..

anyways the problem with me and gordon before when we first tried troubleshooting the issue, is getting the logs from gdb. because of the Visual C++ something runtime error window, since when you press close, gdb stack becomes empty(or something). sadly i do not have 32bit windows installed anymore to check and test things.

@gordon-fish -fish can you check? it does seem to have new timestamp. if possible just download directly from buildbot https://buildbot.libretro.com/nightly/windows/x86/latest/

UPDATE: i just rememberd. the problem was not that it did not compiled before, but it did compile fine and still it would cause runtime error when loaded. so its possible the one in buildbot is newly compiled but still would not run.

@gordon-fish
Copy link
Author

gordon-fish commented Jun 20, 2017 via email

@gordon-fish
Copy link
Author

gordon-fish commented Jun 24, 2017 via email

@szr8
Copy link

szr8 commented Jun 24, 2017 via email

@gordon-fish
Copy link
Author

gordon-fish commented Jun 26, 2017 via email

@gordon-fish
Copy link
Author

@r-type I finally got around to setting up a build environment and cloned the master from this repo, built with just TARGET=mame PTR64=0, got the same crash with the .dll it produced. Then I tried with SUBTARGET=arcade and it crashed the same way as before (same with SUBTARGET=mess too.)

How did you you build your mamearcade_libretro.dll that you posted? I still have it and if I use that, I can load mame roms just fine. So I'm really interested in what you might have done differently. Was there anything you modified? Different make options? Something else perhaps?

I really really want to solve this whole problem and I'm more than willing to do what ever is needed.

@imkrut
Copy link

imkrut commented May 8, 2018

I've been banging my head for a while trying to fix this, (since I have 2 windows 10 machines that worked fine, and an old Windows 7 laptop that that just refused to run the latest mame_libretro.dll.... figured it must be some configuration issue.

Just wondering if x86/32bit support for Mame is dropped? or is there a workaround? I use the same romset between the 3 machines, that's why I favored the latest MAME core.

@gordon-fish
Copy link
Author

@imkrut Standalone mame still runs fine on 32-bit XP, and this is why I don't understand why the 32-bit mame core doesn't work as well I've tried building from sources, but got the same results. I tried using various gdb.exe that I've found but none of them yielded anything. I really wish I knew how to properly debug this. I would use RA debug exe but that one doesn't appear to run on XP.

@tcamargo
Copy link

tcamargo commented Jul 6, 2020

Closing old issues. Please reopen if it is still relevant.

@tcamargo tcamargo closed this as completed Jul 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@tcamargo @inactive123 @hizzlekizzle @Margen67 @r-type @rb6502 @imkrut @szr8 @gordon-fish