> Ideally, valgrind would have a way to distinguish static memory allocations
> from leaks (where by "leak" I mean an allocation that would accumulate when
> the code is run repeatedly). How could such a distinction be implemented,
> without multiplying the time needed to run the test by a factor o
On 10/10/18 7:05 AM, Tim Rühsen wrote:
Given Paul's statement "Besides, debugging tools come and go...": this
means with 100 such tools we (or the people who care) would need to
write and maintain 100 exception files.
Exception files are not the only way to suppress false positives. It
would
7;s test suite also pass with NLS enabled, in a locale other
than the "C" or an English locale, without harmless memory leaks?
Bruno
Hello all,
You raise many good points, both for and against.
In this specific case, the fix is rather simple and costs very little.
would you consider it?
With it, sed and sed's gnulib testsuite passes all tests under SASN,
which is a nice bonus (and will also prevent false reports in the
futur
Hi Tim,
There is no way to avoid not-serious memory leaks in the long run.
1) There are API functions like bindtextdomain(), textdomain()
which are supposed to keep information until the process terminates.
2) There are certain tasks like reading an initialization file (think
of
On 10/10/18 11:10 AM, Bernhard Voelker wrote:
> On 10/9/18 7:37 PM, Paul Eggert wrote:
>> If we want to silence these diagnostics we can either complicate the source
>> code or complicate the debugging tool.
>
> I'm fine with either. Myy only concern is that code from the gnulib tests
> might
>
On 10/9/18 7:37 PM, Paul Eggert wrote:
> If we want to silence these diagnostics we can either complicate the source
> code or complicate the debugging tool.
I'm fine with either. Myy only concern is that code from the gnulib tests might
be taken as basis for application code. Still, it's the r
Tim Rühsen wrote:
The GNU standards [1] say so as well:
"Memory analysis tools such as valgrind can be useful, but don’t complicate
a program merely to avoid their false alarms. For example, if memory is used
until just before a process exits, don’t free it simply to silence such a
to
On 10/9/18 5:22 PM, Bruno Haible wrote:
>> I don't intend to do anything about the not serious ones.
>
> The GNU standards [1] say so as well:
> "Memory analysis tools such as valgrind can be useful, but don’t complicate
>a program merely to avoid their false alarms. For example, if memory i
> I don't intend to do anything about the not serious ones.
The GNU standards [1] say so as well:
"Memory analysis tools such as valgrind can be useful, but don’t complicate
a program merely to avoid their false alarms. For example, if memory is used
until just before a process exits, don’
Hello Assaf
> It is a long tradition not to bother freeing memory in such cases
Yes. I remind the distinction between "not serious" and "serious"
memory leaks (as defined in https://en.wikipedia.org/wiki/Memory_leak ),
and I don't intend to do anything about th
Hello gnulib,
'deltatau' recently reported 3 memory leaks detected in gnulib's test in
sed [1]. This was found using our recent ASAN build feature [2].
[1] https://bugs.gnu.org/32685
[2]
https://git.savannah.gnu.org/cgit/sed.git/commit/?id=0cc0ade4237b8db69f5253c3d933f9890b6
Although relocate() in practice does not produce memory leaks (in the
sense of _repeated_ loss of memory blocks), it is sufficiently often reported
by analysis tools (valgrind, coverity) that I'm now doing something against it.
2017-05-16 Bruno Haible
relocate: Make it easi
Thanks for the fix; I installed it into gnulib and am closing this bug
report.
On Wed, 18 Jan 2017 23:11:28 +0200
Arnold Robbins wrote:
> Hi Grep Guys.
>
> Please:
>
> clone gawk repo
> cd gawk
> ./bootstrap.sh && ./configure && make -j
> make valgrind
>
> Look at the 'definitely lost' lines. For example:
>
> ==30472== 240 bytes in 2 blocks are
On 06/01/2014 12:39 AM, Geoff wrote:
> I am (would be) _very_ happy - ecstatic even - about my present situation. My
> concern is one regarding certain memory leaks I found I could not avoid with
> regard to parent processes. I had hoped to limit the page tables accessed by
>
I am (would be) _very_ happy - ecstatic even - about my present situation. My
concern is one regarding certain memory leaks I found I could not avoid with
regard to parent processes. I had hoped to limit the page tables accessed by
these parent processes; although it appears I may not have
Thanks, I pushed that.
s(-)
diff --git a/ChangeLog b/ChangeLog
index 8fa880d..30b364b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2014-03-26 Bernhard Voelker
+
+ modechange: avoid memory leaks for invalid octal modes
+ * lib/modechange.c (mode_compile): During the parsing of
+ notations like
On Wed, 8 Nov 2006, Paul Eggert wrote:
> "Joel E. Denny" <[EMAIL PROTECTED]> writes:
>
> > Most importantly, the end of the patch includes a small change to
> > lib/quotearg.*, which I see are part of gnulib. I'll need some guidance
> > on whether that change makes sense for gnulib in general
"Joel E. Denny" <[EMAIL PROTECTED]> writes:
> Most importantly, the end of the patch includes a small change to
> lib/quotearg.*, which I see are part of gnulib. I'll need some guidance
> on whether that change makes sense for gnulib in general and on what to do
> with it.
OK, on further thou
21 matches
Mail list logo
