You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(1) |
2
(5) |
3
(1) |
|
4
(3) |
5
(1) |
6
(8) |
7
(7) |
8
(2) |
9
(2) |
10
(2) |
|
11
|
12
(8) |
13
(7) |
14
(14) |
15
(5) |
16
(8) |
17
(8) |
|
18
(12) |
19
(7) |
20
(2) |
21
|
22
(9) |
23
(8) |
24
(1) |
|
25
|
26
(4) |
27
(6) |
28
(5) |
29
|
30
|
31
(1) |
|
From: Dominik S. <dst...@ft...> - 2004-01-12 14:22:42
|
Hi, I don't think valgrind is responsible, but I thought I'd report it anyway, maybe you can add sort of a "Known Issue" somewhere. When I try to run the valgrind-binaries stored in the Rational/IBM ClearCase version control-system, valgrind does not work any more: /dcaclearcase/vobs/eParty/valgrind/Bin/Linux/bin/valgrind --leak-check=yes -v \ --num-callers=20 --track-fds=yes TestRunner ==24043== Memcheck, a memory error detector for x86-linux. ==24043== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==24043== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==24043== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==24043== Command line ==24043== TestRunner ==24043== Startup, with flags: ==24043== --suppressions=/dcaclearcase/vobs/eParty/valgrind/Bin/Linux/lib/valgrind/default.supp ==24043== --leak-check=yes ==24043== -v ==24043== --num-callers=20 ==24043== --track-fds=yes ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/80001a863fb03f20TestRunner ==24043== Reading syms from /lib/ld-2.2.4.so ==24043== Reading syms from /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e ==24043== Reading syms from /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/6/21/eb7ef003450311d89c82000180e4a89e ==24043== Reading syms from /lib/i686/libpthread-0.9.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800005e03fb0477dlibTestUnit.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800001cd3fb046dclibFTI_Core.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/80000a473fb03f1flibFTIDBApplication.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800002993fb03ed7libFTIApplication.so ==24043== Reading syms from /lib/libdl-2.2.4.so ==24043== Reading syms from /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so ==24043== Reading syms from /lib/i686/libm-2.2.4.so ==24043== Reading syms from /lib/i686/libc-2.2.4.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800001f23fb0477clibFTI_OS.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800009a23fb046d8libFTI_Nana.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800004843fb046b1libFTIDebug.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800003723fb04761libFTI_Config.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/8000022a3fb0477blibFTI_STL.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800021553fb03ed4libFTI_XMLTree.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800003193fb03ec2libFTI_Datatypes.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/80002b0d3fb03ed6libFTI_XMLConsoleProtocols.so ==24043== Reading syms from /export/home/VIEWS/dstadler_Linux.vws/.s/00011/800004833fafddfblibxerces-c.so ==24043== Reading suppressions file: /dcaclearcase/vobs/eParty/valgrind/Bin/Linux/lib/valgrind/default.supp ==24043== Estimated CPU clock rate is 864 MHz ==24043== ==24043== Warning: segment-override prefix encountered, but thread has no LDT ==24043== Warning: segment access: virtual addr 0 exceeds segment limit of 0 ==24043== Invalid read of size 4 ==24043== at 0x40249EF4: __pthread_alt_lock (spinlock.c:446) ==24043== by 0x40246D25: __pthread_mutex_lock (mutex.c:120) ==24043== by 0x403AE6D0: __register_frame_info (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==24043== by 0x40021A61: (within /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e) ==24043== by 0x400217D0: (within /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e) ==24043== by 0x4000DAA6: _dl_init (dl-init.c:70) ==24043== by 0x40001ED0: (within /lib/ld-2.2.4.so) ==24043== Address 0x0 is not stack'd, malloc'd or free'd ==24043== ==24043== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==24043== Address not mapped to object at address 0x0 ==24043== at 0x40249EF4: __pthread_alt_lock (spinlock.c:446) ==24043== by 0x40246D25: __pthread_mutex_lock (mutex.c:120) ==24043== by 0x403AE6D0: __register_frame_info (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==24043== by 0x40021A61: (within /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e) ==24043== by 0x400217D0: (within /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e) ==24043== by 0x4000DAA6: _dl_init (dl-init.c:70) ==24043== by 0x40001ED0: (within /lib/ld-2.2.4.so) ==24043== ==24043== FILE DESCRIPTORS: 3 open at exit. ==24043== Open file descriptor 2: /dev/pts/2 ==24043== <inherited from parent> ==24043== ==24043== Open file descriptor 1: /dev/pts/2 ==24043== <inherited from parent> ==24043== ==24043== Open file descriptor 0: /dev/pts/2 ==24043== <inherited from parent> ==24043== ==24043== ==24043== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==24043== ==24043== 1 errors in context 1 of 1: ==24043== Invalid read of size 4 ==24043== at 0x40249EF4: __pthread_alt_lock (spinlock.c:446) ==24043== by 0x40246D25: __pthread_mutex_lock (mutex.c:120) ==24043== by 0x403AE6D0: __register_frame_info (in /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so) ==24043== by 0x40021A61: (within /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e) ==24043== by 0x400217D0: (within /.automount/dcaclust2/root/dcaclearcase/VOBS/eParty.vbs/c/cdft/11/41/ee7ef167450311d89c82000180e4a89e) ==24043== by 0x4000DAA6: _dl_init (dl-init.c:70) ==24043== by 0x40001ED0: (within /lib/ld-2.2.4.so) ==24043== Address 0x0 is not stack'd, malloc'd or free'd ==24043== IN SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==24043== ==24043== malloc/free: in use at exit: 0 bytes in 0 blocks. ==24043== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==24043== ==24043== No malloc'd blocks -- no leaks are possible. --24043-- TT/TC: 0 tc sectors discarded. --24043-- 42 chainings, 0 unchainings. --24043-- translate: new 107 (1859 -> 23983; ratio 129:10) --24043-- discard 0 (0 -> 0; ratio 0:10). --24043-- dispatch: 447 jumps (bb entries), of which 107 (23%) were unchained. --24043-- 1/108 major/minor sched events. 107 tt_fast misses. --24043-- reg-alloc: 16 t-req-spill, 4574+134 orig+spill uis, 527 total-reg-r. --24043-- sanity: 2 cheap, 1 expensive checks. --24043-- ccalls: 421 C calls, 58% saves+restores avoided (1448 bytes) --24043-- 530 args, avg 0.84 setup instrs each (168 bytes) --24043-- 0% clear the stack (1260 bytes) --24043-- 206 retvals, 22% of reg-reg movs avoided (88 bytes) proxy 24049 for tid 1 exited status -1, res 0 /export/home/dstadler/bin/valgrind: line 2: 24043 Segmentation fault /dcaclearcase/vobs/eParty/valgrind/Bin/Linux/bin/valgrind --leak-check=yes -v --num-callers=20 --track-fds=yes $* when the binaries are not stored in ClearCase, valgrind works perfectly. It even works if the valgrind-binary is located inside ClearCase as so called "private files" (i.e. not checked in). The binaries that I try to check can be located in ClearCase, though. Dominik. |
|
From: Dirk M. <dm...@gm...> - 2004-01-12 14:16:41
|
On Monday 12 January 2004 12:04, Janne Karhunen wrote: > Quitting gdb makes it to hang completely ( either gdb or vg ). Any > ideas? The gdb on SuSE 9 is totally broken. you can avoid the hang by doing a kill -CONT <pid>, but the backtrace is still not working in all cases. Dirk |
|
From: Janne K. <Jan...@pp...> - 2004-01-12 11:04:18
|
Hi, As i'm trying to use --gdb-attach on SuSE 9.0 ( gdb 5.3.92-SuSE, valgrind 2.0.0 ) i can't get the stack frame to be shown. GDB is invoked properly, but: (gdb) bt #0 0x4018dc1c in vg_do_syscall3 () from /usr/lib/valgrind/valgrind.so #1 0x4018f320 in vgPlain_system () from /usr/lib/valgrind/valgrind.so (gdb) info threads (gdb) Quitting gdb makes it to hang completely ( either gdb or vg ). Any ideas? -- // Janne |
|
From: Nick R. <ni...@ni...> - 2004-01-10 16:11:57
|
I posted the message below to ema...@gn.... However, I have not used
valgrind in earnest. Could anyone who is familiar with both valgrind and emacs
please comment on its usefulness (or lack of it!). Please note, however, that
THIS REQUIRES THE CVS VERSION OF EMACS from the repository at Savannah.
Thanks,
Nick http://www.nick.uklinux.net
> Type M-x gdb in the minibuffer and when prompted with (something like):
> Run gdb (like this): gdb --annotate=3
> replace it with (if your executable is ~/myprog, say):
> Run gdb (like this): valgrind --gdb-attach=yes ~/myprog
> At a memory violation, when valgrind asks if you want to atach to gdb, type y:
> ==19752== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
> At the prompt for GDB type:
> `set ann 3' and press <RET> if you want the mode for gdb in gdb-ui.el
> `set ann 1' and press <RET> if you want the mode for gdb in gud.el
> In the first case, the main routine appears in the source buffer and the
> resulting layout depends on the value of gdb-many-windows. In the second case,
> nothing happens immediately.
> If you now type bt, GDB prints the call stack. This also includes calls to
> valgrind's code. Identify the frame number of your code, 6 say, and type:
> (gdb) frame 6
> and the code for this call should appear in the source buffer in both
> cases. Just as with the command line you can't step through your code under
> valgrind but you can move up and down the stack and examine the values of
> variables. When you want to return to valgrind type Ctrl-D to quit GDB but
> stay in the GUD buffer.
|
|
From: Robert W. <rj...@du...> - 2004-01-10 07:56:54
|
Hi all, I've made an experimental patch for the CVS head to support memory pool-based custom allocators. These are allocators that malloc or mmap one or more large pools of memory and parcel it out in small chunks.=20 The main motivation for adding this was to allow all memory in a particular pool to be freed in one go. This is pretty difficult to do with the existing custom allocator support, but is fairly popular with the memory pool mechanisms I've seen. This is still work in progress, so there's a few missing pieces. For a start, chunks allocated in a pool do not get leak checked yet. Also, I haven't tested the individual chunk free mechanism very much (as opposed to the "free an entire pool" mechanism, which I have tested.) It has support for red-zones, too, but I haven't tested these at all either. You can find it here: http://www.durables.org/software/valgrind You can see an example of it being used in the test-case I created for it: memcheck/tests/mempool.c Please send me feedback or drop me a mail if you have any questions about how to use it. The motivation for creating this was a pool-based allocator in some software I work on at my job, so it may be skewed towards assumptions I made based on that. If there's other pool-based mechanisms that this doesn't appear to support, please let me know. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Dirk M. <dm...@gm...> - 2004-01-09 01:07:44
|
On Friday 09 January 2004 01:55, Reese, Shawn wrote: > The libippacw7.so is an Intel IPP library, and I have to use this to get > the speed I need. Does anyone know a workaround? its already implemented in the CVS branch. |
|
From: Reese, S. <Sha...@gd...> - 2004-01-09 00:55:41
|
I have a realtime digital signal processing program that I would like to debug. It uses the Intel IPP libraries and is compiled with the Intel C++ compiler. When I try to run Valgrind with the program, it dies after trying to access a function in an Intel library. Here are the errors: Unknown line prefix (disInstr: unhandled instruction bytes: 0xF 0x2B 0x0 0xF) Unknown line prefix ( at 0x403631F3: (within /opt/intel/ipp/sharedlib/libippacw7.so)) Process terminating with default action of signal 4 (SIGILL): dumping core Illegal operand at address 0x401644CE at 0x403631F3: (within /opt/intel/ipp/sharedlib/libippacw7.so) by 0x74696E68: ??? The libippacw7.so is an Intel IPP library, and I have to use this to get the speed I need. Does anyone know a workaround? Thanks, Shawn |
|
From: Sebastian K. <Seb...@so...> - 2004-01-08 12:28:43
|
From: "John Reiser" <jreiser@BitWagon.com>
> Nicholas Nethercote wrote:
> > On Mon, 5 Jan 2004, John Reiser wrote:
> >
> >
> >>>As with all free software, you get out what you put in.
> >>
> >>I put in test cases, I get out bugs -- enough to demonstrate that
memcheck
> >>has a ways to go before I should rely on it to check non-test code.
> >
> >
> > Memcheck produces false positives and false negatives. This will always
> > be the case, because the method it uses isn't sound or complete,
>
> This is a major change in stance. Originally, and for a few years,
valgrind
> claimed
Valgrind is a tool, Valgrind claims nothing as it has not free will to be
able to do so.
> that it would complain if and only if an uninitialized bit affected
> control flow or I/O.
Where was such claim present?
> Of course, the claim _never_ was correct:
> ld-linux.so.2 before LD_PRELOAD takes effect
It is clearly stated in the manuals. If someone does not read the manual
then it's her fault not the fault of the tool she's using.
> scalar args to syscalls
That's the only real problem (with non-academi value) presented by you in
this post.
> floating point arithmetic
It's stated in the manual as well.
> MMX (even AND and OR !)
Same.
> bitwise "convolution" operations (multiplication, division,
remainder)
Same.
> but at least there was the pretense, and therefore some hope, that
> "complain as late as possible [just before disaster]" could be relied on
> in most cases.
And thats true. One should distinguish between most and all.
> Now even the pretense is gone.
Nope.
> > and the
> > implementation will always have imperfections. (And I agree that the
bugs
> > you mention, particular the lack of checking on scalar syscall
arguments,
> > should be looked at.)
> >
> > However, I don't see why one shouldn't use Memcheck on non-test code:
> >
> > - If it produces false positives, as long as the number is small
enough
> > that they don't become a distraction -- and I think experience shows
> > that this is true for Memcheck -- one can check them, determine
their
> > falsehood, and suppress them.
> >
> > - As for producing false negatives, the only problem I can see with
this
> > is if someone assumes that when their programs passes Memcheck
without
> > errors, that it is totally bug-free with respect to memory errors.
I
> > don't imagine this is common, and it is not the case with you
John --
> > you are clearly aware of Memcheck's shortcomings.
> >
> > I can understand why you might not trust a compiler that you knew had
> > certain bugs -- because you are relying on blemish-free output. But
> > Memcheck is a different sort of program, where the output doesn't have
to
> > be blemish-free for it to still be useful. So I don't understand why
> > relying on it would be a bad thing. Perhaps you could elaborate
further?
>
> The test case fanout.c shows that memcheck does not understand
reconvergent
> fanout: "cancelling" of uninitialized-ness. The result of any boolean AND
> (x & ~x) is guaranteed to be 0, regardless of which bits are initialized
> or not, yet memcheck complains from within printf().
How often do you use such stuff in real code?
The are other values than 0 and infinity in the real world. And here
infinity (i.e. catching everything) is practically and theioretically
impossible.
> The example further
> underscores the severity of not checking scalar args to syscalls: by
memcheck's
> logic the return value of main() is undefined, yet memcheck does not
complain
> there! Even if not checking the argument to sys_exit(), everyone knows
that
> there _is_ an implicit read of the return value from main(); memcheck
> ought to pay attention.
>
> -----fanout.c
> int g(int a, int *p)
> {
> return *p & ~a;
> }
>
> int f(int *p)
> {
> return g(*p, p);
> }
>
> main()
> {
> int x; /* deliberately uninitialized */
> printf("%d\n", !!f(&x));
> return !!f(&x);
> }
> /* Curious quirk: memcheck (valgrind-2.1.0) complains 5 times
> as written, but 7 times when both "!!" are removed.
> The values produced by the code (and their "heritage") are the same!
> */
So what? probably logical negation is translated into some branching code,
and at the point of branch error is raised by memcheck.
> -----end fanout.c
>
>
> So, memcheck now admits that its method is neither sound nor complete.
It never did otherwise. It's obvious. And there is *no tool* which could
admit that.
> Memcheck complains "as late as possible" for uninit bits in "easy"
> operations, "as soon as possible" [maybe: integer mul/div/rem are
> murky] for uninit bits in "hard" operations, and "never" for
> scalar args to syscalls. There is no option to get "eager" mode
> all the time (complain "as soon as possible": on any fetch from memory),
> which in many cases is the information needed for the easiest debugging
> and fixing.
It has been beaten to death. Going such way is useless in case of such
design as memcheck (i.e. instryumentation of machine code not source code
nor just system & library calls)
> How, then, should the programmer interpret the output from memcheck?
Should use his/her own brain. Simple as that. If someone uses such bad style
she ougth pto be aware of the places she used that. Valgrind is not a tool
for general user, ity's a tool for specialists (programmers), for
specialists it's output is helpfull and meaningfull. The same way console in
control room of atomic plant is useless for a layman, but it's really
usefull & important for trained operators.
> Supposedly any complaint should indicate an actual bug.
Nope. It's enough to use some unstandard mem allocation, etc. Oneshould be
perrfectly aware of such cases.
> But if
> reconvergent fanout or integer "convolution" is involved, then all bets
> are off, and the noise level from memcheck is quite high.
You're raising academic problems. Such stuff in real code, code which does
something useful, are quite rare (and in many cases are just examples of bad
coding style). I'm not thinking about stuff made for
most-obfuscated-hacked-together-code contest.
> Unfortunately
> such operations are quite common in pattern matching and recognition
> algorithms, and pattern processing is widespread: cryptanalysis, remote
> sensing, image analysis, radar, sonar, vision, robotics, ...;
And relying on uninitialised data? I don't buy it.
Especially using such doubdfull & error prone techniques in things like
radar/sonnar/remote sensing -- often used in life critical apps.
As I daily work in area of high reliablility apps (not lifie critical, but
1-2 steps lower) and I assure you, that such shady stuff is banned here.
Besides for such things one usually uses languages significantly better than
C or C++. In such languages things like uninitialised variables and data
structure overruns are simply impossible to begin with.
In my area such stuff like you're crying about is a banned technique (as
being really bad coding style). And it could & should be avoided in every
properly coded program (with the exception of aforementioned obfuscation
contests). Thus I'm perfectly fine with Valgrid complainng about those.
> including
> stroke recognition for mouse input to a GUI.
???
> Even when a complaint accurately determines that a bug exists, it can
> quite difficult to locate and correct if it is associated with a
> chain of "easy" operations, and therefore the complaint is as late
> as possible. "Eager mode" should be available for all operations,
> not just floating point or other "hard" operations.
Eager mode would cause enormous number of false positives (those you're so
complaining about). It was describe why so many times by the authors that
there is no sense repeating that again.
> More troubling are the omitted complaints (false negatives).
> These include scalar args to syscalls and the internal hacks that
> suppress complaints automatically in an attempt to reduce noise
> from strlen (etc.) without checking that the code is a reaonsable
> impostor for strlen.
>
> All in all, that's too much hassle for me. Memcheck goes to the bottom
> of my toolbox. I can check and correct more code sooner, and have more
> confidence the results, using Insure++, or Purify on SPARC/Solaris.
If you think that those tools use exact methods then you're dreaimng, as
such methods do not exists. But if you feel better with them then fine,
Valgrind is free software, andyone is free to use or not to use it.
Every tool has it's pros and cons. Will those other (and how) handle
nonstandard libraries writtten in other languages. How those handle
nonstandard GCC extensions, inline assembly snippets etc.? It's allways a
matter of compromise (and contrary to 0-infinity world, in real world
compromises do exist)
rgds
Sebastian Kaliszewski
--
"Never underestimate the power of human stupidity" - from Notebooks of L.L.
|
|
From: Mukund S. <mu...@sh...> - 2004-01-08 06:16:58
|
Hi
I am trying to debug some large section of the code that
uses epoll. Unfortunately valgrind says epoll is an unimplemented system
call.=20
I have read the man page, tried to suppress the errors, but with no
success. Here is a sample code that causes the error.
=20
Error
=3D=3D23968=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D23968=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D23968=3D=3D Using valgrind-2.1.0, a program supervision framework =
for
x86-linux.
=3D=3D23968=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D23968=3D=3D Estimated CPU clock rate is 2699 MHz
=3D=3D23968=3D=3D For more details, rerun with: -v
=3D=3D23968=3D=3D=20
--23968-- WARNING: unhandled syscall: 254
--23968-- Do not panic. You may be able to fix this easily.
--23968-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
=3D=3D23968=3D=3D Invalid read of size 1
=3D=3D23968=3D=3D at 0x961D9A: strcmp (in /lib/ld-2.3.2.so)
=3D=3D23968=3D=3D by 0x40322499: dl_open_worker (in =
/lib/i686/libc-2.3.2.so)
=3D=3D23968=3D=3D by 0x95C735: _dl_catch_error_internal (in =
/lib/ld-2.3.2.so)
=3D=3D23968=3D=3D by 0x40322308: __GI__dl_open (in =
/lib/i686/libc-2.3.2.so)
=3D=3D23968=3D=3D Address 0xFFFFE210 is not stack'd, malloc'd or free'd
=3D=3D23968=3D=3D=20
=3D=3D23968=3D=3D Invalid read of size 1
=3D=3D23968=3D=3D at 0x961D9A: strcmp (in /lib/ld-2.3.2.so)
=3D=3D23968=3D=3D by 0x95C0FA: openaux (in /lib/ld-2.3.2.so)
=3D=3D23968=3D=3D by 0x95C735: _dl_catch_error_internal (in =
/lib/ld-2.3.2.so)
=3D=3D23968=3D=3D by 0x95BC80: _dl_map_object_deps_internal (in
/lib/ld-2.3.2.so)
=3D=3D23968=3D=3D Address 0xFFFFE210 is not stack'd, malloc'd or free'd
=3D=3D23968=3D=3D=20
=3D=3D23968=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D23968=3D=3D at 0x416C73FE: getanswer_r (in =
/lib/libnss_dns-2.3.2.so)
=3D=3D23968=3D=3D by 0x416C60B3: _nss_dns_gethostbyname2_r (in
/lib/libnss_dns-2.3.2.so)
=3D=3D23968=3D=3D by 0x416C62AB: _nss_dns_gethostbyname_r (in
/lib/libnss_dns-2.3.2.so)
=3D=3D23968=3D=3D by 0x40304CCA: gethostbyname_r@@GLIBC_2.1.2 (in
/lib/i686/libc-2.3.2.so)
=3D=3D23968=3D=3D=20
=3D=3D23968=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D23968=3D=3D at 0x416C7401: getanswer_r (in =
/lib/libnss_dns-2.3.2.so)
=3D=3D23968=3D=3D by 0x416C60B3: _nss_dns_gethostbyname2_r (in
/lib/libnss_dns-2.3.2.so)
=3D=3D23968=3D=3D by 0x416C62AB: _nss_dns_gethostbyname_r (in
/lib/libnss_dns-2.3.2.so)
=3D=3D23968=3D=3D by 0x40304CCA: gethostbyname_r@@GLIBC_2.1.2 (in
/lib/i686/libc-2.3.2.so)
--23968-- WARNING: unhandled syscall: 255
--23968-- Do not panic. You may be able to fix this easily.
--23968-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--23968-- WARNING: unhandled syscall: 256
--23968-- Do not panic. You may be able to fix this easily.
--23968-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
=3D=3D23968=3D=3D Warning: invalid file descriptor -1 in syscall close()
=3D=3D23968=3D=3D=20
=3D=3D23968=3D=3D ERROR SUMMARY: 24 errors from 4 contexts (suppressed: =
5 from
1)
=3D=3D23968=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D23968=3D=3D malloc/free: 66 allocs, 66 frees, 5227 bytes =
allocated.
=3D=3D23968=3D=3D For a detailed leak analysis, rerun with: =
--leak-check=3Dyes
=3D=3D23968=3D=3D For counts of detected errors, rerun with: -v
=20
=20
Code
=3D=3D=3D=3D
=20
#include <sys/epoll.h>
#include <netdb.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
=20
#define MAX_BUFF_LEN 4096
#define MAX_EVENTS_SIZE 25
=20
int main() {
int ed =3D epoll_create(256);
char buf[MAX_BUFF_LEN];
char output_buff[MAX_BUFF_LEN];
struct epoll_event events[MAX_EVENTS_SIZE];
struct hostent hostEntity;
struct hostent *pResolvedHost;
struct sockaddr_in server;
int syserrno,i,numFds;
int sockfd;
struct epoll_event ev;
char data[] =3D"GET / HTTP/1.0\r\n\r\n";
int status =3D gethostbyname_r("www.yahoo.com",&hostEntity, buf,
MAX_BUFF_LEN,&pResolvedHost, &syserrno);
if (status !=3D 0) {
fprintf(stderr,"Cannot resolve the hostname. gethostbyname_r failed
");
exit(-1);
}
memset((char *) &server,0, sizeof(server));
memmove((char *) &server.sin_addr,
pResolvedHost->h_addr,pResolvedHost->h_length);
server.sin_family =3D pResolvedHost->h_addrtype;
server.sin_port =3D (unsigned short) htons( 80 );
=20
sockfd =3D socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
status =3D connect(sockfd,(struct sockaddr *)&server,sizeof(server));
if (status !=3D 0) {
fprintf(stderr,"Cannot connect to host \n");
}
write (sockfd,data,strlen(data));
=20
ev.events =3D EPOLLIN|EPOLLET;
ev.data.fd =3D sockfd;
status =3D epoll_ctl(ed,EPOLL_CTL_ADD,sockfd,&ev);
numFds =3D epoll_wait(ed, events,MAX_EVENTS_SIZE, -1);
for (i=3D0;i<numFds; i++) {
int len =3D0;
while ( (len =3Dread(events[i].data.fd,output_buff,MAX_BUFF_LEN)) >0 =
)
{
write(1,output_buff,len);
}
close(events[i].data.fd);
}
close(ed);
return 0;
}
=20
=20
=20
=20
=20
|
|
From: Mathieu M. <mat...@ki...> - 2004-01-07 19:49:42
|
> easy one, implemented in CVS. Thanks a lot and please accept my apologies for this. BTW, I had a problem with <timex.h>, solution is here: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109517 HTH Mathieu |
|
From: Aghiles K. <ag...@dn...> - 2004-01-07 19:24:08
|
Hi, > All in all, that's too much hassle for me. Memcheck goes to the bottom > of my toolbox. I can check and correct more code sooner, and have more > confidence the results, using Insure++, or Purify on SPARC/Solaris. > We have been using Purify for so many years.... We are so glad to have valgrind now! Valgrind integrates so smoothly in the development environment. I am working on a 3D renderer and I must say that valgrind is *superior* to Purify in this particular case. Also, valgrind is young, I am sure that in a couple of years (months ? :>) it will be unbeatble. Aghiles www.3delight.com |
|
From: Dirk M. <dm...@gm...> - 2004-01-07 19:17:52
|
On Wednesday 07 January 2004 19:43, Mathieu Malaterre wrote: > What is this instruction ? Any idea how difficult this is to implement? easy one, implemented in CVS. |
|
From: Tom H. <th...@cy...> - 2004-01-07 19:17:43
|
In message <3FF...@ki...>
Mathieu Malaterre <mat...@ki...> wrote:
> disInstr: unhandled instruction bytes: 0xF3 0xF 0x52 0xE3
> Illegal instruction
>
>
> What is this instruction ? Any idea how difficult this is to implement?
It's RSQRTSS and it shouldn't be difficult to do.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Mathieu M. <mat...@ki...> - 2004-01-07 18:43:49
|
==25853== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==25853== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==25853== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==25853== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==25853== Estimated CPU clock rate is 2794 MHz ==25853== For more details, rerun with: -v ==25853== ==25853== Warning: set address range perms: large range 134217728, a 0, v 0 ==25853== Source and destination overlap in memcpy(0x2382570, 0x2382570, 4) ==25853== at 0x360AE4: memcpy (mac_replace_strmem.c:95) ==25853== by 0x19F287: (within /usr/X11R6/lib/libXt.so.6.0) ==25853== by 0x19FBB1: _XtGetResources (in /usr/X11R6/lib/libXt.so.6.0) ==25853== by 0x189042: (within /usr/X11R6/lib/libXt.so.6.0) ==25853== ==25853== Syscall param ioctl(generic) contains uninitialised or unaddressable byte(s) ==25853== at 0x98B384: __GI___ioctl (in /lib/libc-2.3.2.so) ==25853== Address 0xBFF17B90 is on thread 1's stack ==25853== ==25853== Conditional jump or move depends on uninitialised value(s) ==25853== at 0x408A1D35: fglX11InitSurfaceManager (in /usr/X11R6/lib/modules/dri/fglrx_dri.so) disInstr: unhandled instruction bytes: 0xF3 0xF 0x52 0xE3 Illegal instruction What is this instruction ? Any idea how difficult this is to implement? Thanks, Mathieu [Using valgrind 2.1 and ATI OpenGL (fglrx) driver] |
|
From: John R.
|
Nicholas Nethercote wrote:
> On Mon, 5 Jan 2004, John Reiser wrote:
>
>
>>>As with all free software, you get out what you put in.
>>
>>I put in test cases, I get out bugs -- enough to demonstrate that memcheck
>>has a ways to go before I should rely on it to check non-test code.
>
>
> Memcheck produces false positives and false negatives. This will always
> be the case, because the method it uses isn't sound or complete,
This is a major change in stance. Originally, and for a few years, valgrind
claimed that it would complain if and only if an uninitialized bit affected
control flow or I/O. Of course, the claim _never_ was correct:
ld-linux.so.2 before LD_PRELOAD takes effect
scalar args to syscalls
floating point arithmetic
MMX (even AND and OR !)
bitwise "convolution" operations (multiplication, division, remainder)
but at least there was the pretense, and therefore some hope, that
"complain as late as possible [just before disaster]" could be relied on
in most cases. Now even the pretense is gone.
> and the
> implementation will always have imperfections. (And I agree that the bugs
> you mention, particular the lack of checking on scalar syscall arguments,
> should be looked at.)
>
> However, I don't see why one shouldn't use Memcheck on non-test code:
>
> - If it produces false positives, as long as the number is small enough
> that they don't become a distraction -- and I think experience shows
> that this is true for Memcheck -- one can check them, determine their
> falsehood, and suppress them.
>
> - As for producing false negatives, the only problem I can see with this
> is if someone assumes that when their programs passes Memcheck without
> errors, that it is totally bug-free with respect to memory errors. I
> don't imagine this is common, and it is not the case with you John --
> you are clearly aware of Memcheck's shortcomings.
>
> I can understand why you might not trust a compiler that you knew had
> certain bugs -- because you are relying on blemish-free output. But
> Memcheck is a different sort of program, where the output doesn't have to
> be blemish-free for it to still be useful. So I don't understand why
> relying on it would be a bad thing. Perhaps you could elaborate further?
The test case fanout.c shows that memcheck does not understand reconvergent
fanout: "cancelling" of uninitialized-ness. The result of any boolean AND
(x & ~x) is guaranteed to be 0, regardless of which bits are initialized
or not, yet memcheck complains from within printf(). The example further
underscores the severity of not checking scalar args to syscalls: by memcheck's
logic the return value of main() is undefined, yet memcheck does not complain
there! Even if not checking the argument to sys_exit(), everyone knows that
there _is_ an implicit read of the return value from main(); memcheck
ought to pay attention.
-----fanout.c
int g(int a, int *p)
{
return *p & ~a;
}
int f(int *p)
{
return g(*p, p);
}
main()
{
int x; /* deliberately uninitialized */
printf("%d\n", !!f(&x));
return !!f(&x);
}
/* Curious quirk: memcheck (valgrind-2.1.0) complains 5 times
as written, but 7 times when both "!!" are removed.
The values produced by the code (and their "heritage") are the same!
*/
-----end fanout.c
So, memcheck now admits that its method is neither sound nor complete.
Memcheck complains "as late as possible" for uninit bits in "easy"
operations, "as soon as possible" [maybe: integer mul/div/rem are
murky] for uninit bits in "hard" operations, and "never" for
scalar args to syscalls. There is no option to get "eager" mode
all the time (complain "as soon as possible": on any fetch from memory),
which in many cases is the information needed for the easiest debugging
and fixing.
How, then, should the programmer interpret the output from memcheck?
Supposedly any complaint should indicate an actual bug. But if
reconvergent fanout or integer "convolution" is involved, then all bets
are off, and the noise level from memcheck is quite high. Unfortunately
such operations are quite common in pattern matching and recognition
algorithms, and pattern processing is widespread: cryptanalysis, remote
sensing, image analysis, radar, sonar, vision, robotics, ...; including
stroke recognition for mouse input to a GUI.
Even when a complaint accurately determines that a bug exists, it can
quite difficult to locate and correct if it is associated with a
chain of "easy" operations, and therefore the complaint is as late
as possible. "Eager mode" should be available for all operations,
not just floating point or other "hard" operations.
More troubling are the omitted complaints (false negatives).
These include scalar args to syscalls and the internal hacks that
suppress complaints automatically in an attempt to reduce noise
from strlen (etc.) without checking that the code is a reaonsable
impostor for strlen.
All in all, that's too much hassle for me. Memcheck goes to the bottom
of my toolbox. I can check and correct more code sooner, and have more
confidence the results, using Insure++, or Purify on SPARC/Solaris.
--
|
|
From: John R.
|
> ... a list of unimplemented MMX/SSE/SSE2 opcodes. About
> 78% are implemented. ...
The explicit list is a good start at completing opcode coverage.
Looking at the list and at the function disInstr() from the source
coregrind/vg_to_ucode.c -r1.120, I must ask:
Why does the code employ copy+paste+edit so extensively, instead of
taking much more advantage of obvious schemas based on the hardware?
To the code of valgrind there is almost no difference between
ORPS and any of {ANDPS, ANDNPS, XORPS}. Yet ORPS is unimplemented,
and each of the others has its own individual paragraph of code.
All four of them could share the same paragraph by indexing a small
array with the unique opcode byte. And why not decode that byte
using a 'switch' instead of a few dozen consecutive 'if'?
These are more than just optimization hacks. Recognizing and
exploiting underlying schemas to ease coding and improve
performance is one of the hallmarks of a good implementation.
Anyway, based on the annotations in the list, I see some groups:
1) ALU function-only differences: OR/AND/XOR; MIN/MAX; etc.
2) ...DQ
3) CVT...
4) miscellaneous: CLFLUSH, ...
Exploiting such groupings may ease and speed the completion of coverage.
Completing coverage will save implementor and user time in contrast to
the disappointment and aggravation of complaints dribbling in piecemeal.
--
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-06 16:47:27
|
On Mon, 5 Jan 2004, John Reiser wrote: > >> and the continuing > >>unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3). > > > > > > There is pretty good coverage of these now I think. We certainly don't > > seem to be seeing many reports of this now and the ones we do get are > > usually patched fairly quickly and short of a volunteer to go through > > the architecture reference manual and implement any missing instructions > > it isn't clear what more could be done. > > The first thing that could be done is count the number of architected > opcodes (including prefixes) that remain unimplemented. Put that number > in the user-level documentation, put the specific list and classification > of the missing cases and a suggested order of implementation in the developer > documentation, and _then_ ask for volunteers. Advertising the specifics > is much more likely to create interest than a vague "there are some > unimplemented opcodes." See attachment for a list of unimplemented MMX/SSE/SSE2 opcodes. About 78% are implemented. The list may contain mistakes; the names and opcodes of these instructions can be confusing, and I wasn't as thorough as I could have been. Still, it should give a good idea of what's left. As for a suggested order of implementation, I won't pretend to know, however the fact that users haven't reported them yet indicate the ones remaining aren't used very widely. N |
|
From: Steve G <lin...@ya...> - 2004-01-06 11:04:05
|
>Jeremy and I have talked about this and think that the best >way to solve it is to hook the suppression of FD leakage >reports into the general suppression mechanism. This sounds good to me. This should be easier for people in the long road since fd leaks will have the same control mechanisms as memory leaks. Thanks, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: Robert W. <rj...@du...> - 2004-01-06 10:52:55
|
> Does anyone have any experience running valgrind on ACE-based > (http://www.cs.wustl.edu/~schmidt/ACE.html) programs? I tried it on > some little programs and it worked, but when I tried a larger program > I got strange results. I was wondering if there was any collected > wisdom on the subject. I recall correctly (my experience with ACE is something I suppress ;-) ACE provides it's own memory allocator. You'd need to hook that into Valgrind using the VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK client requests. See memcheck/tests/custom_alloc.c for an example. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Sebastian K. <Seb...@so...> - 2004-01-06 10:12:25
|
From: "John Reiser" <jreiser@BitWagon.com> [snip] > 11/20/2003 [Valgrind-users] memcheck 2.0.0 complains about init bit [false positive error report] > Unsigned remainder has properties that memcheck does not understand. This one has been dismissed as splitting hairs. There are infinite number of similar cases, and barrierr must be put somewhere. [snip] > The kernel certainly does pay attention to those extra bits in the > last word. In fact, the kernel pays attention so closely that it returns > EFAULT if any of those extra bits do not exist, such as if they are in > a non-mapped page. For example, a user bug may position one of the arrays for > select() so that the byte that contains the bit for highest_fd is at the high > end of the highest page in a segment, but the byte that contains the bit for > (037 | highest_fd) is in the next higher page, and therefore is not present. This is some utterly rare case, as it requires the FD array to be misaligned to begin with. And then if there is such bug kernel itself complains. Besides: why not post patch instead of complaining? > Why not look at the code and figure out what it is doing? Who/What should look at the code and figure that? Memcheck? > It might > become confusing or the results might be inconclusive, but there is > a large difference between "cannot understand this particular case" > and "will not even try." Memcheck is a piece of software, and runtime checks must be algorithmically simple to allow reasonable speed. It doesn't understand anything, obviously as it's not thinking to begin with. > The first thing that could be done is count the number of architected > opcodes (including prefixes) that remain unimplemented. Put that number > in the user-level documentation, put the specific list and classification > of the missing cases and a suggested order of implementation in the developer > documentation, and _then_ ask for volunteers. Advertising the specifics > is much more likely to create interest than a vague "there are some > unimplemented opcodes." As you seem to be interested, why don't you try it yourself. > > As with all free software, you get out what you put in. > > I put in test cases, I get out bugs -- enough to demonstrate that memcheck > has a ways to go before I should rely on it to check non-test code. So it will never be at the state *you* could rely on it. You seem to be 0,infinity guy -- i.e. the only values interesting to you are 0,and infinity and rest you disregard as uninteresting and reduce to 0 or infinity. Valgrnd can never be exact, as this is simply intractable problem (computationally impossible at all, as is determing if particular Turing Machine will stop). If you're waiting for universal bug killer then you can wait forever. Is hunting significant number of bugs is for you the same as hunting nothing? Reduction to 0? rgds Sebastina Kaliszewski |
|
From: Robert W. <rj...@du...> - 2004-01-06 08:34:15
|
> I'm not against checking for "FD leakage," but I do want it done > so that legal but uncommon usage does not get a "false positive" > error report. Jeremy and I have talked about this and think that the best way to solve it is to hook the suppression of FD leakage reports into the general suppression mechanism. The other option was to add yet another command-line option, but that has the disadvantage of a) being yet another command line option on top of an already crowded set of command-line options; b) somewhat less permanent that having a suppression file for a given application; and c) less flexible to do right. I'll be working on this during the week, assuming I get some spare time for it. I'll hopefully have a patch on my web site by the end of the week: http://www.durables.org/software/valgrind/ Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2004-01-06 08:28:43
|
> Why not look at the code and figure out what it is doing? It might > become confusing or the results might be inconclusive, but there is > a large difference between "cannot understand this particular case" > and "will not even try." <snip> > The first thing that could be done is count the number of architected > opcodes (including prefixes) that remain unimplemented. Put that number > in the user-level documentation, put the specific list and classification > of the missing cases and a suggested order of implementation in the devel= oper > documentation, and _then_ ask for volunteers. Advertising the specifics > is much more likely to create interest than a vague "there are some > unimplemented opcodes." John, I invite you to knock yourself out and take on these tasks if you feel so strongly about them. Most of the Valgrind developers are working long hours on non-Valgrind jobs and simply don't have the time or energy to do this. As Tom suggested, you get out what you put in.=20 This wasn't a slight, simply a statement of fact: if you want something done then you have the option of doing it yourself or waiting probably a long time for someone else to find the time to do it. > I put in test cases, I get out bugs -- enough to demonstrate that memchec= k > has a ways to go before I should rely on it to check non-test code. I'd love to see these. Do you have a pointer to them? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-01-06 06:21:42
|
On Mon, 5 Jan 2004, John Reiser wrote:
> > As with all free software, you get out what you put in.
>
> I put in test cases, I get out bugs -- enough to demonstrate that memcheck
> has a ways to go before I should rely on it to check non-test code.
Memcheck produces false positives and false negatives. This will always
be the case, because the method it uses isn't sound or complete, and the
implementation will always have imperfections. (And I agree that the bugs
you mention, particular the lack of checking on scalar syscall arguments,
should be looked at.)
However, I don't see why one shouldn't use Memcheck on non-test code:
- If it produces false positives, as long as the number is small enough
that they don't become a distraction -- and I think experience shows
that this is true for Memcheck -- one can check them, determine their
falsehood, and suppress them.
- As for producing false negatives, the only problem I can see with this
is if someone assumes that when their programs passes Memcheck without
errors, that it is totally bug-free with respect to memory errors. I
don't imagine this is common, and it is not the case with you John --
you are clearly aware of Memcheck's shortcomings.
I can understand why you might not trust a compiler that you knew had
certain bugs -- because you are relying on blemish-free output. But
Memcheck is a different sort of program, where the output doesn't have to
be blemish-free for it to still be useful. So I don't understand why
relying on it would be a bad thing. Perhaps you could elaborate further?
N
|
|
From: John R.
|
Tom Hughes wrote:
> In message <3FF79568.2030804@BitWagon.com>
> John Reiser <jreiser@BitWagon.com> wrote:
>
>
>>so that legal but uncommon usage does not get a "false positive"
>>error report. I also do not like "false negative" reports (undiagnosed
>>actual errors.) I have been disappointed by Valgrind/memcheck
>>several times in these regards:
>
>
> Problems are more likely to fixed if you report them, and I don't
> recall seeing any mention of most of the things you refer to.
The archives of Valgrind-users show these messages from me:
-----
04/29/2003 [Valgrind-users] checking the arguments to system calls?
Mentions the scalar args to syscalls (such as 3rd argument to open()
or missing trailing arguments to mmap()), and the byte arrays to
select() being rounded differently.
11/20/2003 [Valgrind-users] memcheck 2.0.0 overlooks uninit bit [false negative error report]
Memcheck gives carte blanche to a basic block that uses 0x80808080.
11/20/2003 [Valgrind-users] memcheck 2.0.0 complains about init bit [false positive error report]
Unsigned remainder has properties that memcheck does not understand.
-----
and there have been numerous messages from other users about specific
unimplemented opcodes.
> In fact now we have a bug tracker the best was to ensure they are known about
> is to raise a bug.
>
>
>> scalar args to syscalls are not
>>checked for being defined,
>
>
> An interesting point, and one that had crossed my mind in the past. It
> ought to be doable but requires a bit of effort to work out the number
> of arguments for each call and deal with varargs syscalls.
>
>
>> memcheck rounds the byte array args to
>>select() _down_ to a multiple of 8 bits while the kernel rounds them
>>_up_ to a multiple of 32 bits,
>
>
> The kernel may round up and read whole words, but I bet it doesn't pay
> attention to the extra bits in the last word as that would appear to be
> wrong to me.
The kernel certainly does pay attention to those extra bits in the
last word. In fact, the kernel pays attention so closely that it returns
EFAULT if any of those extra bits do not exist, such as if they are in
a non-mapped page. For example, a user bug may position one of the arrays for
select() so that the byte that contains the bit for highest_fd is at the high
end of the highest page in a segment, but the byte that contains the bit for
(037 | highest_fd) is in the next higher page, and therefore is not present.
The kernel acts as the user's agent in touching memory, and the kernel takes
this responsibility very seriously. Memcheck ought to be just as careful.
The same principle applies to scalar arguments to system calls. The kernel
(acting as an agent of the user) makes decisions based on the values in
those registers, so memcheck should check the values for being [un]defined.
> The interface that valgrind uses to check syscall args can
> currently only check to byte granularity, hence it rounds down to the
> nearest byte and ignores any odd bits. That is indeed a bug, but one that
> is slightly finicky to fix.
>
>
>> the appearance of the immediate constant
>>0x01010101 suppresses all errors even if the basic block is not doing
>>optimistic memory scanning [such as strlen(), etc.],
>
>
> I do remember that one being mentioned but I'm not aware that anybody
> has come up with a good alternative to the current behaviour.
Why not look at the code and figure out what it is doing? It might
become confusing or the results might be inconclusive, but there is
a large difference between "cannot understand this particular case"
and "will not even try."
>
>
>> and the continuing
>>unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3).
>
>
> There is pretty good coverage of these now I think. We certainly don't
> seem to be seeing many reports of this now and the ones we do get are
> usually patched fairly quickly and short of a volunteer to go through
> the architecture reference manual and implement any missing instructions
> it isn't clear what more could be done.
The first thing that could be done is count the number of architected
opcodes (including prefixes) that remain unimplemented. Put that number
in the user-level documentation, put the specific list and classification
of the missing cases and a suggested order of implementation in the developer
documentation, and _then_ ask for volunteers. Advertising the specifics
is much more likely to create interest than a vague "there are some
unimplemented opcodes."
>
> As with all free software, you get out what you put in.
I put in test cases, I get out bugs -- enough to demonstrate that memcheck
has a ways to go before I should rely on it to check non-test code.
--
John Reiser, jreiser@BitWagon.com
|
|
From: Tom H. <th...@cy...> - 2004-01-05 22:33:25
|
In message <3FF79568.2030804@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> so that legal but uncommon usage does not get a "false positive"
> error report. I also do not like "false negative" reports (undiagnosed
> actual errors.) I have been disappointed by Valgrind/memcheck
> several times in these regards:
Problems are more likely to fixed if you report them, and I don't
recall seeing any mention of most of the things you refer to. In fact
now we have a bug tracker the best was to ensure they are known about
is to raise a bug.
> scalar args to syscalls are not
> checked for being defined,
An interesting point, and one that had crossed my mind in the past. It
ought to be doable but requires a bit of effort to work out the number
of arguments for each call and deal with varargs syscalls.
> memcheck rounds the byte array args to
> select() _down_ to a multiple of 8 bits while the kernel rounds them
> _up_ to a multiple of 32 bits,
The kernel may round up and read whole words, but I bet it doesn't pay
attention to the extra bits in the last word as that would appear to be
wrong to me. The interface that valgrind uses to check syscall args can
currently only check to byte granularity, hence it rounds down to the
nearest byte and ignores any odd bits. That is indeed a bug, but one that
is slightly finicky to fix.
> the appearance of the immediate constant
> 0x01010101 suppresses all errors even if the basic block is not doing
> optimistic memory scanning [such as strlen(), etc.],
I do remember that one being mentioned but I'm not aware that anybody
has come up with a good alternative to the current behaviour.
> and the continuing
> unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3).
There is pretty good coverage of these now I think. We certainly don't
seem to be seeing many reports of this now and the ones we do get are
usually patched fairly quickly and short of a volunteer to go through
the architecture reference manual and implement any missing instructions
it isn't clear what more could be done.
As with all free software, you get out what you put in.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|