This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Killing old dead bugs

On 07/17/2017 02:25 PM, Yuri Gribov wrote:
On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor <> wrote:
On 07/17/2017 02:14 AM, Yuri Gribov wrote:

Hi Mikhail,

On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev <>

Hi. Yes, bug maintenance is appreciated. See this message and replies
to it: .

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

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

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.


Firstly, thanks for detailed explanation.

What to do about bugs originating in upstream packages?  I noticed
they sometimes get closed with "RESOLVED MOVED" resolution
( but often this
does not happen and they just hang in tracker forever for no good

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).

I take your point.  I didn't realize closing bugs was restricted.
Given the work you've done on the bugs below (and elsewhere) you
should be able to close them.  If you aren't and would like to be
able to, please request it by emailing ((at
least I think that's the right way to go about it), or follow up
here and I'm sure someone with the right karma will make it happen.


The process for managing bugs is in more detail described here:

If you think it should be clarified in some way please feel free
to send in a patch.


* Bug 41992 - ICE on invalid dereferencing of void *
* Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
underlying type
* Bug 61693 - [asan] is not intercepting aligned_alloc
* Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
format mismatch between libasan and GCC
* Bug 78028 - ASAN doesn't find memory leak
* Bug 55316 - gcc/libsanitizer/asan/ error: #error
"Unsupported arch"
* Bug 78654 - ubsan can lead to excessive stack usage
* Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
headers (
* Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
* Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
* Bug 54123 - inline functions not optimized as well as static inline


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]