mupen64plus crashed with SIGSEGV in ViStatusChanged()

[ProfessorKaos64]

[Impact]

Users of Mupen64plus 2.0+1 0, current package version in 14.04 LTS

System information:

* Release: Ubuntu 14.04 LTS
* Package version: libmupen64plus2 2.0-4 amd64

[Test Case]

1. Any video plugin set to 'Fullscreen=True` crashes mupen64plus regardless of width/height specification in config file
2. This occurs with any game I try
2. command used was 'mupen64plus /home/test/my_game.v64`

The problem seems to be with the "libmupen64plus.so.2.0" file under /usr/lib/x86_64-linux-gnu/

The key comment is: https://bugs.launchpad.net/ubuntu/+source/mupen64plus-core/+bug/1355747/comments/21

[Regression Potential]

Changes have been tested by the 3 members in this bug report with success. The changes only reflect a library used by mupen64plus, and that package only. There should be 0 impact to all other packages.

Please requesty any information not in the apport crash collection and I will report it here.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: mupen64plus-ui-console 2.0-1
Uname: Linux 3.14.0-031400-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.1-0ubuntu3.3
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Aug 12 06:50:18 2014
ExecutablePath: /usr/games/mupen64plus
ExecutableTimestamp: 1373087866
InstallationDate: Installed on 2014-08-09 (2 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
ProcCmdline: mupen64plus /home/test/RetroRig/ROMs/N64/Mario\ Kart\ 64.v64
ProcCwd: /var/crash
SegvAnalysis:
 Segfault happened at: 0x7f18d3d6d216 <ViStatusChanged+38>: mov (%rdi),%rax
 PC (0x7f18d3d6d216) ok
 source "(%rdi)" (0x00000000) not located in a known VMA region (needed readable region)!
 destination "%rax" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: mupen64plus-ui-console
StacktraceTop:
 ViStatusChanged () from /usr/lib/x86_64-linux-gnu/mupen64plus/mupen64plus-video-rice.so
 ?? ()
 ?? ()
 CoreDoCommand () from /usr/lib/x86_64-linux-gnu/libmupen64plus.so.2
 __bss_start ()
Title: mupen64plus crashed with SIGSEGV in ViStatusChanged()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[Apport retracing service (apport)]

StacktraceTop:
 ViStatusChanged () at ../../src/Video.cpp:785
 ?? ()
 ?? ()
 add_breakpoint_struct (newbp=0x140) at ../../src/debugger/dbg_breakpoints.c:54
 DebugBreakpointCommand (command=<optimized out>, index=3781498672, ptr=0x140) at ../../src/api/debugger.c:363

[Sven Eckelmann (sven-eckelmann)]

Thanks for reporting this bug upstream. I've linked the bug now.

I was not able to reproduce the problem here. But you've mentioned that "1. problem occured just 2 days ago, recently". What did you change before this happened? I would guess that this change is necessary when it didn't happened before.

I did my test using

rm ~/.config/mupen64plus/mupen64plus.cfg
mupen64plus --rsp mupen64plus-rsp-hle --gfx mupen64plus-video-rice --fullscreen ~/mupen64plus-rom/m64p_test_rom.v64
mupen64plus --rsp mupen64plus-rsp-hle --gfx mupen64plus-video-glide64 --fullscreen ~/mupen64plus-rom/m64p_test_rom.v64
mupen64plus --rsp mupen64plus-rsp-hle --gfx mupen64plus-video-glide64mk2 --fullscreen ~/mupen64plus-rom/m64p_test_rom.v64

[Sven Eckelmann (sven-eckelmann)]

The dependencies you've posted doesn't contain the libmupen64plus2 info. Can you please also provide this information and where you've got it (from an PPA or so).

And would you be willing to test a change from the ppa that I've just uploaded (libmupen64plus2 2.0-7~ppa2)? https://launchpad.net/~sven-eckelmann/+archive/ubuntu/ppa-mupen64plus/+sourcepub/4351026/+listing-archive-extra

Btw. if you want to use different output devices then you may need to change the environment variable SDL_VIDEO_FULLSCREEN_HEAD (e.g. I use following for my second screen)

SDL_VIDEO_FULLSCREEN_HEAD=1 mupen64plus --rsp mupen64plus-rsp-hle --gfx mupen64plus-video-rice --fullscreen ~/mupen64plus-rom/m64p_test_rom.v64

[ProfessorKaos64 (mdeguzis)]

Apt Cache information:

test@test-pc:~$ apt-cache policy mupen64plus
mupen64plus:
  Installed: (none)
  Candidate: 2.0+1
  Version table:
     2.0+1 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
     2.0+1~ppa1~trusty 0
        500 http://ppa.launchpad.net/sven-eckelmann/ppa-mupen64plus/ubuntu/ trusty/main amd64 Packages

I also saw your bug report from when this seemed to occur in Lucid, and tried your PPA, with no success.

My team member identified some SDL code that may help:
https://github.com/ProfessorKaos64/RetroRig/issues/86

He notes:

"Let me know how this works for you! I take for the centering issue tomorrow, then I'm going to move libmupen64plus2_2.0-4_amd64.deb to our PPA and have it updated."

Besides what he found, what steps should I take to test your changes listed by your ppa? Should I add your ppa, then install the main package?

Thank you for your efforts

[Sven Eckelmann (sven-eckelmann)]

The lucid bug is fixed since ages in the package and was happening in a complete different place.

Something like the stuff from the patch is already part of the 2.0-7 package that I've uploaded this morning. Did you test libmupen64plus_2.0-7 or an older version. Btw. the package mupen64plus is only a meta package and no useful information can be gathered by querying the package information from it.

The patch posted in https://github.com/ProfessorKaos64/RetroRig/issues/86#issuecomment-52029163 contains a lot of code regarding SDL_VIDEO_FULLSCREEN_HEAD which is already handled by SDL2 and seems to work here out-of-the-box (without this extra code). I don't see why it would be necessary to reimplement this functionality inside mupen64plus-core. And this change makes it harder to see what actually is necessary to work around your problem.

[Sven Eckelmann (sven-eckelmann)]

Btw. you seem to already have my ppa added. So you can simply update libmupen64plus2 and test.

`apt-cache policy libmupen64plus2` should say "Installed: 2.0-7~ppa2~trusty"

[ProfessorKaos64 (mdeguzis)]

I tried your PPA yesterday by specifying the package:

apt-get install mupen64plus=2.0+1~ppa1~trusty (I believe that was it, at work now).

I saw the mupen64plus package is just a placeholder/meta package. In that sense, should I specify the individual packages to install this (i.e. mupen64plus-core, and so on), or is simply specifying your ppa above ok? Listing the packages from the PPA to install would help me, sorry to be a drag about this. I'll try to let my team member know this should be fixed as of yesterday and to test your changes.

I will take your direction though and update libmupen64plus2 when I get home from work. It, as well as the rest of your PPA packages were not installed at that specific time, since I was testing back and forth, as well as source compiling it all. Thank you for your time and patience Sven.

[Sven Eckelmann (sven-eckelmann)]

The PPA from yesterday didn't had the change. Please update libmupen64plus2 and not the mupen64plus meta package.

sudo add-apt-repository ppa:ppa:sven-eckelmann/ppa-mupen64plus
sudo apt-get update
sudo apt-get install libmupen64plus2='2.0-7~ppa2~trusty'

And I don't know if this really fixes your problem because I cannot reproduce it here. The used change can be found here: http://anonscm.debian.org/cgit/collab-maint/mupen64plus-core.git/tree/debian/patches/sdl2_fullscreen_fallback.patch

[Jens-Christian (beauman)]

Hello! Hope you don't mind if I chime in.

Sven, you're right. I now compiled libmupen64plus2 w/o any changes, just as is from github. It does not crash (with 2.0-4 I had the same crash as Michael had.)

And dual-head does also work. Even the fullscreening, which really confuses me. With mednafen we had to use SDL_FULLSCREEN_DESKTOP instead of SDL_FULLSCREEN.

That's the good news. An other good news is, that mupen now fullscreens over the complete display.

But, there's also bad news. Mupen now spoils the display settings. It leaves my normally 1920x1080p with a resolution of 1280x1024.

Sven, I like to stress this. We extremely appreciate your great support!! Many thanks!

Regards,
jc

[Jens-Christian (beauman)]

> With mednafen we had to use SDL_FULLSCREEN_DESKTOP instead of SDL_FULLSCREEN

Sorry, I mean SDL_WINDOW_FULLSCREEN_DESKTOP of course.

If I only change SDL_WINDOW_FULLSCREEN to SDL_WINDOW_FULLSCREEN_DESKTOP, the display resolution will not be changed upon game launch. The SDL canvas will be drawn on the left side of the display area.

[Sven Eckelmann (sven-eckelmann)]

When you use upstream source then please contact upstream. And yes, mupen64plus tries to use the resolution specified inside the config. SDL_WINDOW_FULLSCREEN_DESKTOP will just use a large borderless window to simulate fullscreen but should not change the resolution.

I have now completely lost what you want to get done by me.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jens-Christian (beauman)]

> I have now completely lost what you want to get done by me.

Libmupen64plus2 2.0-4 crashes on our machine. Somebody needs to update it the upstream version.

[Sven Eckelmann (sven-eckelmann)]

This cannot be done by me because I am not an Ubuntu maintainer. And I doubt that it will be done by anyone because the LTS system will not really receive new versions of most software packages (which aren't released yet btw). So in my propose would be to find what needs to be changed (needs to be as small as possible) to get it working and then find an Ubuntu MOTU guy to get the fix uploaded.

Btw. all changes of the vidext part in the git of mupen64plus-core are already in 2.0-5, 2.0-6 and 2.0-7 (libmupen64plus2). So the first step is to test them. mdeguzis seems to only have updated the meta package and never the libmupen64plus2. So no one tested it yet, right?

[ProfessorKaos64 (mdeguzis)]

> I will take your direction though and update libmupen64plus2 when I get home from work.

I cannot test this until I get home, as noted. I will do as you asked as soon as I can get time. I'll let you know if doing as you asked earlier works for me or not.

[Jens-Christian (beauman)]

Hello Sven!

Just as feedback, it works with version 2.0-7~ppa2~trusty from your PPA (ppa:sven-eckelmann/ppa-mupen64plus).
It does not crash any more, and dual-head works. Very nice!

Concerning SDL_WINDOW_FULLSCREEN_DESKTOP, we definitely need this in our project. We have two programs that run in fullscreen mode at the same time, and only SDL_WINDOW_FULLSCREEN_DESKTOP ensures that the later one goes on top of the first one. You don't need to worry about all this, we'll fork libmupen64plus2 to our own PPA.

Thanks for your hint about SDL_VIDEO_FULLSCREEN_HEAD, this will reduce our code changes immensely! :-D
And thanks for your support in general!

Regards,
jc

[Sven Eckelmann (sven-eckelmann)]

Ok, thanks for the test. But now we don't know how to close this bug. Can you try to install 2.0-5 manually with dpkg? When this works then you can request an SRU - https://wiki.ubuntu.com/StableReleaseUpdates

wget https://launchpad.net/~sven-eckelmann/+archive/ubuntu/ppa/+build/5949363/+files/libmupen64plus2_2.0-5~ppa1~trusty_amd64.deb
dpkg -i libmupen64plus2_2.0-5~ppa1~trusty_amd64.deb

If this version also works then following patches have to be included in the SRU:

http://anonscm.debian.org/cgit/collab-maint/mupen64plus-core.git/tree/debian/patches/sdl2_no_surface.patch?id=57075c090fdb3aaf4fbb23e531e947b941abe0ea
http://anonscm.debian.org/cgit/collab-maint/mupen64plus-core.git/tree/debian/patches/sdl2_destroywindow.patch

If it is not working then following patch must also be included:

http://anonscm.debian.org/cgit/collab-maint/mupen64plus-core.git/tree/debian/patches/sdl2_fullscreen_fallback.patch?id=57075c090fdb3aaf4fbb23e531e947b941abe0ea

There were many other patches in the 2.0-5 upload but they are all unrelated. http://anonscm.debian.org/cgit/collab-maint/mupen64plus-core.git/tree/debian/changelog?id=af92dafdfa758b06f4035340352d04ab861d9269

[Jens-Christian (beauman)]

Confirmed, libmupen64plus2_2.0-5~ppa1~trusty_amd64.deb is also OK.

Also, (Sven I hope this is not too confusing for you now, but it's cool that you are with us) this works ** without ** SDL_WINDOW_FULLSCREEN_DESKTOP, when I set "ScreenWidth" and ScreenHight" in mupen64plus.cfg
to the actual display settings in advance.

However, it's not possible to set these values to zero to have mupen64plus figure them out automatically.
That would be ideal, then switching displays in our home theater program and passing them down to mupen64plus
could just be done via the environment variable SDL_VIDEO_FULLSCREEN_HEAD, and without any additional measures.

[Sven Eckelmann (sven-eckelmann)]

Fixed in 2.0-5 which was uploaded to Debian 6 months ago and Ubuntu synced it nearly four months ago

Uploads to trusty have to be requested through SRU (team "MOTU Stable Release Updates")

[Sven Eckelmann (sven-eckelmann)]

you can for example change the new resolution via --resolution parameter. By default a size of 640x480 is hardcoded in the video plugins and all video plugins are currently only forcing a size and don't correct themself when the returned window has a different size. This is (imho) not trivial to change. I think you have to talk to upstream to get the complete design of the resolution handling (and maybe even the plugin api) changed.

Maybe rice could work with an resize event after the window was created but at least all other plugins don't support resizing.

[Sven Eckelmann (sven-eckelmann)]

Here is a debdiff for trusty-proposed with the most relevant patch

I have also uploaded it to the ppa so you can retest that this patch really fixes the problem. A sponsor for this change has to be found. The launchpad team ubuntu-sponsors has to be subscribed to this bug to find one.

wget https://launchpad.net/~sven-eckelmann/+archive/ubuntu/ppa-sru/+build/6267431/+files/libmupen64plus2_2.0-4ubuntu0.1~ppa1~trusty_amd64.deb
sudo dpkg -i libmupen64plus2_2.0-4ubuntu0.1\~ppa1\~trusty_amd64.deb

[Sven Eckelmann (sven-eckelmann)]

The bug is also not yet nominated for Trusty. This seems to be done now by the "bug supervisors" https://answers.launchpad.net/launchpad/+question/140509

It seems to already done by you and the bug wasn't nominated. At least when I understand your comment https://github.com/ProfessorKaos64/RetroRig/issues/86#issuecomment-52130286 correctly.

[ProfessorKaos64 (mdeguzis)]

I tried to get a hold of someone via the #ubuntu-bugs channel, but I will try to take the other route of emailing them via the main team page tonight with all this information. Nobody responded to me on IRC overnight.