Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • ParaView ParaView
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,962
    • Issues 1,962
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 98
    • Merge requests 98
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ParaViewParaView
  • ParaViewParaView
  • Issues
  • #12187
Closed
Open
Issue created May 11, 2011 by Kitware Robot@kwrobotOwner

Crash in Exodus reader's ReadMetaDataFile

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


I have a .bin file that I want to open with the raw image reader. Paraview doesn't recognize the .bin extension though, so it presents me with a list of readers to choose from. In order to compile the list of available readers, paraview calls CanReadFile("test.bin") on every reader. When it gets to the vtkExodusFileSeriesReader there is a crash.

It goes:

  1. vtkFileSeriesReader::CanReadFile("test.bin")

  2. if (this->UseMetaFile) <-- true

  3. vtkFileSeriesReader::ReadMetaDataFile("test.bin")

This routine opens test.bin as an ifstream and reads the contents into a std::string: metafile >> fname; Now fname contains garbage, because this is a raw image file.

  1. vtkExodusIIReader::CanReadFile()

This routine fails to open the file, tries to create an error message and calls strcpy on the garbage value and crashes.

So this can be avoided if we check that metafile >> fname reads only ascii characters. One solution is adding:

for (size_t i = 0; i < fname.size(); ++i)
  {
  if (static_cast<unsigned char>(fname[i]) > 127)
    {
    return 0;
    }
  }

Is it ok to call metafile >> fname on binary files? We could read metafile character by character instead of checking fname after the fact. Are there any scenarios where metafile uses a non ascii text encoding that should be supported?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking