Support for Virtual Box GL implementation

[Andrea Azzini]

My testing machine is a Debian Lenny (testing) x64 virtual machine running as a guest on VirtualBox 3.1.8 on a Windows 7 x64 host. Iceweasel is version 3.5.9 with Lightspark 0.3.5. The VM has all VirtualBox extensions installed, and OpenGL 2.0 is supported (see glewinfo output attached).

When loading a random page with a video on Youtube, Firefox logs the following lines to console:

OpenGL Warning: glXChooseFBConfigSGIX not implemented by Chromium
OpenGL Warning: glXChooseFBConfigSGIX not implemented by Chromium

(why Chromium?)
and then dies with a Segmentation Fault.

Backtrace and glewinfo output are attached.

[Alessandro Pignotti (a-pignotti)]

The Chromium bit is quite weird. I think the issue may be related to glXChooseFBConfig being not able to find a suitable configuration. I'll try to reproduce the issue in a week or so.

[Alessandro Pignotti (a-pignotti)]

Hi Andrea, the upcoming release includes in the README how to compile in debug mode, would you give it a try?

[Andrea Azzini (andreazzini)]

OK, I compiled the plugin in debug mode and made youtube crash firefox once again inside gdb. The full output (both from iceweasel and from gdb, interleaved) is attached. Having repeated this trial a few times, I can add that the only line consistently being logged is the last ERROR: Falling back (...).

[Alessandro Pignotti (a-pignotti)]

Please try with 0.3.7-ubuntu2

[Andrea Azzini (andreazzini)]

Died again, this time apparently at a later point of loading the video, and with a different log and signal (SIGABRT). Log attached. It can't find a suitable GL configuration. Do I need to check anything else in my machine to be sure that the right API is actually supported?

[Alessandro Pignotti (a-pignotti)]

Try current revision, I've fixed a very stupid mistake

[Andrea Azzini (andreazzini)]

Checked again, same crash as in the dump posted as comment #7.
I attach my glxinfo output for further info on the machine's abilities.

Btw it appears that "Chromium" referred to http://en.wikipedia.org/wiki/Chromium_(computer_graphics) rather than http://en.wikipedia.org/wiki/Chromium_(web_browser) .

[Alessandro Pignotti (a-pignotti)]

Andrea, would you try changing line swf.cpp:1060 from
int attrib[10]={GLX_BUFFER_SIZE,24,GLX_DEPTH_SIZE,24,None};
to
int attrib[10]={GLX_BUFFER_SIZE,24,GLX_DEPTH_SIZE,16,None};

thanks.

[Alessandro Pignotti (a-pignotti)]

The issue depends on the Chromium GL implementation, used in VirtualBox. I'm changing to a Wish

[Robin Green (greenrd)]

Please could you at least return NULL instead of aborting, until this wish is granted.

[Andrea Azzini (andreazzini)]

I still confirm this bug on
- Host: Windows 7 x64 with hardware virtualization support, VirtualBox 4.0.10
- Guest: Ubuntu Natty x64 fully patched, Virtualbox Guest Additions 4.0.10
- Firefox 5.0+build1+nobinonly-0ubuntu0.11.04.2
- Lightspark 0.5.0~rc1-0ubuntu1~ppa12

Test URL: http://www.youtube.com/watch?v=OCQ5DTR5nb0

Also downloaded the SWF file and tested it from the local filesystem, using the lightspark binary with '-l 4'. Log attached.

The problem appears to be still the same.

[Andrea Azzini (andreazzini)]

Tested again with the same test case from last time (the swf file downloaded from youtube).

Differences: VirtualBox + additions updated to 4.0.12.
This time I built it from the latest git source. With llvm-2.8 it wouldn't compile, so I went for llvm-2.7. I only tested with the standalone binary.

This test ended with a SIGSEGV and what looks like a corrupt stack. I have attached the stdout log (-l 4) and the gdb log with backtrace, stitched into one.

[Alessandro Pignotti (a-pignotti)]

Could you provide a backtrace with a debug enabled build? It seems that one of the GL functions used is not being defined

cmake -DCMAKE_BUILD_TYPE=Debug <etcetc> should do the trick.

[Andrea Azzini (andreazzini)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdf16a700 (LWP 4000)]
0x0000000000000000 in ?? ()
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff72985c3 in lightspark::RenderThread::commonGLInit (this=0x6dcae0, width=480, height=385)
    at /home/andrea/lightspark/src/backends/rendering.cpp:529
#2 0x00007ffff7296d61 in lightspark::RenderThread::worker (th=0x6dcae0) at /home/andrea/lightspark/src/backends/rendering.cpp:263
#3 0x00007ffff55d1d8c in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007ffff58cf04d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#5 0x0000000000000000 in ?? ()

[Alessandro Pignotti (a-pignotti)]

The issue is now a duplicate of bug #626479. We would need compatibility with EXT FBOs while currently only ARB FBOs are supported currently