Hangs when there are less elements than the header defines
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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