Crash with remote scene loading when render window covering multiple displays

[antont]

We have a setup at the university where there is a huge display (basically a wall) built from 3x6 HD displays. There is a single PC running it, with some ATI card & Windows, and we were using it simply so that the windows desktop extends to all those displays.

Due to the known issue #545 it is not possible to use Ogre's (old) dx9 renderer on multiple displays, so I changed to OpenGL simply by editing the plugins.cfg (in Admino's current Rocket release -- that is AFAIK unmodified realXtend Tundra for the basics, only has additional modules too).

With OpenGL Tundra behaves fine on the huge displays, and local scenes open and run reliably (did not get a single crash during several hours of initial testing).

But when trying to load a remote scene (login to Meshmoon) it crashes systematically. The build did not seem to make any kind of dump or at least tell about it, only showed that the crash was in OgreMain.dll.

I did not debug/test extensively as we need to focus on creating the content for a show with that setup for next week, and with opengl + local loading it seemed reliable so we go with that.

Should be repeatable on any windows box with multiple displays. Or possibly just by switching to OpenGL rendering on windows, if it is just due to that and otherwise unrelated to multiple displays.

Tommi said that Admino bugfixing guys can take a look .. so I assign to Cvetan initially, do feel free to change the assignment in any way (if Ludo wants to pick up or whatever).

[jonnenauha]

I don't know if its a good idea to swap into OpenGL rendering with a windows build that has been built with DX enabled. I'd have to look more into the code, but OgreRenderingModule will certainly still run all the ifdeffed dx parts even if the dx renderer plugin is no loaded. Might be possible that there is a null ptr not checked and crashes there. Or simply something else.

This is what I mean https://github.com/realXtend/naali/blob/tundra2/src/Core/OgreRenderingModule/Renderer.cpp#L666. There we are inside DIRECTX_ENABLED code which will still run if you selected gl. If one of the various places in tundra does not have proper null checking like that it might crash. It might even crash inside Ogre on some type of queries during these dx guarded code.

Here is how you make a "full" OpenGL build on windows: https://github.com/realXtend/naali/blob/tundra2/CMakeLists.txt#L233 set this to false.

I didn't even know you can do that as we link to the dx renderer .lib so afaik you have to load dx renderer. Do you have both enabled in the client but then select opengl to really be used?

[Stinkfist0]

The last time (couple months ago) I used Tundra on Windows with Ogre OGL render system instead of a D3D9 one (as a slightly pedantic note DirectX != Direct3D, the latter is a subset of the former) it seemed to run perfectly fine. BTW there are convenient --opengl, --direct3d/--d3d, and --nullRenderer command line parameters for controlling the chosen Ogre render system.

Can one reproduce the crash with the current realXtend Tundra HEAD? Can you provide a scene to reproduce the crash?

[antont]

Thanks for the comments,

I just edited the Ogre plugins.cfg to disable d3d9 plugin loading, and left opengl in. Could try the cmdline args but is the end result the same? Everything was stable with local assets.

As for reproducing, I got it with every scene that tried to load remotely .. the Oulu3d and the Haukipudas church scenes iirc. Largely the same Oulu3d scene works locally -- is not totally identical data though as ran that without avatars etc.

[cvetan5]

@antont This is not reproducible on Mac OS X with 2 screens, so try first as @jonnenauha suggested to make a "full OpenGL build" and let me know if it produces the same results

[antont]

AFAIK I can not reproduce with an own build against Admino hosted scenes, though, as my own build would lack the Admino module required for the authentication. I don't have hosted scenes otherwise that could access remotely.

Also don't have a win build env currently at all, so can not do the build quickly either. Possibly later.

In the meantime, if some Admino dev can test similarily on windows, it might give some info. But is not urgent for us anymore, the event is already on and we are semi-happily running locally there to drive the big multidisplay thing.

[cvetan5]

Not reproducible on Windows build with ENABLE_DIRECTX set to 0, and OpenGL render system with two screens, so the issue remains solely on Windows build with DirectX enabled (#545)