|
From: Melchior F. <mf...@kd...> - 2003-11-13 21:38:15
|
There's an annoying bug in valgrind 2.0.0 (and probably older
versions). I'm memchecking a program with --gdb-attach=yes and
--suppressions=file, and with (among other rules) this in my
suppressions file:
{
<foo>
Memcheck:Cond
fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE18_M_really_overflowEi
fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE8overflowEi
fun:_ZNSt15basic_streambufIcSt11char_traitsIcEE5sputcEc
fun:_ZN6logbuf8overflowEi
}
But valgrind doesn't stop after displaying bugs, instead everything
rushes by without prompting me to start gdb. If, however, I change
any of the "fun:" lines so that the mangled symbol doesn't match
any more, then valgrind will stop after the next bug.
m. ??
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-13 22:55:49
|
On Thu, 13 Nov 2003, Melchior FRANZ wrote:
> There's an annoying bug in valgrind 2.0.0 (and probably older
> versions). I'm memchecking a program with --gdb-attach=yes and
> --suppressions=file, and with (among other rules) this in my
> suppressions file:
>
> {
> <foo>
> Memcheck:Cond
> fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE18_M_really_overflowEi
> fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE8overflowEi
> fun:_ZNSt15basic_streambufIcSt11char_traitsIcEE5sputcEc
> fun:_ZN6logbuf8overflowEi
> }
>
> But valgrind doesn't stop after displaying bugs, instead everything
> rushes by without prompting me to start gdb. If, however, I change
> any of the "fun:" lines so that the mangled symbol doesn't match
> any more, then valgrind will stop after the next bug.
I'm sorry, I don't understand. These errors you want to attach GDB to --
are they being suppressed? It would help if you could explain what you're
doing in more detail. Thanks.
N
|
|
From: Melchior F. <mf...@kd...> - 2003-11-13 23:26:03
|
* Nicholas Nethercote -- Thursday 13 November 2003 23:55:
> I'm sorry, I don't understand. These errors you want to attach GDB to --
> are they being suppressed? It would help if you could explain what you're
> doing in more detail.
No. They are shown, but vg doesn't prompt me to attach gdb to them.
Here's some more detail (all mentioned files in coregrind/):
1. vg_errcontext.c:116:
after each detected error "is_action_requested" is called
2. vg_errorcontext.c:133:
res = VG_(read)(VG_(clo_input_fd), &ch, 1);
checks for user input
3. vg_mylibc.c:1166:
VG_(read) calls system's "read" which does occasionally
return -EAGAIN!
4. vg_errorcontext.c:134:
goes to ioerror
5. vg_errorcontext.c:152:
disables prompting for the rest of the session, only
because of this silly EAGAIN
The following quick fix works for me (but is prone to cause
an endless loop :-)
Index: vg_mylibc.c
===================================================================
RCS file: /home/kde/valgrind/coregrind/vg_mylibc.c,v
retrieving revision 1.45
diff -u -p -r1.45 vg_mylibc.c
--- vg_mylibc.c 6 Jul 2003 01:14:42 -0000 1.45
+++ vg_mylibc.c 13 Nov 2003 23:11:45 -0000
@@ -31,6 +31,7 @@
*/
#include "vg_include.h"
+#include <errno.h>
@@ -1167,7 +1168,9 @@ Int VG_(read) ( Int fd, void* buf, Int c
{
Int res;
/* res = read( fd, buf, count ); */
- res = vg_do_syscall3(__NR_read, fd, (UInt)buf, count);
+ do {
+ res = vg_do_syscall3(__NR_read, fd, (UInt)buf, count);
+ } while (res == -EAGAIN);
if (VG_(is_kerror)(res)) res = -1;
return res;
}
m.
PS: this is Linux 2.4.20, gcc 3.3, libc 2.3.2, SuSE 8.1
|
|
From: Melchior F. <mf...@kd...> - 2003-11-14 12:43:41
|
* Melchior FRANZ -- Friday 14 November 2003 00:14: > * Nicholas Nethercote -- Thursday 13 November 2003 23:55: > > I'm sorry, I don't understand. These errors you want to attach GDB to -- > > are they being suppressed? It would help if you could explain what you're > > doing in more detail. > > No. They are shown, [...] No wait. They are shown if the rule doesn't match (because I made a change to any of the fun: lines, such as removing or adding a letter). Otherwise, if the rule matches, vg only displays ==20796== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- after the next (unsuppressed) error, but doesn't really let me type 'y' but instantly displays the next error, after which it doesn't stop either, and so on. All error messages rush by. As I told you, I know the reason for all that (-> the unhandled -EAGAIN), but I don't know how this particular suppression rule could have any impact on this seemingly unrelated issue. m. |