This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Killing old dead bugs
On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor <msebor@gmail.com> wrote:
> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>
>> Hi Mikhail,
>>
>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev <maltsevm@gmail.com>
>> wrote:
>>>
>>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>>
>>
>> Replies in your link suggest to leave a final comment in bugs with
>> explanatory suggestion to close them so that maintainers who read
>> gcc-bugs list hopefully notice them and act appropriately.
>> Unfortunately I found this to _not_ work in practice. Below you can
>> see a list of bugs I've investigated (and often bisected) in the past
>> weeks - none of them were closed by maintainers (or at least
>> commented).
>>
>> So I'm afraid we have to conclude that there's no working process to
>> close stale bugs in place (which may be one of the reasons of bugcount
>> growth).
>
>
> The informal process that some (most?) of us have been following
> is to close them with a comment explaining our rationale.
> It's good to fill in the Known to fail/Known to work versions if they
> can be determined. Mentioning the commit that fixed the bug as
> you did for the bugs below is ideal. Adding a test case if one
> doesn't exist in the test suite is also very useful, though quite
> a bit more work. In my experience, if a bug is closed that should
> stay open, someone usually notices pretty quickly and reopens it,
> so I wouldn't be too worried about doing something wrong.
Martin,
Firstly, thanks for detailed explanation.
What to do about bugs originating in upstream packages? I noticed
they sometimes get closed with "RESOLVED MOVED" resolution
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
does not happen and they just hang in tracker forever for no good
reason.
Actually what I tried to emphasize is that it's impossible for a
casual commiter (who does not have maintainer access to Bugzilla i.e.
rights to close bugs) to contribute to project by cleaning stale bugs,
because requests to close them are mostly ignored (because
maintainers, obviously, have much more interesting work to do).
> The process for managing bugs is in more detail described here:
>
> https://gcc.gnu.org/bugs/management.html
>
> If you think it should be clarified in some way please feel free
> to send in a patch.
>
> Martin
>
>
>>
>> * Bug 41992 - ICE on invalid dereferencing of void *
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
>> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
>> underlying type
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
>> * Bug 61693 - [asan] is not intercepting aligned_alloc
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
>> * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
>> format mismatch between libasan and GCC
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
>> * Bug 78028 - ASAN doesn't find memory leak
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
>> * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
>> "Unsupported arch"
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
>> * Bug 78654 - ubsan can lead to excessive stack usage
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
>> * Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
>> headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
>> * Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
>> * Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
>> * Bug 54123 - inline functions not optimized as well as static inline
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)
>>
>> -Y
>>
>