Menus don't work on Allegro 5 build (Ubuntu 18.04 amd64 as VirtualBox guest) about b-em HOT 15 CLOSED

Emulated machine's window not changing its place in the window stacking order but the menu bar doing so is similar to something I noticed years ago on video playing apps where the video output part was being overlayed onto the screen though a different route, DRI perhaps, while the controls were being drawn with standard X11 calls.

So, one obvious question - is this x.org or Wayland? Which graphical environment (GNOME, KDE etc)?

from b-em.

Thanks for coming back to me so quickly!

I chose the MATE desktop during the Ubuntu 18.04 install (which I only did yesterday; this is a new VM). I'm pretty sure it's x.org not Wayland - there's an Xorg process running. Not sure if this answers your question fully, but FWIW:

steven@ubuntu:~/src/b-em$ ps axf | grep -i mate
2682 ? Ssl 0:00 _ mate-session
3039 ? Ss 0:00 _ /usr/bin/ssh-agent /usr/bin/im-launch mate-session
3126 ? Sl 0:01 _ /usr/bin/mate-settings-daemon
3150 ? Sl 0:01 _ mate-panel
3478 ? Sl 0:12 | _ mate-terminal
17235 pts/0 S+ 0:00 | | | _ grep --color=auto -i mate
3167 ? Sl 0:00 _ mate-maximus
3176 ? Sl 0:00 _ mate-screensaver
3192 ? Sl 0:00 _ /usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1
3195 ? Sl 0:00 _ mate-power-manager
3157 ? Sl 0:01 _ /usr/lib/mate-panel/wnck-applet

Looking at the ps axf output as a whole, there is a lightdm process which is the parent of mate-session.

I hope this helps, let me know if you want me to try anything else!

from b-em.

PS I guess in hindsight the b-em menus could be appearing but hidden by the emulated machine output, which seems to persistently be drawn in front of everything else, probably including the menus. So that would mean this is all one bug. I guess that's pretty much what you're saying anyway, but I thought I'd make the inference explicit just in case.

from b-em.

Ok, I may not have time this evening to try your exact setup, i.e. that specific version of B-Em on Mate on Ubuntu 18.04, but I did quickly install the mate desktop on my existing Arch Linux machine and tested the master B-Em and it worked as expected.

I think you may be onto something with the emulated screen being drawn on top of everything else because the emulated machine is redrawing this screen continuously. If that is the issue it could be a bug with whatever mate uses as its window manager, but then that has to be a different version on Ubuntu 18.04 compared to Arch, or it could be a bug in the direct rendering implementation in that it is failing to apply clipping limits to the emulated screen. As OpenGL is possibly accelerated by drivers for the specific video card that may mean a driver bug, so in this case with VirtualBox, possibly a VirtualBox bug. Does it make any difference if you change the VirtualBox options for accelerated 2D and 3D graphics?

from b-em.

Here's what it looks like before emulation starts where you can see that the main emulator part of the screen is being treated separately from the UI sections. The main emulator section drawns when it wants to, not in response to X11 expose events (paint events on Windows).

from b-em.

I didn't have the 2D acceleration on anyway as VirtualBox says it is only for Windows guests. I did have the 3D acceleration on and had previously been heartened to find most stuff was working, but turning it off certainly fixes this problem with b-em.

Is there any way this can easily be turned into something which is worth reporting upstream? I am not optimistic about getting a bug related to VirtualBox 3D support for Linux guests fixed, but it would be nice to try if it's easy.

Incidentally, just while playing around with the menus (love the new look, by the way, compared to the old F11 white menu bar with tiny text), if I select the "BBC Master 128 w/ MOS 3.5" option, b-em immediately aborts:
steven@ubuntu:~/src/b-em$ ./b-em
double free or corruption (!prev)
Aborted (core dumped)

Running under gdb:

steven@ubuntu:~/src/b-em$ gdb ./b-em
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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 ./b-em...done.
(gdb) run
Starting program: /home/steven/src/b-em/b-em 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeab38700 (LWP 2061)]
[New Thread 0x7fffe853a700 (LWP 2062)]
[New Thread 0x7fffe7d39700 (LWP 2063)]
[New Thread 0x7fffe7538700 (LWP 2064)]
[New Thread 0x7fffe68f0700 (LWP 2065)]
[New Thread 0x7fffd6aa5700 (LWP 2066)]
[New Thread 0x7fffd62a4700 (LWP 2067)]
[New Thread 0x7fffd5aa3700 (LWP 2068)]
[New Thread 0x7fffd509a700 (LWP 2069)]
[New Thread 0x7fffa3444700 (LWP 2070)]
[New Thread 0x7fffa2c43700 (LWP 2071)]
[New Thread 0x7fffa2442700 (LWP 2072)]
[New Thread 0x7fffa1c41700 (LWP 2073)]
[New Thread 0x7fffa1440700 (LWP 2074)]
[New Thread 0x7fffa0c3f700 (LWP 2075)]
[New Thread 0x7fff57fff700 (LWP 2076)]
[New Thread 0x7fff4b7fe700 (LWP 2077)]
[New Thread 0x7fff4affd700 (LWP 2078)]
[New Thread 0x7fff4a7fc700 (LWP 2079)]
[New Thread 0x7fff49ffb700 (LWP 2080)]
double free or corruption (!prev)

Thread 1 "b-em" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

I can raise a separate issue for this if you like...

from b-em.

PS For the record, the Windows host machine is using the integrated graphics in the Intel i5-2500K CPU; there's no discrete graphics card.

from b-em.

Yes, please split the double-free into a separate issue - I definitely want to fix that one but it is neater to have it separate.

I have the i5-3570K (desktop) and I am using the integrated graphics and not had the same trouble but I am running Linux on bare metal, not within VirtualBox. I assume the VirtualBox 3D acceleration is some kind of filtered pass-through to the underlying OpenGL implementation but means the VirtualBox filter has the capacity to introduce bugs.

from b-em.

Sure, I will create a new issue for the double free. I run Ubuntu on bare metal myself on my own PC, so once Ubuntu 18.04.1 comes out (in a month or so) I will upgrade from 16.04 and try b-em on that. That PC also has a Core i5-2500K and uses the integrated graphics, FWIW.

from b-em.

Did you get any further with this?

from b-em.

Sorry, I only just saw this. Unfortunately my PC's SSD died and I have been waiting for a replacement before I can re-install the OS, at which point I will have 18.04.1 and can try it. However, I have had similar issues with smplayer on the virtual machine I reported this issue on, unless I change it into the x11 rendering mode, so I'm fairly confident this is something wrong (or at least unusual which programs don't cope well with) with the virtualbox 3D support.

from b-em.

Sorry for leaving this so long; I do now have my main PC running Ubuntu 18.04.2 LTS on bare metal (Core it-i2500K, integrated graphics) and the current master branch of b-em builds and runs absolutely fine. I don't know if this is helpful or not. I haven't tried updating VirtualBox or b-em on the PC I was using when I raised this issue on recently, I could try that in a month or so if it would help.

from b-em.

Is this still and issue?

from b-em.

I don't think so; it's obviously pretty old now and I haven't noticed this specific problem in a while. Probably best to close this and if I notice anything strange under VirtualBox I can always open a fresh issue; it's unlikely to be exactly the same as this one. Thanks!

from b-em.

Thanks.

from b-em.