0

This question is about how to be a good citizen in an open source community, and do my part to effectively participate, to advance the project/not harass people.

I am building a medium-sized C++ project at work. My toolchain is the Clang with LLVM 15.0.7 on 64-bit Windows (the most recent LLVM release for Windows on the day I am posting this). And I am perhaps unwisely deciding to port my codebase from "C++ with headers" to C++20 with modules. Clang 15 supports modules, according to the status page and release notes. So, I should be able to do that.

Unfortunately I am finding that Clang with C++ modules is unstable. That means, as I try to tweak things in my modules code, I get lots of backtrace messages from crashed invocations of Clang. Sometimes I can discover a tweak that allows me to do what I really want - just keep coding - and just not crash Clang. And also, sometimes not, and I am stuck not knowing why Clang crashes and I cannot continue. The point is, on any given workday lately, I am looking at Clang crash messages all day (while I do continue to develop the parts of the project I can develop).

Now, the crash message says this:

clang++ --config .\desktop.cfg  -c -o detector_event_handlers.obj ../src/detector_event_handlers.cpp
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: clang++ --config .\\desktop.cfg -c -o detector_event_handlers.obj ../src/detector_event_handlers.cpp
1.      <eof> parser at end of file
Exception Code: 0xC0000005
 #0 0x00007ff7918c589c C:\Program Files\LLVM\bin\clang++.exe 0x198589c C:\Program Files\LLVM\bin\clang++.exe 0x19b5d4d
 #1 0x00007ff7918c589c C:\Program Files\LLVM\bin\clang++.exe 0x198b3f0 C:\Program Files\LLVM\bin\clang++.exe 0x19b63ce
... (continues for many lines)

Now I, wanting to help (and maybe even get some support from the Clang community too!), followed the instructions begging me to open a GitHub issue. (Here are the issues I have opened so far: 60981, 61063, 61068. I have tried to create "complete" issues, i.e. with enough information/example code for anyone to attempt to reproduce my problem, inside each issue. So StackExchange community members looking for the specifics about what Clang crashed on for me, please follow me over to GitHub, thank you.)

Now the LLVM project has more than 5000 open issues and there has not been high engagement on the 3 issues I have opened. So, the question: Should I submit more issues with more crash messages (because I get them every day), as requested in the crash message? Is that helpful, or is that spamming? What does the LLVM community want?

Relatedly, how bummed should I be that Clang is greatly unstable on a feature which, according to the release notes, is supported in this release? It's a full Clang release, not a nightly. I am not a LLVM developer and I do not know how they test LLVM before cutting a release. But in one of my GitHub issues, I cut-and-pasted the modules "Hello World" project from Clang's own v15 documentation, proved that it crashed, and posted this as an issue. Like, I think I should expect that the most basic example from the full-release documentation is not supposed to crash the full-release compiler. Or, if that is really too much to expect, just tell me to calm down, ha ha.

1
  • Well, you learned a lesson: before always switching to "the latest and the greatest" feature of a platform, give it a few years to become stable. Good Software Takes Ten Years.
    – Doc Brown
    Commented Mar 8, 2023 at 8:34

1 Answer 1

3

Should I submit more issues with more crash messages (because I get them every day), as requested in the crash message?

No. Submitting additional bug-reports for crashes in the same feature will not help you in getting the problem fixed. On the contrary, it may slow things down, as each bug report needs to be evaluated if it is a duplicate of another or if it is reporting a different problem and that evaluation takes time as well.

If you don't have the inclination/time/expertise/whatever to dive into the LLVM code and help the maintainers find the rootcause of the problem, then your best course of action is to monitor the bug reports you have already submitted (so you can answer any questions that arise, or try again when the bugs are reported to be fixed) and in the mean time accept that the release notes were too optimistic and that the feature is still too unstable for your use-case.

Also, instead of submitting new bug reports, you can update existing bug reports with additional information that you find, if you think that information might help in resolving the bug.

2
  • And perhaps keep in mind that the people, working on those bugs, are very likely not getting paid for it, but work on them in their spare time.
    – JanRecker
    Commented Mar 8, 2023 at 8:21
  • 1
    Or, for a project like Clang it is more likely that they do get paid for it, but not by you, so they prioritize their time based on who pays them. For example, Clang has many Apple developers on it, but they will focus on bugs that impact Clang's integration with Xcode, code generation for M1 and M2, etc. Commented Mar 8, 2023 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.