nmwsharp / nmwsharp/happly

Hangs when there are less elements than the header defines

Open Beginner friendly
#50 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
406
Forks
74
PR merge metrics
No merged PRs in 30d

Description

In parseASCII, we have this loop:

for (size_t iEntry = 0; iEntry < elem.count; iEntry++) {
  
  string line;
  std::getline(inStream, line);
  
  // Some .ply files seem to include empty lines before the start of property data (though this is not specified
  // in the format description). We attempt to recover and parse such files by skipping any empty lines.
  if (!elem.properties.empty()) { // if the element has no properties, the line _should_ be blank, presumably
    while (line.empty()) { // skip lines until we hit something nonempty
  	std::getline(inStream, line);
    }
  }
  
  // Do stuff with the line
}

The outer loop runs elem.count times, which is the number of elements the header says the file will have.

In the inner loop, we loop until we hit a non-blank line.

However, this means if we are at the end of the file when we call while (line.empty()), we will loop endlessly. This can occur when the actual number of elements is less than the number of elements the header specifies.

Here is an example file that will cause a hang:

ply
format ascii 1.0
element vertex 2
property float x
property float y
comment We tell it there are 2 elements but only provide 1
end_header
3 4 

Possible fix

  • Check for EOF when doing getline

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in the parseASCII function and reproduce the hang with the example PLY content from the issue, where the header declares two elements but only one is provided. Trace the getline calls at end of file and make the parser stop rather than loop indefinitely. Done means truncated input no longer hangs and valid ASCII PLY files still parse normally.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
data
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.