bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: results of gnulib tests with -fsanitize=address


From: Bruno Haible
Subject: Re: results of gnulib tests with -fsanitize=address
Date: Sun, 21 May 2017 20:28:32 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-75-generic; KDE/5.18.0; x86_64; ; )

Paul Eggert wrote:
> I was worried more about something like this: a test for feature X has a 
> subtest 
> for feature Y that fails, then the feature-X test calls fclose but fclose 
> doesn't free the storage because of the feature-Y failure, so then the test 
> for 
> X falsely fails because of the leak. I don't want us to get into the business 
> of 
> debugging fclose internals merely when we're trying to test for feature X. 
> This 
> is partly why I stopped sanitizing tests last year.

I'm not sure I understand.
- Do you mean fclose() could have some bugs that we don't know about yet? I
  would better like to know about them.
- Do you mean our tests are so complex that we wouldn't call fclose correctly?
  Well, our FILE* tests are simple: They open only one FILE* at a time.
  Only our tests with file descriptors are more complex (dup2.m4 and fcntl.m4
  in particular), but no sanitizer requires us to avoid file descriptor "leaks".

> Admittedly I don't have any concrete examples of this right now, but if the 
> issue starts cropping up then I suspect I will still favor advising people to 
> avoid leak-testing when running "configure", rather than bothering to plug 
> leaks 
> in the tests. Leaks are not always bugs.

This advice is good anyway, because we have only fixed the autoconf tests in
gnulib, not the ones that come from the package that uses gnulib.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]