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
(4) |
2
|
3
(5) |
4
(7) |
5
(15) |
6
(11) |
|
7
(11) |
8
(3) |
9
(29) |
10
(2) |
11
(14) |
12
(10) |
13
(2) |
|
14
(4) |
15
(9) |
16
(4) |
17
|
18
|
19
|
20
|
|
21
|
22
|
23
(2) |
24
(14) |
25
(11) |
26
(3) |
27
(1) |
|
28
(4) |
29
(21) |
30
(12) |
|
|
|
|
|
From: Benjamin L. <ben...@us...> - 2003-09-07 07:58:18
|
Your *normal* free() implementation sounds like it is non-ANSI C and non-POSIX compliant. Are you overriding it somewhere or using a malloc checking library? http://www.opengroup.org/onlinepubs/007904975/functions/free.html Can you supply details of your operating system, C library, compiler etc. and all that jazz? On Sunday, 2003-09-07 at 01:54:19 PM, Gong Cheng scribbled: > I have a wired bug > > the code is like this > > > printf("%d",i); > free(j); > printf("%d",i); > > if we suppose i =1 ,the result should be > 1 > 1 > but in reality, the result is > 1 > 0 > > The interesting thing is that if I use valgrind to run the program, > the result turn back to > 1 > 1 > > anybody know what's the difference between normal free and the free in > valgrind? > > Thanks a lot! > > Gong > -- Benjamin Lee Melbourne, Australia "Always real." http://www.realthought.net/ __________________________________________________________________________ Before destruction a man's heart is haughty, but humility goes before honour. -- Psalms 18:12 |
|
From: Dan K. <da...@ke...> - 2003-09-07 04:37:29
|
Steve G wrote: >>If I were you, I'd install a fresh copy of the latest >>gnu make just to see if that made a difference. > > > I wouldn't. If you install a tarball over an rpm, you might get > some of the directories wrong and then you have files all over > the place that aren't tracked by rpm. Yes, that would be messy. However, if you install the new make in /usr/local, there's no conflict, as it turns out. And /usr/local is the default install destination, so it's fairly safe. > The proper thing to do, is figure out how to reliably reproduce > the bug, file a bugzilla bug report, and look in rawhide's srpms > to get the latest official release. Build it and see if that > takes care of it. It won't get better without a bug report. If > there's a bug report already covering the problem add to it. They > may not have a reliable test case. It also wouldn't hurt to > mention it on the RH9 mail list. > > FWIW, I use RH9 and have no problems compiling either. Yep, reproducing it and boiling it down to a minimal test case, and then reporting it, is totally the way to make progress. However, when reporting the bug, it's always nice to be able to say "... and the bug doesn't happen in the latest GNU version installed from source." - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Gong C. <g...@ac...> - 2003-09-07 03:51:34
|
I have a wired bug
the code is like this
printf("%d",i);
free(j);
printf("%d",i);
if we suppose i =1 ,the result should be
1
1
but in reality, the result is
1
0
The interesting thing is that if I use valgrind to run the program,
the result turn back to
1
1
anybody know what's the difference between normal free and the free in
valgrind?
Thanks a lot!
Gong
|
|
From: Evan B. D. <ebd...@un...> - 2003-09-07 02:58:35
|
Is there a way to make valgrind not decide that the program has switched stacks? I have a program that allocates a lot on the stack as main() initializes, which causes valgrind to think the program has switched stacks; this then causes spurious errors. I have since changed the program to work around this, and valgrind is working fine, but it seems there should be some sort of option for when you know the client program won't switch stacks. If there is none, then count this as a feature request :) Thanks, Evan Daniel |
|
From: Steve G <lin...@ya...> - 2003-09-07 02:42:02
|
>If I were you, I'd install a fresh copy of the latest >gnu make just to see if that made a difference. I wouldn't. If you install a tarball over an rpm, you might get some of the directories wrong and then you have files all over the place that aren't tracked by rpm. The proper thing to do, is figure out how to reliably reproduce the bug, file a bugzilla bug report, and look in rawhide's srpms to get the latest official release. Build it and see if that takes care of it. It won't get better without a bug report. If there's a bug report already covering the problem add to it. They may not have a reliable test case. It also wouldn't hurt to mention it on the RH9 mail list. FWIW, I use RH9 and have no problems compiling either. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Dan K. <da...@ke...> - 2003-09-06 20:18:58
|
Nigel Horne wrote: > On Saturday 06 Sep 2003 2:36 pm, Tom Hughes wrote: > >>>If in doubt, 'use the source'. >> >>I disagree. The whole point of using a well known distribution is to >>save yourself the bother of having to build everything yourself > > > Exactly. Y'all can disagree 'til you're blue in the face, but if Valgrind won't build with RH9 because RH9 ships with a broken make, you won't get anywhere until you install a working one. That said, valgrind-20030725 builds fine for me on RH9 with its make. No idea what's up with your copy. If I were you, I'd install a fresh copy of the latest gnu make just to see if that made a difference. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Geoff A. <gal...@nc...> - 2003-09-06 18:24:40
|
I recently downloaded valgrind 20030725 and still encountered the compile. It's easy enough to make the change myself, but I wonder if it's going to be fixed in the official distribution. Thanks, Geoff Alexander ----- Original Message ----- From: "Geoff Alexander" <gal...@nc...> To: "Nicholas Nethercote" <nj...@ca...> Cc: <val...@li...> Sent: Sunday, July 27, 2003 10:43 PM Subject: Re: [Valgrind-users] valgrind 1.9.6 compile problem with gcc 2.95.2 on SuSE 7.1 > > ----- Original Message ----- > From: "Nicholas Nethercote" <nj...@ca...> > > No... the compiler looks like it's complaining about not knowing the > > "struct timeval" type. This is defined in bits/time.h, which is #included > > in vg_intercept.c via sys/time.h, like so: > > > > #ifdef GLIBC_2_1 > > #include <sys/time.h> > > #endif > > Thanks for the response. Removing the #ifdef GLIBC_2_1 fixed the problem. > > SuSE 7.1 uses glibc 2.2. The config.h for valgrind properly sets GLIBC_2_2: > > /* Define to 1 if you're using glibc 2.1.x */ > /* #undef GLIBC_2_1 */ > > /* Define to 1 if you're using glibc 2.2.x */ > #define GLIBC_2_2 1 > > /* Define to 1 if you're using glibc 2.3.x */ > /* #undef GLIBC_2_3 */ > > The POSIX standard states that struct timeval is defined in sys/time.h > (http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/time.h.html), so > don't understand why vg_intercept.c wraps the include of sys/time.h with > #ifdef GLIBC_2_1. Doesn't sys/time.h need to be included on glibc 2.2 and > 2.3 systems as well as glibc 2.1 systems? Is this a bug? If not, where is > vg_intercept.c suppose to get struct timeval on glibc 2.2 and 2.3 systems? > > Thanks, > Geoff Alexander > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nigel H. <nj...@ba...> - 2003-09-06 13:47:01
|
On Saturday 06 Sep 2003 2:36 pm, Tom Hughes wrote: > > If in doubt, 'use the source'. > > I disagree. The whole point of using a well known distribution is to > save yourself the bother of having to build everything yourself Exactly. > Tom -Nigel -- Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk |
|
From: Tom H. <th...@cy...> - 2003-09-06 13:37:18
|
In message <287...@se...>
Jason Gauthier <jga...@la...> wrote:
> 1) Latest RPM isn't always the latest version of make.
> You can get all the GNU stuff here: ftp://ftp.gnu.org/pub.gnu
I know that - where do you I looked to check how recent the RH version
of make was...
> 2) RH has been known to make changes to software before they package it.
> It's possible you have the latest RH RPM of make and it's still broken
> because they broke it.
I know that as well. In this case though the assertion in question
is apparently a well known issue in that version of make and is nothing
to do with any RH patches. I don't understand why different people using
the same build of make see different results though - unless there's an
uninitialised memory read in make of course ;-)
> If in doubt, 'use the source'.
I disagree. The whole point of using a well known distribution is to
save yourself the bother of having to build everything yourself, so
my rule is to use the RH vesion unless I have a good reason not to do
so. Even then I normally take the newer source and rebuild the RPM using
the RH spec file and any patches, at least in the first instance.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jason G. <jga...@la...> - 2003-09-06 12:50:42
|
Two things> 1) Latest RPM isn't always the latest version of make. You can get all the GNU stuff here: ftp://ftp.gnu.org/pub.gnu 2) RH has been known to make changes to software before they package it. It's possible you have the latest RH RPM of make and it's still broken because they broke it. If in doubt, 'use the source'. Jason > -----Original Message----- > From: Dirk Mueller [mailto:dm...@gm...] > Sent: Saturday, September 06, 2003 8:04 AM > To: val...@li... > Subject: Re: [despammed] Re: [Valgrind-users] RH9 > > On Saturday 06 September 2003 13:29, Nigel Horne wrote: > > > > Try upgrading > > > to a more recent version of 'make'. > > I have the latest RPM already. > > then the rpm is still broken. it works with any reasonably > recent make. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Tom H. <th...@cy...> - 2003-09-06 12:14:30
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Saturday 06 September 2003 13:29, Nigel Horne wrote:
>
> > > Try upgrading
> > > to a more recent version of 'make'.
> > I have the latest RPM already.
>
> then the rpm is still broken. it works with any reasonably recent make.
I have no problem building on RH9 and I am using the standard
RedHat RPM of make. Obviously some people do seem to have trouble
with 3.79 but that is only one version behind the latest, so it's
not like the 3.79 isn't reasonably recent.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dirk M. <dm...@gm...> - 2003-09-06 12:04:07
|
On Saturday 06 September 2003 13:29, Nigel Horne wrote: > > Try upgrading > > to a more recent version of 'make'. > I have the latest RPM already. then the rpm is still broken. it works with any reasonably recent make. |
|
From: Nigel H. <nj...@ba...> - 2003-09-06 11:29:19
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 06 Sep 2003 12:23 pm, you wrote: > Try upgrading > to a more recent version of 'make'. I have the latest RPM already. > > > N =2D -Nigel =2D --=20 Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/WcUIhTUd3VwpF6IRAgMSAJ9V2yPzju3GbbOS84MYpsA1GNSfiQCfQuaC 9WkZaEl0CRblAIehg/S+YQ4=3D =3Dojb2 =2D----END PGP SIGNATURE----- |
|
From: Nicholas N. <nj...@ca...> - 2003-09-06 11:23:52
|
On Sat, 6 Sep 2003, Nigel Horne wrote:
> Does valgrind support Red Hat 9? I've tried it on a couple of machines,
> but the "make" stage always fails.
From FAQ.txt:
Q16. When I trying building Valgrind, 'make' dies partway with an
assertion failure, something like this: make: expand.c:489:
allocated_variable_append: Assertion
`current_variable_set_list->next != 0' failed.
A16. It's probably a bug in 'make'. Some, but not all, instances of
version 3.79.1 have this bug, see
www.mail-archive.com/bug...@gn.../msg01658.html. Try upgrading to a
more recent version of 'make'.
N
|
|
From: Nigel H. <nj...@ba...> - 2003-09-06 11:03:03
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does valgrind support Red Hat 9? I've tried it on a couple of machines, but= the "make" stage always fails. make all-recursive make[1]: Entering directory `/home/njh/src/valgrind-20030725' Making all in coregrind make[2]: Entering directory `/home/njh/src/valgrind-20030725/coregrind' Making all in demangle make[3]: Entering directory `/home/njh/src/valgrind-20030725/coregrind/dema= ngle' if cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../include = =2DWinline -Wall -Wshadow -O -fomit-frame-pointer -g -mpreferred-stack-boun= dary=3D2 -Wno-unused -Wno-shadow -MT cp-demangle.o -MD -MP -MF ".deps/cp-d= emangle.Tpo" \ -c -o cp-demangle.o `test -f 'cp-demangle.c' || echo './'`cp-demangle.c; \ then mv ".deps/cp-demangle.Tpo" ".deps/cp-demangle.Po"; \ else rm -f ".deps/cp-demangle.Tpo"; exit 1; \ fi make: expand.c:489: allocated_variable_append: Assertion `current_variable_= set_list->next !=3D 0' failed. make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/njh/src/valgrind-20030725/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/njh/src/valgrind-20030725' make: *** [all] Error 2 =2D --=20 Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/Wb7ehTUd3VwpF6IRApqsAJ9SuJ8pyxNlBlbmqevC9BgF2P5+6wCdEPOz OXbBULD+wvn9QsHVRZHmr6Q=3D =3Dqdbp =2D----END PGP SIGNATURE----- |
|
From: Dan K. <da...@ke...> - 2003-09-06 00:03:09
|
Davide Libenzi wrote: > On Fri, 5 Sep 2003, Dan Kegel wrote: > >> Hey, check this out - somebody updated valgrind to >> work with sys_epoll! He seems to need a shared version >> of your library, maybe you can add that to your >> next release? > > Hi Dan, I made a new version with shlib generation (0.10). Thanks, Davide! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Dan K. <da...@ke...> - 2003-09-05 23:35:13
|
Nicholas Nethercote wrote: > On Thu, 24 Jul 2003, Dan Kegel wrote: > >>I can't use --skin=memcheck, as OpenOffice has so many uninitialized >>memory references Valgrind stops reporting errors. >> >>IMHO it would be worth it to make addrcheck distinguish >>between reads and writes. The problem I'm facing is >>convincing the chowderheads that a Valgrind warning is >>a serious bug. It'd be easier if the warning said >>the access was a write. > > I've just committed to the HEAD a change that does this. Bless you. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Nicholas N. <nj...@ca...> - 2003-09-05 22:17:00
|
On Fri, 15 Aug 2003, Santeri Paavolainen wrote: > >Wouldn't it be possible for valgrind to realise that the required > >environment variables aren't present and add them in again, either by > >mallocing some space for the new env array and the env entries, or by > >using a few static buffers ? > > 1. valgrind.so is hooked using LD_PRELOAD > 2. Command line arguments are passed to coregrind through the VG_ARGS > environmental variable. > 3. When an execve is trapped (vg_syscalls.c), clo_trace_children is > checked: if child tracing is enabled, valgrind does nothing. If child > tracing is disabled, mash_LD_PRELOAD_and_LD_LIBRARY_PATH is called to > modify LD_PRELOAD and LD_LIBRARY_PATH to remove valgrind. > > To allow tracing environmetal variables, I think valgrind should instead > always remove itself from LD_PRELOAD, LD_LIBRARY_PATH and clear VG_ARGS > from the environment. When it traps the execve system call, it would > look into clo_trace_children, and if child tracing is enabled, > LD_PRELOAD, LD_LIBRARY_PATH and VG_ARGS would be modified to include the > original values (since valgrind knows what the values are, this step > would just copy the known correct values in). I've been thinking about this. It is difficult. Currently, when an execve happens, if Valgrind doesn't want to trace into the child then it removes the relevant substrings from the LD_PRELOAD and LD_LIBRARY_PATH variables that are present in the 'envp' arg to execve(). (It falls over if they are missing from 'envp'.) With your proposal, Valgrind would remove the substrings at startup (and also clear VG_ARGS). When an execve happens, if Valgrind does want to trace into the children, it would add the substrings back to LD_PRELOAD and LD_LIBRARY_PATH, and restore VG_ARGS. Here's the difficulty: 'envp' is a NULL-terminated char* array. If any of the three variables weren't present, Valgrind would have to make a new copy of 'envp', copying all the old information and adding the missing variable(s). (Unless we knew there was enough room to add the new entries require, but I can't see how we could possibly know that.) The first, smaller problem: this is a space leak -- if execve happened lots of times, this would add up. The second, bigger problem: this is a space leak -- if 'envp' was malloc'd by the client program, Valgrind will (if running Memcheck or Addrcheck as its skin) identify this as a lost heap block. Which is bad, because it's not the client's fault. Valgrind can't try to free it, because 'envp' might not be malloc'd. I can't see how using static buffers would get around these problems, either. This is a shame, because Valgrind's current handling of all this is definitely broken. Can anyone see a way out? N |
|
From: Bryan O'S. <bo...@se...> - 2003-09-05 20:36:27
|
On Fri, 2003-09-05 at 13:12, David Lee wrote: > We've gotten sys_epoll support for valgrind working! It just needed the > same sort of business that select and poll (and all the other blocking > syscalls) needed. The patch is below. Jeremy Fitzhardinge has been completely reworking vg's support for blocking syscalls to make it more robust and handle signals more correctly. You may want to take a look at his current changes, and consider rebasing your epoll patch off that: http://valgrind.bkbits.net/ <b |
|
From: David L. <lee...@ho...> - 2003-09-05 20:13:29
|
We've gotten sys_epoll support for valgrind working! It just needed the same sort of business that select and poll (and all the other blocking syscalls) needed. The patch is below. We did have to modify the epoll library to generate a shared library in addition to the static library, so that the vg_intercept stuff would work. I've included that patch as well, just in case you want to be able to use the valgrind patch :-) We also had to make sure that /usr/include/asm/unistd.h had the epoll syscall #defines. How do we go about getting this worked into the CVS tree? Enjoy! dave <>< -=- Teracruz -- Performance Made Simple Learn more about Teracruz database acceleration at http://www.teracruz.com -=- valgrind patch -=- diff -uar valgrind-20030725/coregrind/vg_intercept.c valgrind-20030725-tera/coregrind/vg_intercept.c --- valgrind-20030725/coregrind/vg_intercept.c 2003-07-13 14:20:57.000000000 -0500 +++ valgrind-20030725-tera/coregrind/vg_intercept.c 2003-09-05 14:16:02.000000000 -0500 @@ -59,10 +59,12 @@ #include <errno.h> #include <sys/types.h> #include <stdio.h> +#include <stdint.h> #include <sys/ipc.h> #include <sys/msg.h> #include <asm/ipc.h> /* for ipc_kludge */ #include <sys/poll.h> +#include <sys/epoll.h> #include <sys/socket.h> #include <sys/uio.h> #ifdef GLIBC_2_1 @@ -117,6 +119,21 @@ } static __inline__ +int my_do_syscall4 ( int syscallno, + int arg1, int arg2, int arg3, int arg4 ) +{ + int __res; + __asm__ volatile ("int $0x80" + : "=a" (__res) + : "0" (syscallno), + "b" (arg1), + "c" (arg2), + "d" (arg3), + "S" (arg4) ); + return __res; +} + +static __inline__ int my_do_syscall5 ( int syscallno, int arg1, int arg2, int arg3, int arg4, int arg5 ) { @@ -368,6 +385,117 @@ strong_alias(poll, __poll) +/* ================================ epoll ================================ */ + +/* This is the master implementation of epoll_wait(). It blocks only the + calling thread. +*/ + +int VGR_(epoll_wait) (int __epfd, struct epoll_event *__events, + int __maxevents, int __timeout) +{ + unsigned int ms_now, ms_end; + int res; + struct vki_timespec nanosleep_interval; + + __my_pthread_testcancel(); + ensure_valgrind("epoll_wait"); + + /* Detect the current time and simultaneously find out if we are + running on Valgrind. */ + VALGRIND_MAGIC_SEQUENCE(ms_now, 0xFFFFFFFF /* default */, + VG_USERREQ__READ_MILLISECOND_TIMER, + 0, 0, 0, 0); + + + /* CHECK SIZES FOR struct pollfd */ + my_assert(sizeof(struct timeval) == sizeof(struct vki_timeval)); + + /* dummy initialisation to keep gcc -Wall happy */ + ms_end = 0; + + /* If a zero timeout specified, this call is harmless. Also do + this if not running on Valgrind. */ + if (__timeout == 0 || ms_now == 0xFFFFFFFF) { + res = my_do_syscall4(__NR_epoll_wait, __epfd, (int)__events, __maxevents, __timeout); + if (is_kerror(res)) { + * (__errno_location()) = -res; + return -1; + } else { + return res; + } + } + + /* If a timeout was specified, set ms_end to be the end wallclock + time. Easy considering that __timeout is in milliseconds. */ + if (__timeout > 0) { + ms_end = ms_now + (unsigned int)__timeout; + } + + //fprintf(stderr, "MY_EPOLL_WAIT: before loop\n"); + + /* Either timeout < 0, meaning wait indefinitely, or timeout > 0, + in which case t_end holds the end time. */ + + my_assert(__timeout != 0); + + while (1) { + + /* Do a return-immediately poll. */ + + res = my_do_syscall4(__NR_epoll_wait, __epfd, (int)__events, __maxevents, 0 ); + if (is_kerror(res)) { + /* Some kind of error. Set errno and return. */ + * (__errno_location()) = -res; + return -1; + } + if (res > 0) { + /* One or more fds is ready. Return now. */ + return res; + } + + /* Nothing interesting happened, so we go to sleep for a + while. */ + + /* fprintf(stderr, "MY_EPOLL_WAIT: nanosleep\n"); */ + /* nanosleep and go round again */ + nanosleep_interval.tv_sec = 0; + nanosleep_interval.tv_nsec = 13 * 1000 * 1000; /* 13 milliseconds */ + /* It's critical here that valgrind's nanosleep implementation + is nonblocking. */ + res = my_do_syscall2(__NR_nanosleep, + (int)(&nanosleep_interval), (int)NULL); + if (res == -VKI_EINTR) { + /* The nanosleep was interrupted by a signal. So we do the + same. */ + * (__errno_location()) = EINTR; + return -1; + } + + /* Sleeping finished. If a finite timeout, check to see if it + has expired yet. */ + if (__timeout > 0) { + VALGRIND_MAGIC_SEQUENCE(ms_now, 0xFFFFFFFF /* default */, + VG_USERREQ__READ_MILLISECOND_TIMER, + 0, 0, 0, 0); + my_assert(ms_now != 0xFFFFFFFF); + if (ms_now >= ms_end) { + /* timeout; nothing interesting happened. */ + return 0; + } + } + } +} + +int epoll_wait (int __epfd, struct epoll_event *__events, + int __maxevents, int __timeout) +{ + return VGR_(epoll_wait)(__epfd, __events, __maxevents, __timeout); +} + +strong_alias(epoll_wait, __epoll_wait) + + /* ================================ msgsnd ================================ */ /* Turn a blocking msgsnd() into a polling non-blocking one, so that diff -uar valgrind-20030725/coregrind/vg_syscalls.c valgrind-20030725-tera/coregrind/vg_syscalls.c --- valgrind-20030725/coregrind/vg_syscalls.c 2003-07-24 16:00:03.000000000 -0500 +++ valgrind-20030725-tera/coregrind/vg_syscalls.c 2003-09-05 14:14:20.000000000 -0500 @@ -3463,6 +3463,42 @@ VG_TRACK( post_mem_write, arg1, sizeof( vki_ksigset_t ) ) ; break ; +# if defined(__NR_epoll_create) + case __NR_epoll_create: /* syscall 254 */ + /* int epoll_create(int size) */ + MAYBE_PRINTF("epoll_create ( %d )\n", arg1); + KERNEL_DO_SYSCALL(tid,res); + break; +# endif + +# if defined(__NR_epoll_ctl) + case __NR_epoll_ctl: /* syscall 255 */ + /* int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) */ + MAYBE_PRINTF("epoll_ctl ( %d, %d, %d, %p )\n", arg1, arg2, arg3, arg4); + if (arg4 != (UInt)NULL) + { + SYSCALL_TRACK( pre_mem_read, tid, "epoll_ctl", arg4, + sizeof(struct epoll_event) ); + } + KERNEL_DO_SYSCALL(tid,res); + break; +# endif + +# if defined(__NR_epoll_wait) + case __NR_epoll_wait: /* syscall 256 */ + /* int epoll_wait(int epfd, struct epoll_event * events, int maxevents, + int timeout) */ + MAYBE_PRINTF("epoll_wait ( %d, %p, %d, %d )\n", arg1, arg2, arg3, arg4); + SYSCALL_TRACK( pre_mem_write, tid, "epoll_wait", arg2, + arg3 * sizeof(struct epoll_event) ); + KERNEL_DO_SYSCALL(tid,res); + if (!VG_(is_kerror)(res) && res > 0 && arg2 != (UInt)NULL) + { + VG_TRACK( post_mem_write, arg2, res * sizeof(struct epoll_event)); + } + break; +# endif + default: VG_(message) (Vg_DebugMsg,"FATAL: unhandled syscall: %d",syscallno); diff -uar valgrind-20030725/coregrind/vg_unsafe.h valgrind-20030725-tera/coregrind/vg_unsafe.h --- valgrind-20030725/coregrind/vg_unsafe.h 2003-06-14 03:50:27.000000000 -0500 +++ valgrind-20030725-tera/coregrind/vg_unsafe.h 2003-09-05 14:14:20.000000000 -0500 @@ -88,6 +88,7 @@ #include <sys/poll.h> +#include <sys/epoll.h> /*--------------------------------------------------------------------*/ /*--- end vg_unsafe.h ---*/ -=- epoll-lib-0.9 diff -=- diff -ur epoll-lib-0.9/Makefile epoll-lib-0.9-tera/Makefile --- epoll-lib-0.9/Makefile 2003-09-05 13:39:09.000000000 -0500 +++ epoll-lib-0.9-tera/Makefile 2003-09-05 13:40:32.000000000 -0500 @@ -12,11 +12,14 @@ # PREFIX=/usr +KERNELDIR=/usr/src/linux OUTDIR = lib TARGET = $(OUTDIR)/libepoll.a +TARGET_SONAME = libepoll.so.0 +SO_TARGET = $(OUTDIR)/libepoll.so.0.9 SRCDIR = ./src -INCLUDE = -I- -I./include -I/usr/src/linux/include +INCLUDE = -I- -I./include -I$(KERNELDIR)/include CC = gcc LD = ld @@ -44,8 +47,9 @@ .depend: $(SOURCES) $(MKDEP) $(CFLAGS) $(SOURCES) -$(TARGET): $(OBJECTS) +$(TARGET) $(SO_TARGET): $(OBJECTS) $(AR) -cr $(TARGET) $(OBJECTS) + $(LD) -shared -soname $(TARGET_SONAME) -o $(SO_TARGET) $(OBJECTS) epoll-example: $(MAKE) -C examples @@ -61,7 +65,7 @@ $(MAKE) -C examples distclean clean: - @rm -f $(TARGET) + @rm -f $(TARGET) $(SO_TARGET) @rm -f $(OBJECTS) *~ $(MAKE) -C examples clean _________________________________________________________________ Use custom emotions -- try MSN Messenger 6.0! http://www.msnmessenger-download.com/tracking/reach_emoticon |
|
From: Bob V. M.
|
Only system call that was missing while running our software through
valgrind.
The diff is against CVS HEAD.
bob
Index: coregrind/vg_syscalls.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
retrieving revision 1.42
diff -u -r1.42 vg_syscalls.c
--- coregrind/vg_syscalls.c 26 Aug 2003 17:36:26 -0000 1.42
+++ coregrind/vg_syscalls.c 5 Sep 2003 17:27:38 -0000
@@ -954,6 +954,18 @@
KERNEL_DO_SYSCALL(tid,res);
break;
+# if defined(__NR_adjtimex)
+ case __NR_adjtimex: /* syscall 124 */
+ /* int adjtimex(struct timex *buf) */
+ MAYBE_PRINTF("adjtimex ( %p )\n",arg1);
+ SYSCALL_TRACK( pre_mem_write, tst, "adjtimex(buf)",
+ arg1, sizeof(struct timex) );
+ KERNEL_DO_SYSCALL(tid,res);
+ if (!VG_(is_kerror)(res))
+ VG_TRACK( post_mem_write, arg1, sizeof(struct timex) );
+ break;
+# endif
+
/* !!!!!!!!!! New, untested syscalls, 14 Mar 02 !!!!!!!!!! */
# if defined(__NR_setresgid32)
Index: coregrind/vg_unsafe.h
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_unsafe.h,v
retrieving revision 1.14
diff -u -r1.14 vg_unsafe.h
--- coregrind/vg_unsafe.h 12 Jun 2003 20:43:20 -0000 1.14
+++ coregrind/vg_unsafe.h 5 Sep 2003 17:27:38 -0000
@@ -57,6 +57,7 @@
#include <linux/cdrom.h> /* for cd-rom ioctls */
#include <sys/user.h> /* for struct user_regs_struct et al */
#include <signal.h> /* for siginfo_t */
+#include <sys/timex.h> /* for struct timex */
#define __USE_LARGEFILE64
#include <sys/stat.h> /* for struct stat */
|
|
From: Jenny L. <jli...@pi...> - 2003-09-05 17:03:42
|
I went back to do this and noticed that the bad block was no longer on = the same line as I initially found. Weird... So I re-tracked it down = and am running objdump -S on my program. My program is over 100MB in = size. objdump took about an hour to complete and produced output of = ~98MB. The address was looking for is not in the objdump output. Any ideas why? Why does the bad block change on me? -Jenny -----Original Message----- From: Nicholas Nethercote [mailto:nj...@ca...] Sent: Friday, September 05, 2003 9:18 AM To: Jenny Lighthart Cc: val...@li... Subject: Re: [Valgrind-users] disInstr in block 1311986 On Fri, 5 Sep 2003, Jenny Lighthart wrote: > I get "Illegal instruction (core dumped)" if I let the program run > beyond block 1311986. > > Using "valgrind --stop-after=3D1311986 myprogram" produces the = following > output. Can anyone help me interpret what this means so that I can > identify a c/c++ source file to blame the breakage on? > > ------------------------- > disInstr: unhandled instruction bytes: 0x66 0xF 0x0 0xC8 > =3D=3D=3D=3D=3D=3Dvvvvvvvv=3D=3D=3D=3D=3D=3D LAST TRANSLATION = =3D=3D=3D=3D=3D=3Dvvvvvvvv=3D=3D=3D=3D=3D=3D > Original x86 code to UCode: > > 0x84C5F6C: movzwl -20(%ebp),%edx > > 0: GETL %EBP, t2 > 1: LEA1L -20(t2), t0 > 2: LDW (t0), t0 > 3: WIDENL _Wzt0 > 4: PUTL t0, %EDX > 5: INCEIPo $4 > > 0x84C5F70: disInstr: unhandled instruction bytes: 0x66 0xF = 0x0 0xC8 > > 6: CALLM_So > 7: CALLMo $0xE5 > 8: CALLM_Eo > 9: JMPo $0x84C5F73 Instruction 0x84C5F70 looks to be in the text of 'myprogram'. If 'myprogram' is compiled with debug info (-g), do "objdump -S myprogram" and find the offending instruction. The original program text should be nearby. N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-05 15:18:01
|
On Fri, 5 Sep 2003, Jenny Lighthart wrote: > I get "Illegal instruction (core dumped)" if I let the program run > beyond block 1311986. > > Using "valgrind --stop-after=1311986 myprogram" produces the following > output. Can anyone help me interpret what this means so that I can > identify a c/c++ source file to blame the breakage on? > > ------------------------- > disInstr: unhandled instruction bytes: 0x66 0xF 0x0 0xC8 > ======vvvvvvvv====== LAST TRANSLATION ======vvvvvvvv====== > Original x86 code to UCode: > > 0x84C5F6C: movzwl -20(%ebp),%edx > > 0: GETL %EBP, t2 > 1: LEA1L -20(t2), t0 > 2: LDW (t0), t0 > 3: WIDENL _Wzt0 > 4: PUTL t0, %EDX > 5: INCEIPo $4 > > 0x84C5F70: disInstr: unhandled instruction bytes: 0x66 0xF 0x0 0xC8 > > 6: CALLM_So > 7: CALLMo $0xE5 > 8: CALLM_Eo > 9: JMPo $0x84C5F73 Instruction 0x84C5F70 looks to be in the text of 'myprogram'. If 'myprogram' is compiled with debug info (-g), do "objdump -S myprogram" and find the offending instruction. The original program text should be nearby. N |
|
From: Dan K. <da...@ke...> - 2003-09-05 15:16:29
|
Wolfgang Rohdewald wrote: > I found the offending code. This is some 20 year old assembly > doing speed optimized BCD arithmetic (written for an 80286). > Since I have the same code in C (much slower), I am now using > the C code for valgrind, problem solved. > > This was the assembly code: > > adj2: > addl $0x7,0x8(%ebp) > addl $0x7,0xc(%ebp) > pushl %ds <=================== > popl %es <=================== > ret The push ds, pop es sequence is extremely common, or at least was, back in the day. Valgrind really should support it. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Jenny L. <jli...@pi...> - 2003-09-05 14:52:35
|
Hi valgrind gurus,
My program has recently stopped working with valgrind (again for those =
of you who remember my pselect/select problem).
I get "Illegal instruction (core dumped)" if I let the program run =
beyond block 1311986.
Using "valgrind --stop-after=3D1311986 myprogram" produces the following =
output. Can anyone help me interpret what this means so that I can =
identify a c/c++ source file to blame the breakage on?
Thanks in advance.
-------------------------
disInstr: unhandled instruction bytes: 0x66 0xF 0x0 0xC8
=3D=3D=3D=3D=3D=3Dvvvvvvvv=3D=3D=3D=3D=3D=3D LAST TRANSLATION =
=3D=3D=3D=3D=3D=3Dvvvvvvvv=3D=3D=3D=3D=3D=3D
Original x86 code to UCode:
0x84C5F6C: movzwl -20(%ebp),%edx
0: GETL %EBP, t2
1: LEA1L -20(t2), t0
2: LDW (t0), t0
3: WIDENL _Wzt0
4: PUTL t0, %EDX
5: INCEIPo $4
0x84C5F70: disInstr: unhandled instruction bytes: 0x66 0xF 0x0 =
0xC8
6: CALLM_So
7: CALLMo $0xE5
8: CALLM_Eo
9: JMPo $0x84C5F73
Improvements:
Improved UCode:
0: GETL %EBP, t2
1: LEA1L -20(t2), t0
2: LDW (t0), t0
3: WIDENL _Wzt0
4: PUTL t0, %EDX
5: INCEIPo $4
6: CALLM_So
7: CALLMo $0xE5
8: CALLM_Eo
9: JMPo $0x84C5F73 ($3)
Unimproved instrumented UCode:
0: GETVL %EBP, q2
1: GETL %EBP, t2
2: MOVL q2, q0
3: TAG1o q0 =3D Left4 ( q0 )
4: LEA1L -20(t2), t0
5: TESTVL q0
6: SETVL q0
7: LOADVW (t0), q0
8: LDW (t0), t0
9: TAG1o q0 =3D ZWiden24 ( q0 )
10: WIDENL _Wzt0
11: PUTVL q0, %EDX
12: PUTL t0, %EDX
13: INCEIPo $4
14: CALLM_So
15: SETVo q4
16: TESTVo q4
17: SETVo q4
18: CALLMo $0xE5
19: CALLM_Eo
20: JMPo $0x84C5F73 ($3)
Instrumentation improvements:
at 16: delete TESTV on defd arg
at 17: delete SETV
at 15: delete SETV
at 6: delete SETV
Instrumented UCode:
0: GETVL %EBP, q2
1: GETL %EBP, t2
2: MOVL q2, q0
3: TAG1o q0 =3D Left4 ( q0 )
4: LEA1L -20(t2), t0
5: TESTVL q0
7: LOADVW (t0), q0
8: LDW (t0), t0
9: TAG1o q0 =3D ZWiden24 ( q0 )
10: WIDENL _Wzt0
11: PUTVL q0, %EDX
12: PUTL t0, %EDX
13: INCEIPo $4
14: CALLM_So
18: CALLMo $0xE5
19: CALLM_Eo
20: JMPo $0x84C5F73 ($3)
Live range assignments:
LR 0 is after 4 to before 12 spillno 0
LR 1 is after 2 to before 11 spillno 1
LR 2 is after 1 to before 4 spillno 2
LR 3 is after 0 to before 2 spillno 3
Register allocated UCode:
0: GETVL %EBP, q2
0: GETVL %EBP, %eax
1: GETL %EBP, t2
1: GETL %EBP, %ebx
2: MOVL q2, q0
2: MOVL %eax, %ecx
3: TAG1o q0 =3D Left4 ( q0 )
3: TAG1o %ecx =3D Left4 ( %ecx )
4: LEA1L -20(t2), t0
4: LEA1L -20(%ebx), %edx
5: TESTVL q0
5: TESTVL %ecx
7: LOADVW (t0), q0
6: LOADVW (%dx), %cx
8: LDW (t0), t0
7: LDW (%dx), %dx
9: TAG1o q0 =3D ZWiden24 ( q0 )
8: TAG1o %ecx =3D ZWiden24 ( %ecx )
10: WIDENL _Wzt0
9: WIDENL _Wz%edx
11: PUTVL q0, %EDX
10: PUTVL %ecx, %EDX
12: PUTL t0, %EDX
11: PUTL %edx, %EDX
13: INCEIPo $4
12: INCEIPo $4
14: CALLM_So
13: CALLM_So
18: CALLMo $0xE5
14: CALLMo $0xE5
19: CALLM_Eo
15: CALLM_Eo
20: JMPo $0x84C5F73 ($3)
16: JMPo $0x84C5F73 ($3)
Generated x86 code:
0: FF 0D 24 B2 1E 40
decl (0x401EB224)
6: 75 00
jnz-8 %eip+(7)
8: BD 1D 00 00 00
movl $0x1D, %ebp
13: C3
ret
(target to jump site 7; delta: 6)
0: GETVL %EBP, %eax [a-----]
14: 8B 45 38
movl 0x38(%ebp), %eax
1: GETL %EBP, %ebx [ab----]
17: 8B 5D 14
movl 0x14(%ebp), %ebx
2: MOVL %eax, %ecx [-bc---]
20: 89 C1
movl %eax, %ecx
3: TAG1o %ecx =3D Left4 ( %ecx ) =
[-bc---]
22: 89 C8
movl %ecx, %eax
24: F7 D8
negl %eax
26: 09 C1
orl %eax, %ecx
4: LEA1L -20(%ebx), %edx [--cd--]
28: 8D 53 EC
leal 0xFFFFFFEC(%ebx), %edx
5: TESTVL %ecx [---d--]
31: 83 F9 00
cmpl $0, %ecx
34: 74 03
jz-8 %eip+3
36: FF 55 48
call * 72(%ebp)
6: LOADVW (%dx), %cx [--cd--]
39: 52
pushl %edx
40: 89 D0
movl %edx, %eax
42: FF 95 A0 03 00 00
call * 928(%ebp)
48: 89 C1
movl %eax, %ecx
50: 5A
popl %edx
7: LDW (%dx), %dx [--cd--]
51: 0F B7 12
movzwl (%edx), %edx
8: TAG1o %ecx =3D ZWiden24 ( %ecx ) =
[--cd--]
54: 81 E1 FF FF 00 00
andl $0xFFFF, %ecx
9: WIDENL _Wz%edx [--cd--]
10: PUTVL %ecx, %EDX [---d--]
60: 89 4D 2C
movl %ecx, 0x2C(%ebp)
11: PUTL %edx, %EDX [------]
63: 89 55 08
movl %edx, 0x8(%ebp)
12: INCEIPo $4 [------]
66: C6 45 64 70
movb $0x70, 0x64(%ebp)
13: CALLM_So [------]
14: CALLMo $0xE5 [------]
70: FF 95 94 03 00 00
call * 916(%ebp)
15: CALLM_Eo [------]
16: JMPo $0x84C5F73 ($3) [------]
76: B8 73 5F 4C 08
movl $0x84C5F73, %eax
81: 89 45 64
movl %eax, 0x64(%ebp)
84: 0F 0B 0F 0B 90
ud2; ud2; nop
=3D=3D=3D=3D=3D=3D^^^^^^^^=3D=3D=3D=3D=3D=3D LAST TRANSLATION =
=3D=3D=3D=3D=3D=3D^^^^^^^^=3D=3D=3D=3D=3D=3D
=3D=3D23309=3D=3D
=3D=3D23309=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 =
from 0)
=3D=3D23309=3D=3D malloc/free: in use at exit: 201916 bytes in 293 =
blocks.
=3D=3D23309=3D=3D malloc/free: 294 allocs, 1 frees, 201920 bytes =
allocated.
=3D=3D23309=3D=3D For a detailed leak analysis, rerun with: =
--leak-check=3Dyes
=3D=3D23309=3D=3D For counts of detected errors, rerun with: -v
|