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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(5) |
2
(12) |
3
(2) |
|
4
(1) |
5
(3) |
6
(4) |
7
(9) |
8
(7) |
9
(3) |
10
(4) |
|
11
(3) |
12
(16) |
13
(9) |
14
(16) |
15
(7) |
16
|
17
|
|
18
(1) |
19
(1) |
20
(9) |
21
(4) |
22
(1) |
23
(6) |
24
|
|
25
|
26
(2) |
27
(8) |
28
(12) |
29
(14) |
30
(8) |
31
(2) |
|
From: Jeffrey S. <fe...@xi...> - 2003-05-12 20:42:06
|
awesome, thanks ;-) Jeff On Mon, 2003-05-12 at 16:40, Nicholas Nethercote wrote: > On 12 May 2003, Jeffrey Stedfast wrote: > > > > I wouldn't say it gets confused; it's a syntax error, because > > > suppressions don't support stack traces with more than four entries. > > > Admittedly the error message isn't great, but I don't think this is a > > > behaviour that needs fixing. > > > > sure, except that it breaks on 4 callers ;-) > > Oh yeah. I've fixed it now in the HEAD, thanks. > > N -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. fe...@xi... - www.ximian.com |
|
From: Nicholas N. <nj...@ca...> - 2003-05-12 20:40:18
|
On 12 May 2003, Jeffrey Stedfast wrote: > > I wouldn't say it gets confused; it's a syntax error, because > > suppressions don't support stack traces with more than four entries. > > Admittedly the error message isn't great, but I don't think this is a > > behaviour that needs fixing. > > sure, except that it breaks on 4 callers ;-) Oh yeah. I've fixed it now in the HEAD, thanks. N |
|
From: Jeffrey S. <fe...@xi...> - 2003-05-12 20:19:07
|
On Mon, 2003-05-12 at 15:59, Nicholas Nethercote wrote:
> On 8 May 2003, Jeffrey Stedfast wrote:
>
> > If the number of callers specified in the suppression rule is >=
> > VG_N_SUPP_CALLERS, the parser gets confused.
> >
> > The attached patch fixes this condition.
>
> I wouldn't say it gets confused; it's a syntax error, because
> suppressions don't support stack traces with more than four entries.
> Admittedly the error message isn't great, but I don't think this is a
> behaviour that needs fixing.
sure, except that it breaks on 4 callers ;-)
the current parser only accepts 3, the 4th line MUST be a "}" line or
the next pass thru the outer loop will encounter the "}" and abort since
it doesn't match "{"
for (i = 0; i < VG_N_SUPP_CALLERS; i++) {
eof = VG_(get_line) ( fd, buf, N_BUF );
if (eof) goto syntax_error;
if (i > 0 && STREQ(buf, "}"))
break;
supp->caller[i] = VG_(arena_strdup)(VG_AR_CORE, buf);
if (!setLocationTy(&(supp->caller[i]), &(supp->caller_ty[i])))
goto syntax_error;
}
note that if VG_N_SUPP_CALLERS == 4, then the loop only gets executed a
max of 4 times - meaning a max of 4 lines read. Since the only check for
the "}"-line is inside the loop, if that "}"-line isn't read by the 4th
line, then the parser will fail for that suppressions file.
example:
{
RuleName
skin:supp_kind
fun:foo i = 0
fun:bar i = 1
fun:baz i = 2
fun:func i = 3; last pass thru the loop.
} i = 4; oops. no pass thru the loop. line not
caught.
I guess another fix would be to just read a max of one more line after
the loop to check for the "}" (you wouldn't want to change the for-loop
to accept <= VG_N_SUPP_CALLERS or you could overflow the cllaers array).
Hope my explanation helps,
Jeff
>
> N
--
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi... - www.ximian.com
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-12 19:59:50
|
On 8 May 2003, Jeffrey Stedfast wrote: > If the number of callers specified in the suppression rule is >= > VG_N_SUPP_CALLERS, the parser gets confused. > > The attached patch fixes this condition. I wouldn't say it gets confused; it's a syntax error, because suppressions don't support stack traces with more than four entries. Admittedly the error message isn't great, but I don't think this is a behaviour that needs fixing. N |
|
From: Tom H. <th...@cy...> - 2003-05-12 08:14:28
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Thanks so much for this info; I do indeed implement __errno_location()
> but I wasn't sure it's always getting used. This passing of a
> descriptor block does sound like NPTL, tho, and we're operating
> glibc-2.3.2 in old PosixThreads mode so far. We have confirmation
> from Nick that the errno test program fails on glibc-2.2.X, so
> something else must be broken.
The idea may have come from NPTL but the glibc 2.3.2 that RedHat
shipped as an update for RH8 comes with a version of linuxthreads
that works in the same way.
The main problem is that there isn't an errno_location function
pointer in the descriptor block - instead it uses the thread_descr
function to get the address of the thread descriptor and then expects
to find the thread's errno at a particular offset in that block.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2003-05-12 07:57:06
|
Dan
Attached is a patch which allows you to change stdin to whatever
you like, if you thing V is closing it.
J
------------------------------------------------------------------
[Valgrind-users] Patch to make debugging curses programs easier
Date: Sun May 11 18:31:24 2003
From: Sami Liedes <sl...@cc...>
To: val...@li...
I found the following simple changes helpful in using Valgrind to
debug curses programs with --gdb-attach=yes.
I'd be happy to know if someone has found an easier way to use
--gdb-attach=yes with curses programs; if not, this patch might be
useful for others too. With it it's possible to read the Y/N for the
"attach gdb" question from any file descriptor (--input=fd=<n>). The
--gdb-command=<command> option allows e.g. using a script to start gdb
in an xterm (or using openvt).
Attached patch against 1.9.6.
Sami
diff -ur valgrind-1.9.6/coregrind/vg_errcontext.c
valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c
--- valgrind-1.9.6/coregrind/vg_errcontext.c 2003-01-28 21:59:35.000000000
+0200
+++ valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c 2003-05-10
18:46:47.000000000 +0300
@@ -141,14 +141,14 @@
VG_(getpid)()
);
- res = VG_(read)(0 /*stdin*/, &ch, 1);
+ res = VG_(read)(VG_(clo_input_fd), &ch, 1);
if (res != 1) goto ioerror;
/* res == 1 */
if (ch == '\n') return False;
if (ch != 'N' && ch != 'n' && ch != 'Y' && ch != 'y'
&& ch != 'C' && ch != 'c') goto again;
- res = VG_(read)(0 /*stdin*/, &ch2, 1);
+ res = VG_(read)(VG_(clo_input_fd), &ch2, 1);
if (res != 1) goto ioerror;
if (ch2 != '\n') goto again;
diff -ur valgrind-1.9.6/coregrind/vg_include.h
valgrind-1.9.6-cursespatch/coregrind/vg_include.h
--- valgrind-1.9.6/coregrind/vg_include.h 2003-05-05 02:34:22.000000000
+0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_include.h 2003-05-10
17:57:12.000000000 +0300
@@ -171,6 +171,8 @@
extern Bool VG_(clo_error_limit);
/* Enquire about whether to attach to GDB at errors? default: NO */
extern Bool VG_(clo_GDB_attach);
+/* The command to run as GDB? default: gdb */
+extern Char* VG_(clo_GDB_command);
/* Sanity-check level: 0 = none, 1 (default), > 1 = expensive. */
extern Int VG_(sanity_level);
/* Automatically attempt to demangle C++ names? default: YES */
@@ -205,6 +207,8 @@
extern Int VG_(clo_logfile_fd);
extern Char* VG_(clo_logfile_name);
+/* The file descriptor to read for input. */
+extern Int VG_(clo_input_fd);
/* The number of suppression files specified. */
extern Int VG_(clo_n_suppressions);
/* The names of the suppression files. */
diff -ur valgrind-1.9.6/coregrind/vg_main.c
valgrind-1.9.6-cursespatch/coregrind/vg_main.c
--- valgrind-1.9.6/coregrind/vg_main.c 2003-05-05 03:03:40.000000000 +0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_main.c 2003-05-10
18:47:35.000000000 +0300
@@ -457,6 +457,7 @@
/* Define, and set defaults. */
Bool VG_(clo_error_limit) = True;
Bool VG_(clo_GDB_attach) = False;
+Char* VG_(clo_GDB_command) = "gdb";
Int VG_(sanity_level) = 1;
Int VG_(clo_verbosity) = 1;
Bool VG_(clo_demangle) = True;
@@ -469,6 +470,7 @@
Int VG_(clo_logfile_fd) = 2;
Char* VG_(clo_logfile_name) = NULL;
+Int VG_(clo_input_fd) = 0; /* stdin */
Int VG_(clo_n_suppressions) = 0;
Char* VG_(clo_suppressions)[VG_CLO_MAX_SFILES];
Bool VG_(clo_profile) = False;
@@ -558,6 +560,7 @@
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose, incl counts of errors\n"
" --gdb-attach=no|yes start GDB when errors detected? [no]\n"
+" --gdb-command=<command> command to run as gdb [gdb]\n"
" --demangle=no|yes automatically demangle C++ names? [yes]\n"
" --num-callers=<number> show <num> callers in stack traces [4]\n"
" --error-limit=no|yes stop showing new errors if too many? [yes]\n"
@@ -567,6 +570,7 @@
" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
" --logfile-fd=<number> file descriptor for messages [2=stderr]\n"
" --logfile=<file> log messages to <file>.pid<pid>\n"
+" --input-fd=<number> file descriptor for input [0=stdin]\n"
" --logsocket=ipaddr:port log messages to socket ipaddr:port\n"
" --suppressions=<filename> suppress errors described in\n"
" suppressions file <filename>\n"
@@ -859,6 +863,9 @@
else if (STREQ(argv[i], "--gdb-attach=no"))
VG_(clo_GDB_attach) = False;
+ else if (STREQN(14,argv[i], "--gdb-command="))
+ VG_(clo_GDB_command) = &argv[i][14];
+
else if (STREQ(argv[i], "--demangle=yes"))
VG_(clo_demangle) = True;
else if (STREQ(argv[i], "--demangle=no"))
@@ -896,6 +903,9 @@
VG_(clo_logfile_name) = &argv[i][10];
}
+ else if (STREQN(11, argv[i], "--input-fd="))
+ VG_(clo_input_fd) = (Int)VG_(atoll)(&argv[i][11]);
+
else if (STREQN(12, argv[i], "--logsocket=")) {
VG_(clo_log_to) = VgLogTo_Socket;
VG_(clo_logfile_name) = &argv[i][12];
@@ -1673,7 +1683,8 @@
Int res;
UChar buf[100];
VG_(sprintf)(buf,
- "/usr/bin/gdb -nw /proc/%d/exe %d",
+ "%s -nw /proc/%d/exe %d",
+ VG_(clo_GDB_command),
VG_(getpid)(), VG_(getpid)());
VG_(message)(Vg_UserMsg, "starting GDB with cmd: %s", buf);
res = VG_(system)(buf);
|
|
From: Dan K. <da...@ke...> - 2003-05-12 07:56:05
|
Troels Walsted Hansen wrote: >>I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2, >>which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1 >>and the errno problems didn't seem to afflict it. > > > RH8 ships with glibc 2.3.1, but 2.3.2 is available as a security update, > so many people probably have 2.3.2. > > https://rhn.redhat.com/errata/RHSA-2003-089.html > [dank@krunch dank]$ cat /etc/issue Red Hat Linux release 8.0 (Psyche) Kernel \r on an \m [dank@krunch dank]$ rpm -q -a | grep glibc glibc-2.2.93-5 glibc-devel-2.2.93-5 glibc-common-2.2.93-5 glibc-kernheaders-2.4-7.20 I don't think my system is updated. Thus I suspect Red Hat 8 ships with a prerelease version of glibc 2.3.0 called 2.2.93. (And since my problem happens on rh7.2 as well, I don't think the errno handling is the problem.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Julian S. <js...@ac...> - 2003-05-12 07:53:57
|
On Monday 12 May 2003 8:23 am, Tom Hughes wrote: > In message <200...@ac...> > > Julian Seward <js...@ac...> wrote: > > Er, yes. There's definitely some still wrong with errno handling > > on both my glibc-2.3.2 systems. The attached test program I made > > doesn't work properly -- the perror calls print different stuff when > > running on V. I'll look into it more tomorrow night. The strange > > thing is the numbers returned by the errno uses are right, it's just > > that when perror reads errno it gets junk. > > The errno handling in glibc 2.3.2 is horrible. Some of the routines > in the library don't go through the procedure linkage table when they > call the helper function that gets the address of the current thread's > errno, so they always get glibc's version of that routine instead of > the one that you have tried to replace it with. > > This works normally because libpthread calls __libc_pthread_init at > startup and gives it a descriptor block which includes a function > pointer which glibc uses to find the thread descriptor and hence the > errno to use, but if you don't call that function, and if your thread > descriptor don't match the real libpthread ones, then it all falls > apart. Thanks so much for this info; I do indeed implement __errno_location() but I wasn't sure it's always getting used. This passing of a descriptor block does sound like NPTL, tho, and we're operating glibc-2.3.2 in old PosixThreads mode so far. We have confirmation from Nick that the errno test program fails on glibc-2.2.X, so something else must be broken. > This is why wine now deliberately writes a jmp instruction over the > first instruction of glibc's internal errno address getting routine > so that it guarantee to get control at that point... Hmm. J |
|
From: Troels W. H. <tr...@th...> - 2003-05-12 07:44:01
|
> I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2, > which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1 > and the errno problems didn't seem to afflict it. RH8 ships with glibc 2.3.1, but 2.3.2 is available as a security update, so many people probably have 2.3.2. https://rhn.redhat.com/errata/RHSA-2003-089.html -- Troels |
|
From: Dan K. <da...@ke...> - 2003-05-12 07:29:42
|
Dan Kegel wrote: > The good news is, I verified that valgrind 1.9.6 on Red Hat 7.2 > does run openoffice1.1beta just fine. > I believe I'm unstuck now, and will continue with OO on valgrind > next chance I get. Damn, damn, damn. Nope. Here's the deal: even on red hat 7.2, only the first couple of errors invoke gdb properly. After that, when gdb is invoked, something is wrong with stdin; gdb thinks it's at EOF. Think openoffice is closing stdin? For what it's worth, here's the bug I'm really going after: http://www.openoffice.org/project/www/issues/show_bug.cgi?id=14046 To reproduce it, just load the file FR0453p.doc into ooo1.1beta1 or the later snapshot build 644_m11. Without valgrind, you have to click on the first page, click Format/arrange/send to back (or any of the other arrange commands, probably), then undo, to trigger the crash. With Valgrind, I get ==6614== Invalid memory access of size 2 ==6614== at 0x41020329: (within /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4101F934: (within /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4102043A: XSubtractRegion (in /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4102049B: XXorRegion (in /usr/X11R6/lib/libX11.so.6.2) ==6614== Address 0x42C1D970 is 0 bytes after a block of size 16 alloc'd ==6614== at 0x40150E99: realloc (vg_clientfuncs.c:276) ==6614== by 0x4101A78A: (within /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4101AEB7: XPolygonRegion (in /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x40590A17: SalGraphics::DrawPolyPolygon(unsigned long, unsigned long const*, SalPoint const**, OutputDevice const*) (in /home/dank/opt/OpenOffice.org1.1Beta/program/libvcl644li.so) ==6614== as soon as the file finishes loading; you don't even have to do the send-to-back/undo thing. Saying 'y' to valgrind at that point starts gdb, but it goes haywire as if the keyboard isn't really attached anymore. I'd like to get a backtrace with gdb there. - 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-05-12 07:26:14
|
On Mon, 12 May 2003, Julian Seward wrote: > Er, yes. There's definitely some still wrong with errno handling > on both my glibc-2.3.2 systems. The attached test program I made > doesn't work properly -- the perror calls print different stuff when > running on V. I'll look into it more tomorrow night. The strange > thing is the numbers returned by the errno uses are right, it's just > that when perror reads errno it gets junk. > > Nick, can you lmk if it works on R H 7.1? Thx, Hmm, I don't think so: [~/grind/head] a.out f1 = 0x804b8a8, errno1 = 4 wurble1: Interrupted system call f2 = (nil), errno2 = 2 wurble2: No such file or directory f3 = (nil), errno3 = 2 wurble3: No such file or directory [~/grind/head] vg6 a.out ==557== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==557== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==557== Using valgrind-cvs-head-2003-04-23, a program supervision framework for x86-linux. ==557== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==557== Estimated CPU clock rate is 1405 MHz ==557== For more details, rerun with: -v ==557== f1 = 0x40fd8194, errno1 = 0 wurble1: Success f2 = (nil), errno2 = 2 wurble2: No such file or directory f3 = (nil), errno3 = 2 wurble3: No such file or directory ==557== ==557== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 2) ==557== malloc/free: in use at exit: 564 bytes in 2 blocks. ==557== malloc/free: 9 allocs, 7 frees, 2408 bytes allocated. ==557== For a detailed leak analysis, rerun with: --leak-check=yes ==557== For counts of detected errors, rerun with: -v |
|
From: Tom H. <th...@cy...> - 2003-05-12 07:24:31
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Er, yes. There's definitely some still wrong with errno handling
> on both my glibc-2.3.2 systems. The attached test program I made
> doesn't work properly -- the perror calls print different stuff when
> running on V. I'll look into it more tomorrow night. The strange
> thing is the numbers returned by the errno uses are right, it's just
> that when perror reads errno it gets junk.
The errno handling in glibc 2.3.2 is horrible. Some of the routines
in the library don't go through the procedure linkage table when they
call the helper function that gets the address of the current thread's
errno, so they always get glibc's version of that routine instead of
the one that you have tried to replace it with.
This works normally because libpthread calls __libc_pthread_init at
startup and gives it a descriptor block which includes a function
pointer which glibc uses to find the thread descriptor and hence the
errno to use, but if you don't call that function, and if your thread
descriptor don't match the real libpthread ones, then it all falls
apart.
This is why wine now deliberately writes a jmp instruction over the
first instruction of glibc's internal errno address getting routine
so that it guarantee to get control at that point...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dan K. <da...@ke...> - 2003-05-12 05:52:48
|
Hi all!
Now that I have my nice shiny new valgrind1.9.6 running on Red Hat 7.2
with OpenOffice1.1beta1, I'd like to figure out whether the errors
that pop up are real or not.
Here's the first one that shows up:
==6424== Invalid memory access of size 1
==6424== at 0x4119C4C5: _STL::basic_string<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t> >::basic_string(wchar_t const*, _STL::allocator<wchar_t> const&) (in /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424== by 0x41162A2F: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424== by 0x41162B11: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424== by 0x41171E46: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424== Address 0xBFFFF4C9 is just below %esp. Possibly a bug in GCC/G++
==6424== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes
==6424==
==6424== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==6424== starting GDB with cmd: /usr/bin/gdb -nw /proc/6424/exe 6424
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
...
(gdb) bt
#0 vg_do_syscall3 (syscallno=65535, arg1=1, arg2=3221222680, arg3=1091971632) at vg_mylibc.c:92
#1 0x0000191c in ?? () at eval.c:41
#2 0x4119c4c5 in _STL::basic_string<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t> >::basic_string(wchar_t const*, _STL::allocator<wchar_t> const&) ()
from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#3 0x41162a30 in _STL::numpunct<wchar_t>::do_falsename() const ()
from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#4 0x41162b12 in _STL::numpunct<wchar_t>::do_falsename() const ()
from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#5 0x41171e47 in _STL::tanh(_STL::complex<long double> const&) ()
from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#6 0x411556b6 in _init () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#7 0x4000d9e7 in _dl_init () at eval.c:41
That one looks real to me (although I can't for the life of me
figure out what punctuation has to do with hyperbolic tangents).
I think OpenOffice contains its own copy of
STL, which appears to have an off-by one bug. Or is it
really just a gcc bug, and I should do as the message suggests?
Anyone know of valgrind issues in stlport.org's stl implementation?
Second problem: at startup time, I get this:
==18415== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
==18415== at 0x40170F87: vgAllRoadsLeadToRome_writev (vg_intercept.c:108)
==18415== by 0x40170FC4: __writev (vg_intercept.c:733)
==18415== by 0x40C2588F: (within /usr/X11R6/lib/libX11.so.6.2)
==18415== by 0x40C264CE: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
==18415== Address 0x43F51058 is 32 bytes inside a block of size 2048 alloc'd
==18415== at 0x4015E780: calloc (vg_clientfuncs.c:245)
==18415== by 0x40BF852B: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==18415== by 0x4048C395: SalXLib::Init(int*, char**) (in /opt/OpenOffice.org644/program/libvcl644li.so)
==18415== by 0x4048BFD8: SalData::Init(int*, char**) (in /opt/OpenOffice.org644/program/libvcl644li.so)
This might just be normal X library behavior; see
http://keithp.com/~keithp/talks/usenix2003/html/net.html,
which says "Gian Filippo Pinzari [Pin03] has recently pointed out that
Xlib does not zero out unused bytes in the protocol stream but
transmits the left over bytes in the protocol buffer where the requests are formed. "
Doesn't sound valgrind-friendly offhand. Ripe for suppression?
Guidence from the masters would be welcome. I'll probably be bugging
this list quite a bit in the next few days as I come up to speed
on valgrind/ooo.
Thanks,
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-05-12 05:25:06
|
Julian Seward (jseward at acm.org) wrote: > Hi. First off, I think OpenOffice is an important project > and am pleased to hear someone is valgrinding it. OO is my > biggest, most hairy test case. If it's possible, I'd like to > help the OOo developers be in the position where they routinely > valgrindify OOo, in the same way that the KDE and Gnome folks > use it routinely. Excellent! I'm hoping to use it quickly in the next few days to help make OpenOffice 1.1 beta more solid. I don't know if the openoffice developers are using it yet; I'm just a gadfly who got a bee in his bonnet about a backlog of untriaged bugs in the openoffice bug tracking system, and jumped in to help sort through them and mark the interesting ones for the developers to work on. > I don't a RH8 box to repro this on. But I have just tried > gdb attach/detach on SuSE 8.2 on the OOo 1.0.2 they supply, > and that works fine using the valgrind cvs head. I did it a > bit different from you, perhaps: > > LD_LIBRARY_PATH=/opt/OpenOffice.org/program \ > ./Inst/bin/valgrind -v -v --skin=addrcheck \ > --gdb-attach=yes /opt/OpenOffice.org/program/soffice.bin > > I did all that directly on the command line, no shell script > or anything. Perhaps your shell script ./soffice-valgrind.sh > is causing a problem? Can you try something equivalent to the > above? Thanks for that nice short line. (I had been clumsily editing the soffice script without bothering to understand it.) However, I get the same results with that as with my script. Also, your errno patch didn't have any impact on the strange problem I had running valgrind 1.9.6 on Red Hat 8, just as you expected. The good news is, I verified that valgrind 1.9.6 on Red Hat 7.2 does run openoffice1.1beta just fine. I believe I'm unstuck now, and will continue with OO on valgrind next chance I get. > The following is a question re OO on V. With the help of Michael > Meeks at Ximian, I did manage to build from source various cvs > branches of OO (cws_srx644_ooo11beta, in the end) and valgrinded > them. What I noticed was that (1) the number of mallocs/frees > reported by V was surprisingly low, compared with 1.0.2, > and (2) all the buffer-overrun errors had disappeared. And so > I wondered if OO had moved to using some kind of internal > allocator which V cannot 'see' ? Alternatively of course all > those bugs have been fixed. No idea - but I'll pass the question on to de...@op.... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Julian S. <js...@ac...> - 2003-05-12 00:03:26
|
> However... I managed to recreate the exact same problem with another
> testcase. The new testcase contains the same code, but runs in a
> different thread. Script is attached.
Er, yes. There's definitely some still wrong with errno handling
on both my glibc-2.3.2 systems. The attached test program I made
doesn't work properly -- the perror calls print different stuff when
running on V. I'll look into it more tomorrow night. The strange
thing is the numbers returned by the errno uses are right, it's just
that when perror reads errno it gets junk.
Nick, can you lmk if it works on R H 7.1? Thx,
J
#include <pthread.h>
#include <stdio.h>
#include <errno.h>
void* thr2 ( void* v )
{
FILE* f = fopen("bogus2", "r");
printf("f2 = %p, errno2 = %d\n", f, errno);
perror("wurble2");
return NULL;
}
void* thr3 ( void* v )
{
FILE* f = fopen("bogus3", "r");
printf("f3 = %p, errno3 = %d\n", f, errno);
perror("wurble3");
return NULL;
}
int main ( void )
{
FILE* f;
pthread_t tid2, tid3;
pthread_create(&tid2, NULL, &thr2, NULL);
pthread_create(&tid3, NULL, &thr3, NULL);
f = fopen("bogus", "r");
printf("f1 = %p, errno1 = %d\n", f, errno);
perror("wurble1");
pthread_join(tid2, NULL);
pthread_join(tid3, NULL);
return 0;
}
|
|
From: Julian S. <js...@ac...> - 2003-05-11 22:28:48
|
Hi. First off, I think OpenOffice is an important project and am pleased to hear someone is valgrinding it. OO is my biggest, most hairy test case. If it's possible, I'd like to help the OOo developers be in the position where they routinely valgrindify OOo, in the same way that the KDE and Gnome folks use it routinely. I don't a RH8 box to repro this on. But I have just tried gdb attach/detach on SuSE 8.2 on the OOo 1.0.2 they supply, and that works fine using the valgrind cvs head. I did it a bit different from you, perhaps: LD_LIBRARY_PATH=/opt/OpenOffice.org/program \ ./Inst/bin/valgrind -v -v --skin=addrcheck \ --gdb-attach=yes /opt/OpenOffice.org/program/soffice.bin I did all that directly on the command line, no shell script or anything. Perhaps your shell script ./soffice-valgrind.sh is causing a problem? Can you try something equivalent to the above? I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2, which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1 and the errno problems didn't seem to afflict it. Nevertheless I attach a patch which fixes the problem and you should apply it to your 1.9.6. It'll be rolled into 1.9.7. Let me know the outcome of the above. The following is a question re OO on V. With the help of Michael Meeks at Ximian, I did manage to build from source various cvs branches of OO (cws_srx644_ooo11beta, in the end) and valgrinded them. What I noticed was that (1) the number of mallocs/frees reported by V was surprisingly low, compared with 1.0.2, and (2) all the buffer-overrun errors had disappeared. And so I wondered if OO had moved to using some kind of internal allocator which V cannot 'see' ? Alternatively of course all those bugs have been fixed. J On Sunday 11 May 2003 9:13 pm, Dan Kegel wrote: > Hi, I'm using valgrind 1.9.6 on redhat 8.0 with OpenOffice. > It seems to work fine with no options, but if I turn on > --gdb-attach=yes, I don't get what I expect. On the > first error, it asks me nicely if I want to run gdb, > and it does start gdb, but here's what I see: > > ==18736== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y > ==18736== starting GDB with cmd: /usr/bin/gdb -nw /proc/18736/exe 18736 > GNU gdb Red Hat Linux (5.2.1-4) > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are welcome to change it and/or distribute copies of it under certain > conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux"... > (no debugging symbols found)... > Attaching to program: /opt/OpenOffice.org644/program/soffice.bin, process > 18736 Reading symbols from > /usr/local/lib/valgrind/vgskin_memcheck.so...done. Loaded symbols for > /usr/local/lib/valgrind/vgskin_memcheck.so > Reading symbols from /usr/local/lib/valgrind/valgrind.so...done. > Loaded symbols for /usr/local/lib/valgrind/valgrind.so > Reading symbols from /opt/OpenOffice.org644/program/libvcl644li.so...done. > Loaded symbols for /opt/OpenOffice.org644/program/libvcl644li.so > ... etc etc ... > Reading symbols from /opt/OpenOffice.org644/program/libsal.so.3...done. > Loaded symbols for /opt/OpenOffice.org644/program/libsal.so.3 > Reading symbols from /usr/X11R6/lib/libXext.so.6...done. > Loaded symbols for /usr/X11R6/lib/libXext.so.6 > > [1]+ Stopped ./soffice-valgrind.sh > > If I then do a fg, it seems to continue, but things are all screwed up. > gdb goes away as soon as it finishes loading up: > > vg_do_syscall3 (syscallno=4294966784, arg1=18738, arg2=0, arg3=0) > at vg_mylibc.c:92 > 92 } > (gdb) ==18736== > ==18736== GDB has detached. Valgrind regains control. We continue. > > and the app continues on, seemingly in the background, while I'm > dumped back to the shell. Very odd. > > Any suggestions? > > Thanks, > Dan |
|
From: Dan K. <da...@ke...> - 2003-05-11 19:49:29
|
Hi, I'm using valgrind 1.9.6 on redhat 8.0 with OpenOffice.
It seems to work fine with no options, but if I turn on
--gdb-attach=yes, I don't get what I expect. On the
first error, it asks me nicely if I want to run gdb,
and it does start gdb, but here's what I see:
==18736== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==18736== starting GDB with cmd: /usr/bin/gdb -nw /proc/18736/exe 18736
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Attaching to program: /opt/OpenOffice.org644/program/soffice.bin, process 18736
Reading symbols from /usr/local/lib/valgrind/vgskin_memcheck.so...done.
Loaded symbols for /usr/local/lib/valgrind/vgskin_memcheck.so
Reading symbols from /usr/local/lib/valgrind/valgrind.so...done.
Loaded symbols for /usr/local/lib/valgrind/valgrind.so
Reading symbols from /opt/OpenOffice.org644/program/libvcl644li.so...done.
Loaded symbols for /opt/OpenOffice.org644/program/libvcl644li.so
... etc etc ...
Reading symbols from /opt/OpenOffice.org644/program/libsal.so.3...done.
Loaded symbols for /opt/OpenOffice.org644/program/libsal.so.3
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
[1]+ Stopped ./soffice-valgrind.sh
If I then do a fg, it seems to continue, but things are all screwed up.
gdb goes away as soon as it finishes loading up:
vg_do_syscall3 (syscallno=4294966784, arg1=18738, arg2=0, arg3=0)
at vg_mylibc.c:92
92 }
(gdb) ==18736==
==18736== GDB has detached. Valgrind regains control. We continue.
and the app continues on, seemingly in the background, while I'm
dumped back to the shell. Very odd.
Any suggestions?
Thanks,
Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
|
|
From: Sami L. <sl...@cc...> - 2003-05-11 17:30:57
|
I found the following simple changes helpful in using Valgrind to
debug curses programs with --gdb-attach=yes.
I'd be happy to know if someone has found an easier way to use
--gdb-attach=yes with curses programs; if not, this patch might be
useful for others too. With it it's possible to read the Y/N for the
"attach gdb" question from any file descriptor (--input=fd=<n>). The
--gdb-command=<command> option allows e.g. using a script to start gdb
in an xterm (or using openvt).
Attached patch against 1.9.6.
Sami
diff -ur valgrind-1.9.6/coregrind/vg_errcontext.c valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c
--- valgrind-1.9.6/coregrind/vg_errcontext.c 2003-01-28 21:59:35.000000000 +0200
+++ valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c 2003-05-10 18:46:47.000000000 +0300
@@ -141,14 +141,14 @@
VG_(getpid)()
);
- res = VG_(read)(0 /*stdin*/, &ch, 1);
+ res = VG_(read)(VG_(clo_input_fd), &ch, 1);
if (res != 1) goto ioerror;
/* res == 1 */
if (ch == '\n') return False;
if (ch != 'N' && ch != 'n' && ch != 'Y' && ch != 'y'
&& ch != 'C' && ch != 'c') goto again;
- res = VG_(read)(0 /*stdin*/, &ch2, 1);
+ res = VG_(read)(VG_(clo_input_fd), &ch2, 1);
if (res != 1) goto ioerror;
if (ch2 != '\n') goto again;
diff -ur valgrind-1.9.6/coregrind/vg_include.h valgrind-1.9.6-cursespatch/coregrind/vg_include.h
--- valgrind-1.9.6/coregrind/vg_include.h 2003-05-05 02:34:22.000000000 +0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_include.h 2003-05-10 17:57:12.000000000 +0300
@@ -171,6 +171,8 @@
extern Bool VG_(clo_error_limit);
/* Enquire about whether to attach to GDB at errors? default: NO */
extern Bool VG_(clo_GDB_attach);
+/* The command to run as GDB? default: gdb */
+extern Char* VG_(clo_GDB_command);
/* Sanity-check level: 0 = none, 1 (default), > 1 = expensive. */
extern Int VG_(sanity_level);
/* Automatically attempt to demangle C++ names? default: YES */
@@ -205,6 +207,8 @@
extern Int VG_(clo_logfile_fd);
extern Char* VG_(clo_logfile_name);
+/* The file descriptor to read for input. */
+extern Int VG_(clo_input_fd);
/* The number of suppression files specified. */
extern Int VG_(clo_n_suppressions);
/* The names of the suppression files. */
diff -ur valgrind-1.9.6/coregrind/vg_main.c valgrind-1.9.6-cursespatch/coregrind/vg_main.c
--- valgrind-1.9.6/coregrind/vg_main.c 2003-05-05 03:03:40.000000000 +0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_main.c 2003-05-10 18:47:35.000000000 +0300
@@ -457,6 +457,7 @@
/* Define, and set defaults. */
Bool VG_(clo_error_limit) = True;
Bool VG_(clo_GDB_attach) = False;
+Char* VG_(clo_GDB_command) = "gdb";
Int VG_(sanity_level) = 1;
Int VG_(clo_verbosity) = 1;
Bool VG_(clo_demangle) = True;
@@ -469,6 +470,7 @@
Int VG_(clo_logfile_fd) = 2;
Char* VG_(clo_logfile_name) = NULL;
+Int VG_(clo_input_fd) = 0; /* stdin */
Int VG_(clo_n_suppressions) = 0;
Char* VG_(clo_suppressions)[VG_CLO_MAX_SFILES];
Bool VG_(clo_profile) = False;
@@ -558,6 +560,7 @@
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose, incl counts of errors\n"
" --gdb-attach=no|yes start GDB when errors detected? [no]\n"
+" --gdb-command=<command> command to run as gdb [gdb]\n"
" --demangle=no|yes automatically demangle C++ names? [yes]\n"
" --num-callers=<number> show <num> callers in stack traces [4]\n"
" --error-limit=no|yes stop showing new errors if too many? [yes]\n"
@@ -567,6 +570,7 @@
" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
" --logfile-fd=<number> file descriptor for messages [2=stderr]\n"
" --logfile=<file> log messages to <file>.pid<pid>\n"
+" --input-fd=<number> file descriptor for input [0=stdin]\n"
" --logsocket=ipaddr:port log messages to socket ipaddr:port\n"
" --suppressions=<filename> suppress errors described in\n"
" suppressions file <filename>\n"
@@ -859,6 +863,9 @@
else if (STREQ(argv[i], "--gdb-attach=no"))
VG_(clo_GDB_attach) = False;
+ else if (STREQN(14,argv[i], "--gdb-command="))
+ VG_(clo_GDB_command) = &argv[i][14];
+
else if (STREQ(argv[i], "--demangle=yes"))
VG_(clo_demangle) = True;
else if (STREQ(argv[i], "--demangle=no"))
@@ -896,6 +903,9 @@
VG_(clo_logfile_name) = &argv[i][10];
}
+ else if (STREQN(11, argv[i], "--input-fd="))
+ VG_(clo_input_fd) = (Int)VG_(atoll)(&argv[i][11]);
+
else if (STREQN(12, argv[i], "--logsocket=")) {
VG_(clo_log_to) = VgLogTo_Socket;
VG_(clo_logfile_name) = &argv[i][12];
@@ -1673,7 +1683,8 @@
Int res;
UChar buf[100];
VG_(sprintf)(buf,
- "/usr/bin/gdb -nw /proc/%d/exe %d",
+ "%s -nw /proc/%d/exe %d",
+ VG_(clo_GDB_command),
VG_(getpid)(), VG_(getpid)());
VG_(message)(Vg_UserMsg, "starting GDB with cmd: %s", buf);
res = VG_(system)(buf);
|
|
From: Troels W. H. <tr...@th...> - 2003-05-10 16:09:28
|
Hi Julian,
I can confirm that your patch solved my testcase. I tested Valgrind
1.9.6 + patch (applied with a small offset) on RH9.
However... I managed to recreate the exact same problem with another
testcase. The new testcase contains the same code, but runs in a
different thread. Script is attached.
$ python dbboguserrno2.py
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap
self.run()
File "dbboguserrno2.py", line 8, in run
filetype = db.DB_BTREE)
File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
d.open(filename, dbname, filetype, flags, mode)
DBNoSuchFileError: (2, 'No such file or directory')
$ valgrind python dbboguserrno2.py
==24099== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==24099== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==24099== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==24099== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==24099== Estimated CPU clock rate is 436 MHz
==24099== For more details, rerun with: -v
==24099==
==24099== valgrind's libpthread.so: IGNORED call to:
pthread_attr_destroy
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap
self.run()
File "dbboguserrno2.py", line 8, in run
filetype = db.DB_BTREE)
File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
d.open(filename, dbname, filetype, flags, mode)
DBAgainError: (11, 'Resource temporarily unavailable')
Troels
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Julian
Seward
Sent: 10. mai 2003 02:03
To: Troels Walsted Hansen; val...@li...
Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
Thanks for chasing this down. The attached patch fixes it for me on
R H 9 and SuSE 8.2. Perhaps you can try it?
J
On Wednesday 07 May 2003 10:01 am, Troels Walsted Hansen wrote:
> Sorry, I managed to forget to attach the script.
>
> Here's the script, as well as two straces, created with the below
> commands, on a RH8+glibc 2.3.3 machine.
>
> strace python dbboguserrno.py 2> strace-normal.txt
> strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
>
> Both traces show the below syscall, but the instance running in
Valgrind
> seems to get EAGAIN instead...
>
> open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> Troels
|
|
From: Julian S. <js...@ac...> - 2003-05-10 10:28:50
|
Ah, that's great. Thanks. I had wondered about how to fix that problem. J On Saturday 10 May 2003 9:57 am, Troels Walsted Hansen wrote: > Restarting valgrind-listener quickly can produce the error below. > Attached patch fixes it by enabling SO_REUSEADDR for the listening > socket. > > $ valgrind-listener > valgrind-listener started at Sat May 10 10:39:43 2003 > cannot bind port : Address already in use > > valgrind-listener: the `impossible' happened: > main -- bind port > Please report this bug to: js...@ac... |
|
From: Troels W. H. <tr...@th...> - 2003-05-10 08:58:09
|
Restarting valgrind-listener quickly can produce the error below. Attached patch fixes it by enabling SO_REUSEADDR for the listening socket. $ valgrind-listener valgrind-listener started at Sat May 10 10:39:43 2003 cannot bind port : Address already in use valgrind-listener: the `impossible' happened: main -- bind port Please report this bug to: js...@ac... -- Troels |
|
From: Julian S. <js...@ac...> - 2003-05-10 00:03:32
|
Thanks for chasing this down. The attached patch fixes it for me on
R H 9 and SuSE 8.2. Perhaps you can try it?
J
On Wednesday 07 May 2003 10:01 am, Troels Walsted Hansen wrote:
> Sorry, I managed to forget to attach the script.
>
> Here's the script, as well as two straces, created with the below
> commands, on a RH8+glibc 2.3.3 machine.
>
> strace python dbboguserrno.py 2> strace-normal.txt
> strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
>
> Both traces show the below syscall, but the instance running in Valgrind
> seems to get EAGAIN instead...
>
> open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> Troels
>
> > -----Original Message-----
> > From: Nicholas Nethercote [mailto:nj...@he...] On
> > Behalf Of Nicholas Nethercote
> > Sent: 7. mai 2003 10:43
> > To: Troels Walsted Hansen
> > Cc: val...@li...
> > Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
> >
> > On Wed, 7 May 2003, Troels Walsted Hansen wrote:
> > > This is the expected behavior of the program.
> > >
> > > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
> > >
> > > This is what happens in Valgrind. RH8 and RH9 uses
> >
> > BerkeleyDB 4.0.14,
> >
> > > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> > > nosuchfile.db: Resource temporarily unavailable')
> >
> > It's possible that Valgrind's doing something slightly
> > different with file
> > handling that means you get a different behaviour. Do you have more
> > information about what exactly is happening to prompt this
> > error? Eg. is
> > it trying to open a file with the open() system call, or
> > something like
> > that? It's very difficult to know what the problem is from your
> > description so far.
> >
> > N
|
|
From: Mathieu M. <Mat...@cr...> - 2003-05-09 13:36:29
|
Hi all,
For those of you that are using nvidia driver here is my nvidia.supp
file. I have just discovered that there was a new nvidia driver out
there. I hope I'll just need to 'sed' from one version to the other.
HTH
mathieu
Ps: my nvidia name are dummy, but this is closed source software! You
won't be able to do anything even if you will.
#-------- For nvidia-1.0-4349
{
nvidia1
Memcheck:Cond
fun:__nvsym16906
}
{
nvidia2
Memcheck:Cond
obj:/usr/lib/libGLcore.so.1.0.4349
}
{
nvidia3
Memcheck:Cond
fun:NvRmAlloc
}
{
nvidia4
Memcheck:Cond
fun:strcat
fun:__nvsym17797
}
{
nvidia5
Memcheck:Param
modify_ldt(ptr)(func=1 or 0x11)
obj:/usr/lib/libGL.so.1.0.4349
}
{
nvidia6
Memcheck:Value4
obj:/usr/lib/libGLcore.so.1.0.4349
}
{
nvidia-leak1
Memcheck:Leak
fun:malloc
fun:__nvsym17642
}
{
nvidia-leak2
Memcheck:Leak
fun:malloc
obj:/usr/lib/libGL.so.1.0.4349
}
{
nvidia-leak3
Memcheck:Leak
fun:malloc
fun:XextAddDisplay
fun:__nvsym17642
}
# 0x413ACB6C: __nvsym17758 (in /usr/lib/libGL.so.1.0.4349)
{
nvidia-leak4
Memcheck:Leak
fun:calloc
fun:_dlerror_run
fun:dlopen@@GLIBC_2.1
}
# 0x413ACF46: __nvsym17729 (in /usr/lib/libGL.so.1.0.4349)
{
nvidia-leak5
Memcheck:Leak
fun:calloc
fun:__nvsym17729
}
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-09 12:15:28
|
On Fri, 9 May 2003 Joh...@al... wrote:
> Is there any documentation on the usage of suppressions, ie: adding your
> own? The manual just skips over it, and the example docs in the provided
> suppression files are cryptic to say the least. Google turned up
> nothing. I got the old write(buf) one to work, but others seem to be
> just ignored.
The manual is weak on suppressions. One important thing: C++ function
names must be _mangled_; use --demangle=no to get mangled names in error
messages.
Or, to make life much easier, check out the CVS HEAD from the
Valgrind SourceForge page, build it (see README for instructions), and use
the --gen-suppressions option to automatically generate suppressions for
you. This will answer many of your questions, or remove the need for
answers.
> Is Memcheck simply a leak check, and Addrcheck an address validation
> function? Can you suppression uninitialised variables with either of these?
Memcheck checks the validity (definedness) and addressibility of all
memory reads. Addrcheck only does addressibility checking. Both do leak
checking (with --leak-check=yes). Only Memcheck gives errors for
uninitialised variables, and yes you can suppress them.
> What does supp_kind mean, ie: Param vs Free vs Cond
Means "what kind of error is it"?
> are the fun: / obj: sequential, ie:
>
> fun:_dl_relocate_object*
> obj:*libc-2.2.?.so
> fun:_dl_catch_error*
>
> Does that mean its _dl_relocate_object, which is called by anything in
> libc-2.2 and then called by _dl_catch_error.
Yes, except the '*' is a wildcard. The lines reflect the stack trace in
the error.
> Oh yeah, is the order from bottom to top, ie: is the last function
> first, rather than other way around (I know its the former, but its nice
> to get it stated in documentation...)
First function is the most recently called, ie. the one the error occurred
in.
> Whats core: mean?
The bit before the ':' on the second line indicates what 'skin' (eg.
Memcheck, Addrcheck, etc) the suppression is for; Valgrind's "core" can
detect some errors itself too, in which case you use "core:".
> {
> pthread_error/__pthread_mutex_destroy/_IO_default_finish
> core:PThread
> fun:pthread_error
> fun:__pthread_mutex_destroy
> fun:_IO_default_finish*
> }
>
> The qualifiers, sometimes we get Memcheck:Value4? Addr4? An explanation
> would be nice.
>
> Any pointers to information such as this would be great.
The manual will be improved eventually. Meanwhile, get the CVS HEAD
version and use --gen-suppressions, it will make your life much easier.
N
|
|
From: <Joh...@al...> - 2003-05-09 11:19:42
|
Is there any documentation on the usage of suppressions, ie: adding your
own? The manual just skips over it, and the example docs in the provided
suppression files are cryptic to say the least. Google turned up
nothing. I got the old write(buf) one to work, but others seem to be
just ignored.
Typical things which would be nice to know:
Memcheck vs Addrcheck:
Is Memcheck simply a leak check, and Addrcheck an address validation
function? Can you suppression uninitialised variables with either of these?
What does supp_kind mean, ie: Param vs Free vs Cond
What is the qualification for these, ie: using of the optional pars?
are the fun: / obj: sequential, ie:
fun:_dl_relocate_object*
obj:*libc-2.2.?.so
fun:_dl_catch_error*
Does that mean its _dl_relocate_object, which is called by anything in
libc-2.2 and then called by _dl_catch_error.
Oh yeah, is the order from bottom to top, ie: is the last function
first, rather than other way around (I know its the former, but its nice
to get it stated in documentation...)
Whats core: mean?
{
pthread_error/__pthread_mutex_destroy/_IO_default_finish
core:PThread
fun:pthread_error
fun:__pthread_mutex_destroy
fun:_IO_default_finish*
}
The qualifiers, sometimes we get Memcheck:Value4? Addr4? An explanation
would be nice.
Any pointers to information such as this would be great.
Great project though.
Thanks
John
|