paulfloyd / freebsd_valgrind

Git repo used to Upstream the FreeBSD Port of Valgrind
GNU General Public License v2.0
15 stars 4 forks source link

drd/tests/atomic_var is failing [FreeBSD 13.0 and 13.1 amd64] #169

Closed paulfloyd closed 2 years ago

paulfloyd commented 2 years ago

Conflicting load by thread x at 0x........ size 4 at 0x........: thread_func_2 (atomic_var.c:?) by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?) -Location 0x........ is 0 bytes inside global var "s_y" -declared at atomic_var.c:35 +Location 0x........ is 0 bytes inside g_dummy[512], +a global variable declared at atomic_var.c:34

Looks wrong.

paulfloyd commented 2 years ago

Is this any better when correctly reading PT_LOADs? No.

paulfloyd commented 2 years ago

Without filtering

==1798== Thread 3:
==1798== Conflicting load by thread 3 at 0x002040c0 size 4
==1798==    at 0x201B83: thread_func_2 (atomic_var.c:48)
==1798==    by 0x4860F98: vgDrd_thread_wrapper (drd_pthread_intercepts.c:491)
==1798== Location 0x2040c0 is 0 bytes inside g_dummy[512],
==1798== a global variable declared at atomic_var.c:34

and also

raw symbol [  15]: LOC OBJ : svma 0x00002040c0, sz    4  s_y
    rec(d) [  15]:            val 0x00002040c0, sz    4  s_y
raw symbol [  43]: GLO OBJ : svma 0x0000203ec0, sz  512  g_dummy
    rec(d) [  43]:            val 0x0000203ec0, sz  512  g_dummy

OK so the problem is that this iterates over the variables, and then it is finding g_dummy before s_y

In static Bool data_address_is_in_var ( /OUT/PtrdiffT* offset,

Bool show = True;

VVVV: data_address_0x2040c0_is_in_var: g_dummy :: char[513]

How did that get a size of 513?

trace-symtab again

<833> addVar: level 0: g_dummy :: char[513]
  Loc=GX(final){[0x0,0xffffffffffffffff]=03c03e200000000000}
  FrB=none
  declared at: 19 atomic_var.c:34
  ACQUIRE for range(s) [0x0,0xffffffffffffffff] 

and

diff --git a/coregrind/m_debuginfo/readdwarf3.c b/coregrind/m_debuginfo/readdwarf3.c
index 96bd21f7f..b1a709e6a 100644
--- a/coregrind/m_debuginfo/readdwarf3.c
+++ b/coregrind/m_debuginfo/readdwarf3.c
@@ -4571,7 +4571,7 @@ static void parse_type_DIE ( /*MOD*/XArray* /* of TyEnt */ tyents,
          boundE.Te.Bound.knownL = True;
          boundE.Te.Bound.knownU = True;
          boundE.Te.Bound.boundL = lower;
-         boundE.Te.Bound.boundU = lower + count;
+         boundE.Te.Bound.boundU = lower + count - 1;
       } else {
          /* FIXME: handle more cases */
          goto_bad_DIE;

That looks like the culrpit, and out by one error.

paulfloyd commented 2 years ago

commit 498b5c4286ec631bec43b8c359e3ff00c00b90e7 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd pjfloyd@wanadoo.fr Date: Tue Jul 5 12:53:34 2022 +0200

Fix reading dwarf info for arrays with lower bound and count

There was an out-by-one error, the upper bound was being set to
count whereas it should be count - 1.

This was causing drd/tests/atomic_var to fail because the g_dummy
array seemed to overlap the following s_y variable.

This seems only to have been caused by clang, not GCC, which
presumably supplies lower and upper bound rather than lower
bound and count.