You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2010-01-27 17:14:41
|
On Wednesday 27 January 2010, Konstantin Serebryany wrote: > I've minimized the problem to a small test (below). > It spawns many threads and doesn't join them before exiting. > It will hang (or loop forever) one out of 40-100 runs: > % g++ -g -lpthread hang.cc > % for((i=10;i<=99;i++)); do date; time ~/valgrind/trunk/inst/bin/valgrind > --tool=none --trace-syscalls=yes --trace-signals=yes -q ./a.out 2> $i.log > ; done Ok; managed to reproduce it. 2 threads were still stuck in some syscall (don't know which yet). Investigating. J |
|
From: Julian S. <js...@ac...> - 2010-01-27 16:54:54
|
> Also, I'd like to propose new annotations for barriers. We can annotate
> barriers in terms of the above 4, but that hardwires the assumption that
> the underlying checker has a concept of h-b edges. I'd prefer a set
> of macros which merely specify the state of the barrier:
>
> B_RESET(bar)
> state that nobody is waiting for the barrier
>
> B_ARRIVE(bar)
> i have arrived at the barrier
>
> B_DEPART(bar, Bool i_am_the_last_to_depart)
> i have left the barrier, and give an indication of whether or
> not I am the last to leave. (If so, the checker would
> probably want to behave like B_RESET).
Actually, even with those, I think it is impossible to guarantee a correct
annotation in the worst-case race condition. In the worst-case condition
we need an arbitrary number of VTSs associated with the barrier, and also
to track how many threads are waiting at the barrier.
This is because it could be that threads leaving the "real" barrier
call/mechanism stall and do not get to the B_DEPART request (at which
point their VTSs are updated) before a whole different set of threads arrive
at the barrier, pass through it, add their own set of edges to it. Then
the original threads finally get to their B_DEPART requests, at which
point they get the edges of these "overtaking" threads incorrectly
added.
IOW we need to deal in the worst case with an arbitrary delay between
a thread leaving the barrier proper and having its state updated at
the B_DEPART request.
Hence I am now thinking instead of the following annotations:
B_INITIALISE(bar, int capacity)
initialise; state capacity
void* abstract_handle = B_ARRIVE(bar)
arrive at barrier. obtain abstract handle (a VTS*, essentially) from
which we need to update when leaving
B_DEPART(bar, abstract_handle)
depart from barrier, updating our VTS using the one we were given
by B_ARRIVE
---------------------
One other thing. I think, for the semantics of the annotations to make
sense generally, you need to say that, although the checker may run the
threads concurrently, it must process each annotation atomically. It
sounds like hair splitting, I know, but .. it's hard to see what the
effect would be if processing of annotations was allowed to happen
concurrently.
J
|
|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:10
|
Konstantin, I'm trying to annotate a user-implemented barrier, using http://code.google.com/p/google-perftools/source/browse/trunk/src/base/dynamic_annotations.h specifically ANNOTATE_HAPPENS_BEFORE and ANNOTATE_HAPPENS_AFTER like this void barrier_wait ( barrier* b ) { ANNOTATE_HAPPENS_BEFORE(b); // the barrier implementation ANNOTATE_HAPPENS_AFTER(b); } But this doesn't work well, and I think it's not clear what semantics you intended for these two. This situation I can understand: T1: AH_BEFORE(obj) T2: AH_AFTER(obj) then we get an edge T1->T2 But what about this? T1: AH_BEFORE(obj) T2: AH_BEFORE(obj) T3: AH_AFTER(obj) Should we get edges T1->T3 and T2->T3, or only T2->T3 ? IOW, does a call AH_BEFORE(obj) cause obj to "forget" about any previous AH_BEFORE calls on it? It seems to me that to annotate a barrier properly requires generating two edges in this example, not just one. (Plus then it requires a way to tell obj to "forget everything" when the barrier is reinitialised, so that subsequent uses of it do not end up generating edges back to previous uses.) J |
|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:07
|
> > But this doesn't work well, and I think it's not clear what semantics
> > you intended for these two.
> >
> > This situation I can understand:
> >
> > T1: AH_BEFORE(obj)
> > T2: AH_AFTER(obj)
> >
> > then we get an edge T1->T2
> >
> > But what about this?
> >
> > T1: AH_BEFORE(obj)
> > T2: AH_BEFORE(obj)
> > T3: AH_AFTER(obj)
> >
> > Should we get edges T1->T3 and T2->T3,
>
> Yes, we will get two edges.
> The h-before events are never forgotten. (ThreadSanitizer forgets them when
> it flushes the entire state)
I don't think it is good that the behaviour AH_BEFORE is hardwired
in this way. It makes the annotation set inflexible. What do you
think of the following proposal?
AH_BEFORE_OVERWRITE(obj)
forget everything in obj, then acquire a h-b dep from caller
AH_BEFORE_ACCUMULATE(obj)
merge in a h-b dep from caller; don't forget history
so your AH_BEFORE == AH_BEFORE_ACCUMULATE
AH_AFTER(obj)
acquire h-b edges from obj (unchanged)
A_FORGET(obj)
forget everything
You may not find A_FORGET and AH_BEFORE_OVERWRITE useful, but at least
there presence (+ clarification of the semantics) makes it more
flexible and controllable.
Also, I'd like to propose new annotations for barriers. We can annotate
barriers in terms of the above 4, but that hardwires the assumption that
the underlying checker has a concept of h-b edges. I'd prefer a set
of macros which merely specify the state of the barrier:
B_RESET(bar)
state that nobody is waiting for the barrier
B_ARRIVE(bar)
i have arrived at the barrier
B_DEPART(bar, Bool i_am_the_last_to_depart)
i have left the barrier, and give an indication of whether or
not I am the last to leave. (If so, the checker would
probably want to behave like B_RESET).
J
|
|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:06
|
Uh, this unfortunately kills the VALGRIND_PRINTF_BACKTRACE macro
at least on amd64-linux, and, I suspect, on all platforms (V segfaults).
Problem is this
union {
va_list vargs;
unsigned long t;
} args;
va_start(args.vargs, format);
VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, VG_USERREQ__PRINTF,
(unsigned long)format, (unsigned long)(args.t),
0, 0, 0);
on amd64-linux, sizeof(vargs) == 24. So what this code does is
to initialise a 24-byte structure, pass the first 8 bytes of it
to the client request ("unsigned long)(args.t)"). Back on the
"other side of the fence", the client request handler does this
union {
va_list vargs;
unsigned long t;
} args;
Int count;
args.t = (unsigned long)arg[2];
count =
VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], args.vargs );
that is, initialises the first 1/3 of the 24-byte structure with supplied
8 bytes, passes the whole structure to VG_(vmessage), and segfaults.
We can only pass machine words as arguments in client requests. So the
obvious solution is to pass a reference to the vargs structure rather
than (trying to pass) the structure itself.
This is all somewhat complicated by the fact that VG_USERREQ__PRINTF
effectively constitutes a public API, and we can't change the behaviour
of it. So there needs to be a new VG_USERREQ__PRINTF_VARGS_BY_REF request
and the VALGRIND_PRINTF_BACKTRACE (et al) macros should then use that.
J
On Monday 04 January 2010, Julian Seward wrote:
> Committed as r11006. Thanks.
>
> J
>
> On Wednesday 23 December 2009, Dmitry Zhurikhin wrote:
> > Hello.
> >
> > It seems like ARM branch can't be compiled with recent versions of GCC
> > (stock GCC 4.4 and CodeSourcery arm-2008q3 or even earlier). A patch is
> > attached that allows building of Valgrind. Probably the reason for the
> > failure is in the GCC version 4.4 changelog: "On ARM EABI targets, the
> > C++ mangling of the va_list type has been changed to conform to the
> > current revision of the EABI". This should mean that for ARM va_list is
> > not integer (but a structure it seems) anymore which is still true for
> > other platforms that Valgrind supports. Valgrind sources are written in
> > such a way that it wants va_list to be able to be casted to an integer
> > type implicitly. This is no longer available in current GCC for ARM.
> > Seems like CodeSourcery made this change a little bit earlier (as
> > original GCC version 4.3.2 is able to build Valgrind without errors).
> > Please review the patch. It only makes a cast using union.
> >
> > Following is the error log:
> > In file included from m_debuglog.c:57:
> > ../include/valgrind.h: In function 'VALGRIND_PRINTF':
> > ../include/valgrind.h:4186: error: aggregate value used where an integer
> > was expected
> > ../include/valgrind.h: In function 'VALGRIND_PRINTF_BACKTRACE':
> > ../include/valgrind.h:4201: error: aggregate value used where an integer
> > was expected
> > make[3]: *** [libcoregrind_arm_linux_a-m_debuglog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > mv -f .deps/libcoregrind_arm_linux_a-m_debugger.Tpo
> > .deps/libcoregrind_arm_linux_a-m_debugger.Po
> > mv -f .deps/libcoregrind_arm_linux_a-m_commandline.Tpo
> > .deps/libcoregrind_arm_linux_a-m_commandline.Po
> > make[3]: Leaving directory
> > `/home/batuzovk/valgrind/valgrind-clean/coregrind' make[2]: *** [all]
> > Error 2
> > make[2]: Leaving directory
> > `/home/batuzovk/valgrind/valgrind-clean/coregrind' make[1]: ***
> > [all-recursive] Error 1
> > make[1]: Leaving directory `/home/batuzovk/valgrind/valgrind-clean'
> > make: *** [all] Error 2
> >
> >
> > Regards,
> > Dmitry
>
> ---------------------------------------------------------------------------
>--- This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Konstantin S. <kon...@gm...> - 2010-01-27 14:17:55
|
On Wed, Jan 27, 2010 at 3:41 PM, Julian Seward <js...@ac...> wrote: > > Konstantin, > > I'm trying to annotate a user-implemented barrier, using > > > http://code.google.com/p/google-perftools/source/browse/trunk/src/base/dynamic_annotations.h > specifically ANNOTATE_HAPPENS_BEFORE and ANNOTATE_HAPPENS_AFTER > > like this > > void barrier_wait ( barrier* b ) > { > ANNOTATE_HAPPENS_BEFORE(b); > // the barrier implementation > ANNOTATE_HAPPENS_AFTER(b); > } > this is exactly how I handle barrier. > > But this doesn't work well, and I think it's not clear what semantics > you intended for these two. > > This situation I can understand: > > T1: AH_BEFORE(obj) > T2: AH_AFTER(obj) > > then we get an edge T1->T2 > > But what about this? > > T1: AH_BEFORE(obj) > T2: AH_BEFORE(obj) > T3: AH_AFTER(obj) > > Should we get edges T1->T3 and T2->T3, Yes, we will get two edges. The h-before events are never forgotten. (ThreadSanitizer forgets them when it flushes the entire state) > or only T2->T3 ? IOW, does > a call AH_BEFORE(obj) cause obj to "forget" about any previous > AH_BEFORE calls on it? > > It seems to me that to annotate a barrier properly requires generating > two edges in this example, not just one. (Plus then it requires > a way to tell obj to "forget everything" when the barrier is reinitialised, > so that subsequent uses of it do not end up generating edges back to > previous uses.) > That would be possible by adding yet another annotation (ANNOTATE_FORGET_HB_EDGES(obj)) but I never found this really useful, at least in ThreadSanitizer. --kcc > > J > |
|
From: <sv...@va...> - 2010-01-27 10:28:10
|
Author: sewardj
Date: 2010-01-27 10:28:00 +0000 (Wed, 27 Jan 2010)
New Revision: 11031
Log:
Fix handling of mprotect so as to be more consistent with the handling
of mmap. Fixes #205541 and its dup #210268. The fix is simple enough
but the analysis is a bit complex, as detailed in comments.
Modified:
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/mc_main.c
===================================================================
--- trunk/memcheck/mc_main.c 2010-01-26 13:26:41 UTC (rev 11030)
+++ trunk/memcheck/mc_main.c 2010-01-27 10:28:00 UTC (rev 11031)
@@ -1636,6 +1636,22 @@
}
}
+/* Similarly (needed for mprotect handling ..) */
+static void make_mem_defined_if_noaccess ( Addr a, SizeT len )
+{
+ SizeT i;
+ UChar vabits2;
+ DEBUG("make_mem_defined_if_noaccess(%p, %llu)\n", a, (ULong)len);
+ for (i = 0; i < len; i++) {
+ vabits2 = get_vabits2( a+i );
+ if (LIKELY(VA_BITS2_NOACCESS == vabits2)) {
+ set_vabits2(a+i, VA_BITS2_DEFINED);
+ if (UNLIKELY(MC_(clo_mc_level) >= 3)) {
+ MC_(helperc_b_store1)( a+i, 0 ); /* clear the origin tag */
+ }
+ }
+ }
+}
/* --- Block-copy permissions (needed for implementing realloc() and
sys_mremap). --- */
@@ -3701,17 +3717,87 @@
}
}
+/* Handling of mmap and mprotect is not as simple as it seems.
+
+ The underlying semantics are that memory obtained from mmap is
+ always initialised, but may be inaccessible. And changes to the
+ protection of memory do not change its contents and hence not its
+ definedness state. Problem is we can't model
+ inaccessible-but-with-some-definedness state; once we mark memory
+ as inaccessible we lose all info about definedness, and so can't
+ restore that if it is later made accessible again.
+
+ One obvious thing to do is this:
+
+ mmap/mprotect NONE -> noaccess
+ mmap/mprotect other -> defined
+
+ The problem case here is: taking accessible memory, writing
+ uninitialised data to it, mprotecting it NONE and later mprotecting
+ it back to some accessible state causes the undefinedness to be
+ lost.
+
+ A better proposal is:
+
+ (1) mmap NONE -> make noaccess
+ (2) mmap other -> make defined
+
+ (3) mprotect NONE -> # no change
+ (4) mprotect other -> change any "noaccess" to "defined"
+
+ (2) is OK because memory newly obtained from mmap really is defined
+ (zeroed out by the kernel -- doing anything else would
+ constitute a massive security hole.)
+
+ (1) is OK because the only way to make the memory usable is via
+ (4), in which case we also wind up correctly marking it all as
+ defined.
+
+ (3) is the weak case. We choose not to change memory state.
+ (presumably the range is in some mixture of "defined" and
+ "undefined", viz, accessible but with arbitrary V bits). Doing
+ nothing means we retain the V bits, so that if the memory is
+ later mprotected "other", the V bits remain unchanged, so there
+ can be no false negatives. The bad effect is that if there's
+ an access in the area, then MC cannot warn; but at least we'll
+ get a SEGV to show, so it's better than nothing.
+
+ Consider the sequence (3) followed by (4). Any memory that was
+ "defined" or "undefined" previously retains its state (as
+ required). Any memory that was "noaccess" before can only have
+ been made that way by (1), and so it's OK to change it to
+ "defined".
+
+ See https://bugs.kde.org/show_bug.cgi?id=205541
+ and https://bugs.kde.org/show_bug.cgi?id=210268
+*/
static
void mc_new_mem_mmap ( Addr a, SizeT len, Bool rr, Bool ww, Bool xx,
ULong di_handle )
{
- if (rr || ww || xx)
+ if (rr || ww || xx) {
+ /* (2) mmap/mprotect other -> defined */
MC_(make_mem_defined)(a, len);
- else
+ } else {
+ /* (1) mmap/mprotect NONE -> noaccess */
MC_(make_mem_noaccess)(a, len);
+ }
}
static
+void mc_new_mem_mprotect ( Addr a, SizeT len, Bool rr, Bool ww, Bool xx )
+{
+ if (rr || ww || xx) {
+ /* (4) mprotect other -> change any "noaccess" to "defined" */
+ make_mem_defined_if_noaccess(a, len);
+ } else {
+ /* (3) mprotect NONE -> # no change */
+ /* do nothing */
+ }
+}
+
+
+static
void mc_new_mem_startup( Addr a, SizeT len,
Bool rr, Bool ww, Bool xx, ULong di_handle )
{
@@ -5780,7 +5866,7 @@
//
// So we should arguably observe all this. However:
// - The current inaccuracy has caused maybe one complaint in seven years(?)
- // - Telying on the zeroed-ness of whole brk'd pages is pretty grotty... I
+ // - Relying on the zeroed-ness of whole brk'd pages is pretty grotty... I
// doubt most programmers know the above information.
// So I'm not terribly unhappy with marking it as undefined. --njn.
//
@@ -5790,21 +5876,15 @@
// just mark all memory it allocates as defined.]
//
VG_(track_new_mem_brk) ( make_mem_undefined_w_tid );
+
+ // Handling of mmap and mprotect isn't simple (well, it is simple,
+ // but the justification isn't.) See comments above, just prior to
+ // mc_new_mem_mmap.
VG_(track_new_mem_mmap) ( mc_new_mem_mmap );
+ VG_(track_change_mem_mprotect) ( mc_new_mem_mprotect );
VG_(track_copy_mem_remap) ( MC_(copy_address_range_state) );
- // Nb: we don't do anything with mprotect. This means that V bits are
- // preserved if a program, for example, marks some memory as inaccessible
- // and then later marks it as accessible again.
- //
- // If an access violation occurs (eg. writing to read-only memory) we let
- // it fault and print an informative termination message. This doesn't
- // happen if the program catches the signal, though, which is bad. If we
- // had two A bits (for readability and writability) that were completely
- // distinct from V bits, then we could handle all this properly.
- VG_(track_change_mem_mprotect) ( NULL );
-
VG_(track_die_mem_stack_signal)( MC_(make_mem_noaccess) );
VG_(track_die_mem_brk) ( MC_(make_mem_noaccess) );
VG_(track_die_mem_munmap) ( MC_(make_mem_noaccess) );
|
|
From: Konstantin S. <kon...@gm...> - 2010-01-27 09:47:29
|
On Wed, Jan 27, 2010 at 12:59 PM, Julian Seward <js...@ac...> wrote: > On Wednesday 27 January 2010, Konstantin Serebryany wrote: > > I've minimized the problem to a small test (below). > > Good that there's a small test case now. > > So .. this is on which platform? something-linux, or something-darwin? > I am seeing it on x86_64 linux (ubuntu 8.04) w/o the --trace-... flags it hangs more often: for((i=10;i<=99;i++)); do date; time ~/valgrind/trunk/inst/bin/valgrind --tool=none -q ./a.out 2> $i.log ; done > > J > |
|
From: Julian S. <js...@ac...> - 2010-01-27 09:44:51
|
On Wednesday 27 January 2010, Konstantin Serebryany wrote: > I've minimized the problem to a small test (below). Good that there's a small test case now. So .. this is on which platform? something-linux, or something-darwin? J |
|
From: Konstantin S. <kon...@gm...> - 2010-01-27 09:37:43
|
I've minimized the problem to a small test (below).
It spawns many threads and doesn't join them before exiting.
It will hang (or loop forever) one out of 40-100 runs:
% g++ -g -lpthread hang.cc
% for((i=10;i<=99;i++)); do date; time ~/valgrind/trunk/inst/bin/valgrind
--tool=none --trace-syscalls=yes --trace-signals=yes -q ./a.out 2> $i.log ;
done
Even nulgrind is affected.
Any suggestion?
Thanks,
--kcc
--------------------------------------------------------------------------------------------------------
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
void *run(void *p) {
for (int i = 0; ; i++) {
usleep(100);
fprintf(stderr, "T=%d i=%d\n", (int)pthread_self(), i);
}
return NULL;
}
int main(int argc, char** argv) {
for (int i = 0; i < 200; i++) {
pthread_t t;
pthread_create(&t, NULL, run, NULL);
}
fprintf(stderr, "exiting main\n");
return 0;
}
--------------------------------------------------------------------------------------------------------
On Mon, Jan 18, 2010 at 12:56 PM, Julian Seward <js...@ac...> wrote:
> On Monday 18 January 2010, Konstantin Serebryany wrote:
> > On Wed, Jan 13, 2010 at 4:54 PM, Julian Seward <js...@ac...> wrote:
> > > > Any idea how to attack the problem?
> > > > Any workaround?
> > >
> > > Don't know, sorry. Obviously if you can reduce it to a test case
> > > that is small enough to be debuggable
> >
> > trying...
> >
> > When strace-ing an already hung process, I see this line:
> > read(32761, <unfinished ...>
> >
> > Does it tell you anything?
> > Does 32761 look like a legitimate fd?
>
> Hmm, I don't know. I don't think it's legit but am not sure.
>
> J
>
> >
> > --kcc
> >
> > > , that would be a big help.
> > >
> > > J
>
>
>
|
|
From: Bart V. A. <bar...@gm...> - 2010-01-27 09:04:01
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-27 02:34:32 EST Ended at 2010-01-27 04:03:42 EST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 449 tests, 43 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Bart V. A. <bar...@gm...> - 2010-01-27 07:28:01
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-27 02:27:50 EST Ended at 2010-01-27 02:27:54 EST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-27T02:27:50} valgrind-new conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Configuring valgrind ... cd valgrind-new && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-new/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Building valgrind ... cd valgrind-new && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Running regression tests ... cd valgrind-new && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-26T02:27:50} valgrind-old conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Configuring valgrind ... cd valgrind-old && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-old/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Building valgrind ... cd valgrind-old && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Running regression tests ... cd valgrind-old && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Jan 27 02:27:54 2010 --- new.short Wed Jan 27 02:27:54 2010 *************** *** 8,10 **** ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-26T02:27:50} valgrind-old conf/cellbuzz-native.conf: line 16: qsub: command not found --- 8,10 ---- ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-27T02:27:50} valgrind-new conf/cellbuzz-native.conf: line 16: qsub: command not found *************** *** 12,14 **** cat: cmd-output.txt: No such file or directory ! Configuring valgrind ... cd valgrind-old && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-old/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found --- 12,14 ---- cat: cmd-output.txt: No such file or directory ! Configuring valgrind ... cd valgrind-new && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-new/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found *************** *** 16,18 **** cat: cmd-output.txt: No such file or directory ! Building valgrind ... cd valgrind-old && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found --- 16,18 ---- cat: cmd-output.txt: No such file or directory ! Building valgrind ... cd valgrind-new && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found *************** *** 20,22 **** cat: cmd-output.txt: No such file or directory ! Running regression tests ... cd valgrind-old && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found --- 20,22 ---- cat: cmd-output.txt: No such file or directory ! Running regression tests ... cd valgrind-new && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found |
|
From: Alexander P. <gl...@go...> - 2010-01-27 06:51:58
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-27 09:06:02 MSK Ended at 2010-01-27 09:29:26 MSK Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 433 tests, 22 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Jan 27 09:18:31 2010 --- new.short Wed Jan 27 09:29:26 2010 *************** *** 8,10 **** ! == 433 tests, 22 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/null_socket (stdout) --- 8,10 ---- ! == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) *************** *** 32,34 **** helgrind/tests/tc23_bogus_condwait (stderr) - drd/tests/pth_detached (stdout) --- 32,33 ---- -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-01-27 03:49:50
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-27 03:05:04 GMT Ended at 2010-01-27 03:49:32 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-27 03:35:54
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-27 03:10:06 GMT Ended at 2010-01-27 03:35:41 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 2 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Jan 27 03:22:59 2010 --- new.short Wed Jan 27 03:35:41 2010 *************** *** 8,11 **** ! == 538 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Julian S. <js...@ac...> - 2010-01-26 19:10:25
|
On Tuesday 26 January 2010, Rich Coe wrote: > Hi Julian, > > I was looking at https://bugs.kde.org/show_bug.cgi?id=205541 and wanted > to know more about what are the Wine test cases. 205541 isn't specific to running Wine on V. It's really a more general bug about how mmap and mprotect are handled in Memcheck. It's just that the problem appears particularly acutely in Wine. > Does V need a set of testcases which test all the mprotect cases ? memcheck/tests/addressable.c contains some tests for this stuff, although definitely it is not comprehensive enough. If you want to extend it or add a new case, that would be no bad thing. J |
|
From: Rich C. <Ric...@me...> - 2010-01-26 16:02:43
|
Hi Julian, I was looking at https://bugs.kde.org/show_bug.cgi?id=205541 and wanted to know more about what are the Wine test cases. Does V need a set of testcases which test all the mprotect cases ? Thanks, Rich -- |
|
From: <sv...@va...> - 2010-01-26 13:27:17
|
Author: sewardj
Date: 2010-01-26 13:26:41 +0000 (Tue, 26 Jan 2010)
New Revision: 11030
Log:
Fix up debug printing for the PDB reader, so it can be properly
controlled from the command line. Recommended flags are
-v --trace-symtab=yes "--trace-symtab-patt=*nameofinteresting.exe"
Also print entry/exit information for DEBUG_SnarfCodeView and
DEBUG_SnarfLinetab.
Modified:
trunk/coregrind/m_debuginfo/readpdb.c
Modified: trunk/coregrind/m_debuginfo/readpdb.c
===================================================================
--- trunk/coregrind/m_debuginfo/readpdb.c 2010-01-21 10:24:37 UTC (rev 11029)
+++ trunk/coregrind/m_debuginfo/readpdb.c 2010-01-26 13:26:41 UTC (rev 11030)
@@ -1201,8 +1201,6 @@
/*--- ---*/
/*------------------------------------------------------------*/
-static Bool debug = False; // JRS: fixme
-
static ULong DEBUG_SnarfCodeView(
DebugInfo* di,
IMAGE_SECTION_HEADER* sectp,
@@ -1216,12 +1214,13 @@
UChar* nmstr;
Char symname[4096 /*WIN32_PATH_MAX*/];
+ Bool debug = di->trace_symtab;
Addr bias = BIAS_FOR_SYMBOLS;
ULong n_syms_read = 0;
if (debug)
VG_(message)(Vg_UserMsg,
- "SnarfCodeView addr=%p offset=%d length=%d\n",
+ "BEGIN SnarfCodeView addr=%p offset=%d length=%d\n",
root, offset, size );
VG_(memset)(&vsym, 0, sizeof(vsym)); /* avoid holes */
@@ -1262,7 +1261,7 @@
symname[sym->data_v1.p_name.namelen] = '\0';
if (debug)
- VG_(message)(Vg_UserMsg, "Data %s\n", symname );
+ VG_(message)(Vg_UserMsg, " Data %s\n", symname );
if (0 /*VG_(needs).data_syms*/) {
nmstr = ML_(addStr)(di, symname, sym->data_v1.p_name.namelen);
@@ -1287,7 +1286,7 @@
if (debug)
VG_(message)(Vg_UserMsg,
- "S_GDATA_V2/S_LDATA_V2/S_PUB_V2 %s\n", symname );
+ " S_GDATA_V2/S_LDATA_V2/S_PUB_V2 %s\n", symname );
if (sym->generic.id==S_PUB_V2 /*VG_(needs).data_syms*/) {
nmstr = ML_(addStr)(di, symname, k);
@@ -1318,7 +1317,7 @@
if (debug)
VG_(message)(Vg_UserMsg,
- "S_PUB_FUNC1_V3/S_PUB_FUNC2_V3/S_PUB_V3 %s\n",
+ " S_PUB_FUNC1_V3/S_PUB_FUNC2_V3/S_PUB_V3 %s\n",
symname );
if (1 /*sym->generic.id==S_PUB_FUNC1_V3
@@ -1368,7 +1367,7 @@
vsym.isIFunc = False;
if (debug)
VG_(message)(Vg_UserMsg,
- "Adding function %s addr=%#lx length=%d\n",
+ " Adding function %s addr=%#lx length=%d\n",
symname, vsym.addr, vsym.size );
ML_(addSym)( di, &vsym );
n_syms_read++;
@@ -1389,7 +1388,7 @@
vsym.isIFunc = False;
if (debug)
VG_(message)(Vg_UserMsg,
- "Adding function %s addr=%#lx length=%d\n",
+ " Adding function %s addr=%#lx length=%d\n",
symname, vsym.addr, vsym.size );
ML_(addSym)( di, &vsym );
n_syms_read++;
@@ -1398,7 +1397,7 @@
case S_GPROC_V3: {
if (debug)
VG_(message)(Vg_UserMsg,
- "S_LPROC_V3/S_GPROC_V3 %s\n", sym->proc_v3.name );
+ " S_LPROC_V3/S_GPROC_V3 %s\n", sym->proc_v3.name );
if (1) {
nmstr = ML_(addStr)(di, sym->proc_v3.name,
@@ -1483,6 +1482,10 @@
} /* for ( i = offset; i < size; i += length ) */
+ if (debug)
+ VG_(message)(Vg_UserMsg,
+ "END SnarfCodeView addr=%p offset=%d length=%d\n",
+ root, offset, size );
return n_syms_read;
}
@@ -1529,9 +1532,15 @@
struct startend * start;
Int this_seg;
+ Bool debug = di->trace_symtab;
Addr bias = BIAS_FOR_LINETAB;
ULong n_lines_read = 0;
+ if (debug)
+ VG_(message)(Vg_UserMsg,
+ "BEGIN SnarfLineTab linetab=%p size=%d\n",
+ linetab, size );
+
/*
* Now get the important bits.
*/
@@ -1600,7 +1609,7 @@
if (debug)
VG_(message)(Vg_UserMsg,
- "Adding %d lines for file %s segment %d addr=%#x end=%#x\n",
+ " Adding %d lines for file %s segment %d addr=%#x end=%#x\n",
linecount, filename, segno, start[k].start, start[k].end );
for ( j = 0; j < linecount; j++ ) {
@@ -1612,7 +1621,7 @@
: start[k].end);
if (debug)
VG_(message)(Vg_UserMsg,
- "Adding line %d addr=%#lx end=%#lx\n",
+ " Adding line %d addr=%#lx end=%#lx\n",
((unsigned short *)(pnt2.ui + linecount))[j],
startaddr, endaddr );
ML_(addLineInfo)(
@@ -1624,6 +1633,11 @@
}
}
+ if (debug)
+ VG_(message)(Vg_UserMsg,
+ "END SnarfLineTab linetab=%p size=%d\n",
+ linetab, size );
+
return n_lines_read;
}
@@ -1679,8 +1693,8 @@
unsigned i;
struct codeview_linetab2_block* lbh;
struct codeview_linetab2_file* fd;
- //const Bool debug = False;
+ Bool debug = di->trace_symtab;
Addr bias = BIAS_FOR_LINETAB2;
ULong n_line2s_read = 0;
@@ -1792,6 +1806,7 @@
char *modimage;
char *file;
+ Bool debug = di->trace_symtab;
Addr bias_for_fpo = BIAS_FOR_FPO;
ULong n_fpos_read = 0, n_syms_read = 0,
@@ -1952,6 +1967,8 @@
*/
modimage = pdb->read_file( pdb, symbols.gsym_file, &len_modimage );
if (modimage) {
+ if (debug)
+ VG_(umsg)("\n");
if (VG_(clo_verbosity) > 1)
VG_(message)(Vg_UserMsg, "Reading global symbols\n" );
DEBUG_SnarfCodeView( di, sectp_avma, modimage, 0, len_modimage );
@@ -1991,6 +2008,8 @@
total_size = pdb_get_file_size(pdb, file_nr);
if (symbol_size) {
+ if (debug)
+ VG_(umsg)("\n");
if (VG_(clo_verbosity) > 1)
VG_(message)(Vg_UserMsg, "Reading symbols for %s\n",
file_name );
@@ -2001,6 +2020,8 @@
}
if (lineno_size) {
+ if (debug)
+ VG_(umsg)("\n");
if (VG_(clo_verbosity) > 1)
VG_(message)(Vg_UserMsg, "Reading lines for %s\n", file_name );
n_lines_read
|
|
From: Tom H. <to...@co...> - 2010-01-25 16:41:13
|
On 25/01/10 16:20, Duncan Thomas wrote: > The Quadrics elan4 network card driver uses a large number of ioctls > when interacting with userspace code. Quadrics provide a patch to > valgrind 3.3 to allow valgrind to check the use of these ioctls. I've > started updating this patch to valgrind 3.5.0 and I'm trying to follow > the coding style so that it is mergable. It is currently unfinished, > though the ioctls implemented are correct. Two questions: Is trying to > get this into a mergable form useful? And if so, am I doing anything > obviously wrong? Is the driver in the standard kernel.org kernel? We generally only support system calls which are in the standard kernel, which may be why this never got merged before if it's for an out-of-tree driver. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Duncan T. <dun...@gm...> - 2010-01-25 16:20:32
|
Hi The Quadrics elan4 network card driver uses a large number of ioctls when interacting with userspace code. Quadrics provide a patch to valgrind 3.3 to allow valgrind to check the use of these ioctls. I've started updating this patch to valgrind 3.5.0 and I'm trying to follow the coding style so that it is mergable. It is currently unfinished, though the ioctls implemented are correct. Two questions: Is trying to get this into a mergable form useful? And if so, am I doing anything obviously wrong? The Quadrics drivers are now maintained by Vega Consulting, and support.hpc.vega.co.uk Thanks -- Duncan Thomas |
|
From: Gert W. <gw....@gm...> - 2010-01-23 01:21:41
|
> > Hi!, > > The tests for CMOV inspect the eflags value (by executing a gcc asm block). I was hoping there's already something pre-made, like with the other tests, now I have to brush up my knowledge in assembler ;) The patch seems okay but I can't test it... Haven't got the hardware for it > and gcc doesn't compile it in macosx. > Well, the carry flag was not set properly, and I will attach a(nother) unified patch to the bug report tomorrow. There were at least two people who came across the problem and have the hardware and probably watch the report. Best, Gert |
|
From: Tim T. <tte...@sw...> - 2010-01-22 16:28:09
|
So, valgrind does not exist for Solaris. I have x86 and am willing to contribute to the efforts, is there anything I need to know before I get started? In particular is there already an effort to get this working on some flavor? I realize that I am most likely getting into more than I want to at some rate but would like to work towards that goal. Thanks, Tim |
|
From: Filipe C. <fi...@gm...> - 2010-01-22 14:15:21
|
Hi!
On 1/21/10 22:20, Gert Wollny wrote:
> Hello!
>
> 2010/1/21 Filipe Cabecinhas <fi...@gm... <mailto:fi...@gm...>>
>
> The source code is fairly easy to understand (and if you have any
> doubts, there's always the mailing list ;-) ).
>
> Indeed, it was really quite easy to get going. I did implement LZCNT in
> terms of BSR, and it now passes some basic tests, so it's a point to
> start from.
> There's one thing though, how can I test that the flags are properly set?
Check memcheck/tests/x86/more_x86_fp.c
The tests for CMOV inspect the eflags value (by executing a gcc asm block).
> I guess creating an IR would be the next step. Where would I add the
> opcode enum? - just at the end of the big list?
>
> Okay, I've attached the patches against valgrind aand VEX and the test
> definition file. Any pointer how to improve this are very welcome.
>
I don't think you need to create a new IR instruction. I suppose using
BSR is okay (but hey... I'm no valgrind expert... You can always wait
for Julian's (or another person's) reply, if you want a definitive
answer ;-) )
But, in your code, where you have:
---------------------------------
+ if (haveF2orF3(pfx)) {
+ if (haveF3(pfx))
+ delta = dis_LZCNT ( vbi, pfx, sz, delta );
+ else
+ goto decode_failure;
+ }else
---------------------------------
But you're testing against F3 twice. I would change that to:
if (haveF3(pfx)) {
delta = dis_LZCNT ( vbi, pfx, sz, delta );
else if (haveF2(pfx))
goto decode_failure;
else ...
The patch seems okay but I can't test it... Haven't got the hardware for
it and gcc doesn't compile it in macosx.
Regards,
Filipe
|
|
From: Julian S. <js...@ac...> - 2010-01-22 13:22:11
|
On Friday 22 January 2010, Alexander Potapenko wrote: > As you can see, the stack trace contains only the top function, > whereas on x86 Linux the whole stack trace is printed. > Is it the desired behavior of Memcheck on ARM? Unwinding on ARM (or, more correctly, ARM-ELF as provided by Ubuntu 9.04) absolutely requires compiling with -g, since without that, the Dwarf3 unwind info is not present. This is different from the situation on AMD64-Linux, in which unwind info is always present regardless of the presence or absence of -g. Note that -g does not imply that -O0 is required. The guidelines for -O settings remain the same as for other platforms -- which is that -O is OK (and recommended), but -O2 and above are not. In short: "-g -O0" or "-g -O". J |
|
From: Alexander P. <gl...@go...> - 2010-01-22 12:59:55
|
Hi all,
I'm running the following C code under Valgrind on a ARMv7 CPU:
==========broken-stack.c============
#include <stdio.h>
void f4() {
int a;
if (a) {
printf("a==true\n");
} else {
printf("a==false\n");
}
}
void f3() { f4(); }
void f2() { f3(); }
void f1() { f2(); }
int main() {
f1();
return 0;
}
===============================
$ gcc broken-stack.c -o broken-stack
$ valgrind broken-stack
==4615== Memcheck, a memory error detector
==4615== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4615== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==4615== Command: /home/glider/src/arm-stack/broken-stack
==4615==
==4615== Conditional jump or move depends on uninitialised value(s)
==4615== at 0x83C8: f4 (in /home/glider/src/arm-stack/broken-stack)
==4615==
a==true
==4615==
==4615== HEAP SUMMARY:
...
As you can see, the stack trace contains only the top function,
whereas on x86 Linux the whole stack trace is printed.
Is it the desired behavior of Memcheck on ARM?
Thanks in advance,
Alexander Potapenko
Software Engineer
Google Moscow
|