[fuzz, binary] Assertion `StartColNo <= map.getSourceLine().size() && "Invalid range!"' failed.

[llvmbot]

Bugzilla Link	21953
Version	trunk
OS	Linux
Blocks	#23431
Attachments	test case
Reporter	LLVM Bugzilla Contributor
CC	@Keno,@nico

Extended Description

Fuzzing discovered that the attached test case, which contains non-printable characters, when given as input to

clang -fno-crash-diagnostics -std=c++11 -xc++ -c -emit-llvm

causes this assertion failure:

clang-3.6: tools/clang/lib/Frontend/TextDiagnostic.cpp:972: void highlightRange(const clang::CharSourceRange&, unsigned int, clang::FileID, const {anonymous}::SourceColumnMap&, std::string&, const clang::SourceManager&, const clang::LangOptions&): Assertion `StartColNo <= map.getSourceLine().size() && "Invalid range!"' failed.

[Keno]

I spent some time looking at this bug today. The reason this is happening is because when computing the line to show for the diagnostic we truncate at the first '\0' we encounter. This seemed like an easy fix, but then I saw that that had already been done once in r154981, which was reverted due to #13046 . I'd recommend reading the discussion there, but the gist is that scratch buffers have a bunch of zeros that we don't want to print. I really don't know what the right solution here is. Ideally I think you'd want to do something about the scratch buffer case, since in normal source files you probably do want to print null characters in the diagnostics such that the use can notice something is fishy. On the other hand, to at least fix this test case, one thing one could do is to only ignore trailing null bytes. That would work for this case, but I'm not convinced that there isn't a case where you can run into trouble there as well.

[kcc]

mentioned in issue #23431

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[Endilll]

Appears to be fixed in Clang 3.9. Doesn't reproduce on Compiler Explorer, only locally.