Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • VTK VTK
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 830
    • Issues 830
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 240
    • Merge requests 240
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • VTKVTK
  • VTKVTK
  • Issues
  • #385
Closed
Open
Issue created Nov 16, 2003 by Kitware Robot@kwrobotOwner

Crash in vtkRenderer::Render() when backing store is on

This issue was created automatically from an original Mantis Issue. Further discussion may take place here.


If you activate the backing store (by calling vtkRenderer::BackingStoreOn()), and then quickly enlarge the window, the application will sometimes crash with a segmentation fault.

To reproduce the bug, you can use the attached tcl file (a modified version of Cone5.tcl). Grab the right side of the window and quickly move it left-right. If you are (un)lucky the application will crash.

I tracked the bug down to the vtkRenderer::Render() function. It does a series of checks to see whether the backing store is still valid. It doesn't check whether the size of the window has changed. It then copies the data from the backing store to the window, using the current size of the window. If the window size is bigger, it will copy more data than what was stored in the buffer. Depending on what is in memory after the buffer, this results in a crash, or just some garbage on the screen (that is cleared by the next render).

I'm attaching a simple patch that fixes the problem. It stores the previous size of the render window and uses the backing store only if the size hasn't changed.

Assignee
Assign to
Time tracking