Memory bug during graphics initialization (OCC6.5.3) ?
Memory bug during graphics initialization (OCC6.5.3) ?
Mark Blome
2012/09/01 15:56
Hi everybody,
I'm having an issue during graphics display initialization
in OCC 6.5.3 on Linux and Mac OS X that was not present in OCC 6.5.0.
For the GUI I develop (through PythonOCC) I repeatedly create (and subsequently destroy)
graphics displays using something like:
short hi = static_cast<short>(window_handle >> 16);
short lo = static_cast<short>(window_handle);
gd = new Graphic3d_GraphicDevice(std::getenv("DISPLAY"));
myWindow =new Xw_Window(gd,static_cast<Standard_Integer>(hi),static_cast<Standard_Integer>(lo),Xw_WQ_3DQUALITY);
myV3dViewer = new V3d_Viewer( gd , (short* const)"viewer" );
myV3dViewer->Init();
and so on …
This typically works the first few times after program start without any issues,
but then fails (unpredictably) at line
gd = new Graphic3d_GraphicDevice(std::getenv("DISPLAY"));
with error messages like
_X11TransOpen: Unable to find transport for <an invalid DISPLAY variable>
that are caused by the (initially correct) DISPLAY variable being scrambled by what
seems to me a memory bug in OSD_Environment.cxx (presumably in function Build())
From the line above I traced this issue down to
1) Graphic3d_GraphicDevice.cxx: In constructor at line 75
status = MyGraphicDriver->Begin (connexion);
2) OpenGl_GraphicDriver_1.cxx: In Begin at line 38
openglDisplay = new OpenGl_Display(ADisplay);
3) OpenGl_Display.cxx: In constructor at lines 75-76
OSD_Environment aDispEnv ("DISPLAY", theDisplay);
aDispEnv.Build();
After destruction of "aDispEnv" the content of "theDisplay" is scrambled,
which subsequently leads to the graphic initialization to fail (in Graphic3d_GraphicDevice constructor, "connexion" is scrambled as well).
I assume there is something going wrong in OSD_Environment::Build() function. If I uncomment the
two lines in OpenGl_Display.cxx the issue disappears on Linux and Mac OS X (the DISPLAY environment variable is present anyway). Am I doing something wrong here ?
