{"action":"opened","issue":{"url":"https://api.github.com/repos/aowen87/BAR/issues/2062","repository_url":"https://api.github.com/repos/aowen87/BAR","labels_url":"https://api.github.com/repos/aowen87/BAR/issues/2062/labels{/name}","comments_url":"https://api.github.com/repos/aowen87/BAR/issues/2062/comments","events_url":"https://api.github.com/repos/aowen87/BAR/issues/2062/events","html_url":"https://github.com/aowen87/BAR/issues/2062","id":388907256,"node_id":"MDU6SXNzdWUzODg5MDcyNTY=","number":2062,"title":"DISPLAY environment variable can cause VTK to hang in mangled mesa implementation, looking for GL extensions.","user":{"login":"aowen87","id":11658578,"node_id":"MDQ6VXNlcjExNjU4NTc4","avatar_url":"https://avatars0.githubusercontent.com/u/11658578?v=4","gravatar_id":"","url":"https://api.github.com/users/aowen87","html_url":"https://github.com/aowen87","followers_url":"https://api.github.com/users/aowen87/followers","following_url":"https://api.github.com/users/aowen87/following{/other_user}","gists_url":"https://api.github.com/users/aowen87/gists{/gist_id}","starred_url":"https://api.github.com/users/aowen87/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aowen87/subscriptions","organizations_url":"https://api.github.com/users/aowen87/orgs","repos_url":"https://api.github.com/users/aowen87/repos","events_url":"https://api.github.com/users/aowen87/events{/privacy}","received_events_url":"https://api.github.com/users/aowen87/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-12-08T10:01:46Z","updated_at":"2018-12-08T10:01:46Z","closed_at":null,"author_association":"OWNER","body":"From Gunther:\r\n\r\nI encountered a VisIt parallel engine hang on Hopper if the DISPLAY environment variable is set. I have resolved the immediate problem by unsetting this variable in internallauncher when running on Hopper. However, the hang occurs when the offscreen VTK tries to connect to the DISPLAY, which may point to a deeper VTK-related issue (since I would expect the offscreen version not to connect to the DIPSLAY at all.) I have discussed this issue with Tom Fogal (see below) and his comment is:\r\n\r\nTo whomever ends up looking at it: looks like the MesaExtMgr still has some X code in there.  We might want an OSMesaExtMgr subclass.  Or you can just remove the X code from the Mesa* classes altogether; we've broken all \"system\"  Mesa OpenGL use cases except for the system  OSMesa one anyway.  Feel free to ping me, I forget a lot of the details at present and it may come back to me if we start talking about it.\r\n\r\n\r\nFurther information:\r\n\"\r\nIf DISPLAY is set and rendering annotations is turned on, the parallel engine on Hopper hangs in \"VisWinRendering::PostProcessScreenCapture()\" when calling \"renWin->Render()\". renWin is a \"vtkOSOpenGLRenderWindow\" according to \"GetClassName()\". The call stack for the hang is\r\n\r\n1:  Engine::AlarmHandler(int)\r\n2:\r\n3:  __select\r\n4:\r\n5:  xcb_connect_to_fd\r\n6:  xcb_connect\r\n7:  _XConnectXCB\r\n8:  XOpenDisplay\r\n9:  vtkMesaExtensionManager::ReadOpenGLExtensions()\r\n10:  vtkExtensionManager::Update()\r\n11:  vtkMesaExtensionManager::ExtensionSupported(char const*)\r\n12:  vtkMesaTexture::Load(vtkRenderer*)\r\n13:  vtkTextActor::RenderOverlay(vtkViewport*)\r\n14:  vtkVisItAxisActor2D::RenderOverlay(vtkViewport*)\r\n15:  vtkTriad2D::RenderOverlay(vtkViewport*)\r\n16:  vtkRenderer::UpdateGeometry()\r\n17:  vtkMesaRenderer::DeviceRender()\r\n18:  vtkRenderer::Render()\r\n19:  vtkRendererCollection::Render()\r\n20:  vtkRenderWindow::DoStereoRender()\r\n21:  vtkRenderWindow::DoFDRender()\r\n22:  vtkRenderWindow::DoAARender()\r\n23:  vtkRenderWindow::Render()\r\n24:  VisWinRendering::PostProcessScreenCapture(ref_ptr<avtImage>, bool, bool)\r\n25:  VisWindow::PostProcessScreenCapture(ref_ptr<avtImage>, bool, bool)\r\n26:  NetworkManager::RenderPostProcess(std::vector<ref_ptr<avtPlot>, std::allocator<ref_ptr<avtPlot> > >&, ref_ptr<avtDataObject>&, int) const\r\n27:  IceTNetworkManager::Render(bool, std::vector<int, std::allocator<int> >, bool, int, int, bool)\r\n28:  RPCExecutor<RenderRPC>::Execute(RenderRPC*)\r\n29:  RPCExecutor<RenderRPC>::Update(Subject*)\r\n30:  Subject::Notify()\r\n31:  AttributeSubject::Notify()\r\n32:  MPIXfer::Process()\r\n33:  Engine::ProcessInput()\r\n34:  Engine::EventLoop()\r\n35:  Engine::PAR_EventLoop()\r\n36:  EngineMain(int, char****)\r\n37:  main\r\n38:  __libc_start_main\r\n39:  /scratch/scratchdirs/ghweber/visit-new_ghost/debug/exe/engine_par() [0x401489]\r\n\r\nTo figure out the call stack, I added a PrintCallStack to the alarm handler and added an \"alarm(60)\" before \"renWin->Render()\".\r\n\r\nDo you think it is worth digging deeper into this problem? Do you have any suggestions?\r\n\n\n\n\n\n\n-----------------------REDMINE MIGRATION-----------------------\nThis ticket was migrated from Redmine. As such, not all \ninformation was able to be captured in the transition. Below is\na complete record of the original redmine ticket.\n\nTicket number: 982\nStatus: Pending\nProject: VisIt\nTracker: Bug\nPriority: Normal\nSubject: DISPLAY environment variable can cause VTK to hang in mangled mesa implementation, looking for GL extensions.\nAssigned to: \nCategory: \nTarget version: \nAuthor: Brad Whitlock\nStart: 02/27/2012\nDue date: \n% Done: 0\nEstimated time: \nCreated: 02/27/2012 02:03 pm\nUpdated: 03/01/2012 08:14 pm\nLikelihood: 2 - Rare\nSeverity: 4 - Crash / Wrong Results\nFound in version: 2.4.0\nImpact: \nExpected Use: \nOS: All\nSupport Group: Any\nDescription:\n From Gunther:\r\n\r\nI encountered a VisIt parallel engine hang on Hopper if the DISPLAY environment variable is set. I have resolved the immediate problem by unsetting this variable in internallauncher when running on Hopper. However, the hang occurs when the offscreen VTK tries to connect to the DISPLAY, which may point to a deeper VTK-related issue (since I would expect the offscreen version not to connect to the DIPSLAY at all.) I have discussed this issue with Tom Fogal (see below) and his comment is:\r\n\r\nTo whomever ends up looking at it: looks like the MesaExtMgr still has some X code in there.  We might want an OSMesaExtMgr subclass.  Or you can just remove the X code from the Mesa* classes altogether; we've broken all \"system\" + Mesa OpenGL use cases except for the system + OSMesa one anyway.  Feel free to ping me, I forget a lot of the details at present and it may come back to me if we start talking about it.\r\n\r\n\r\nFurther information:\r\n\"\r\nIf DISPLAY is set and rendering annotations is turned on, the parallel engine on Hopper hangs in \"VisWinRendering::PostProcessScreenCapture()\" when calling \"renWin->Render()\". renWin is a \"vtkOSOpenGLRenderWindow\" according to \"GetClassName()\". The call stack for the hang is\r\n\r\n1:  Engine::AlarmHandler(int)\r\n2:\r\n3:  __select\r\n4:\r\n5:  xcb_connect_to_fd\r\n6:  xcb_connect\r\n7:  _XConnectXCB\r\n8:  XOpenDisplay\r\n9:  vtkMesaExtensionManager::ReadOpenGLExtensions()\r\n10:  vtkExtensionManager::Update()\r\n11:  vtkMesaExtensionManager::ExtensionSupported(char const*)\r\n12:  vtkMesaTexture::Load(vtkRenderer*)\r\n13:  vtkTextActor::RenderOverlay(vtkViewport*)\r\n14:  vtkVisItAxisActor2D::RenderOverlay(vtkViewport*)\r\n15:  vtkTriad2D::RenderOverlay(vtkViewport*)\r\n16:  vtkRenderer::UpdateGeometry()\r\n17:  vtkMesaRenderer::DeviceRender()\r\n18:  vtkRenderer::Render()\r\n19:  vtkRendererCollection::Render()\r\n20:  vtkRenderWindow::DoStereoRender()\r\n21:  vtkRenderWindow::DoFDRender()\r\n22:  vtkRenderWindow::DoAARender()\r\n23:  vtkRenderWindow::Render()\r\n24:  VisWinRendering::PostProcessScreenCapture(ref_ptr<avtImage>, bool, bool)\r\n25:  VisWindow::PostProcessScreenCapture(ref_ptr<avtImage>, bool, bool)\r\n26:  NetworkManager::RenderPostProcess(std::vector<ref_ptr<avtPlot>, std::allocator<ref_ptr<avtPlot> > >&, ref_ptr<avtDataObject>&, int) const\r\n27:  IceTNetworkManager::Render(bool, std::vector<int, std::allocator<int> >, bool, int, int, bool)\r\n28:  RPCExecutor<RenderRPC>::Execute(RenderRPC*)\r\n29:  RPCExecutor<RenderRPC>::Update(Subject*)\r\n30:  Subject::Notify()\r\n31:  AttributeSubject::Notify()\r\n32:  MPIXfer::Process()\r\n33:  Engine::ProcessInput()\r\n34:  Engine::EventLoop()\r\n35:  Engine::PAR_EventLoop()\r\n36:  EngineMain(int, char**)\r\n37:  main\r\n38:  __libc_start_main\r\n39:  /scratch/scratchdirs/ghweber/visit-new_ghost/debug/exe/engine_par() [0x401489]\r\n\r\nTo figure out the call stack, I added a PrintCallStack to the alarm handler and added an \"alarm(60)\" before \"renWin->Render()\".\r\n\r\nDo you think it is worth digging deeper into this problem? Do you have any suggestions?\r\n\n\nComments:\n\n"}}
{"actor":{"display_login":"aowen87"}}