[valgrind] [Bug 430321] drd/tests/bar_bad and drd/tests/bar_bad_xml are non-deterministic

2021-05-03 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=430321

Yi Fan Yu  changed:

   What|Removed |Added

 CC||yifan...@windriver.com

--- Comment #1 from Yi Fan Yu  ---
here is the diff file I collected for the test failure

```
--- bar_bad.stderr.exp  2018-03-09 12:34:56.0 +
+++ bar_bad.stderr.out  2021-04-23 21:34:56.65400 +
@@ -25,14 +25,11 @@


 destroy a barrier that has waiting threads
-Destruction of a barrier with active waiters: barrier 0x
+
+destroy a barrier that was never initialised
+Not a barrier
at 0x: pthread_barrier_destroy (drd_pthread_intercepts.c:?)
by 0x: main (bar_bad.c:?)
-barrier 0x was first observed at:
-   at 0x: pthread_barrier_init (drd_pthread_intercepts.c:?)
-   by 0x: main (bar_bad.c:?)


-destroy a barrier that was never initialised
-
-ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
```

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-04-20 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #13 from Yi Fan Yu  ---
https://sourceware.org/git/?p=valgrind.git;a=commit;h=4c8c4a9c3a92300e3e6500e5a278ca37514a1fdb

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-04-20 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

Yi Fan Yu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #12 from Yi Fan Yu  ---
thanks!

passes on yocto ptest

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-04-05 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #10 from Yi Fan Yu  ---
Created attachment 137357
  --> https://bugs.kde.org/attachment.cgi?id=137357&action=edit
proposed patch v2

basically to avoid printing the stacktrace with a handled signal.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-04-05 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #9 from Yi Fan Yu  ---
stderr.exp that would pass the test.
```


Process terminating with default action of signal 14 (SIGALRM)
   at 0x: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:?)
   by 0x: nanosleep (nanosleep.c:?)

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #7 from Yi Fan Yu  ---
maybe the root cause is just the stderr.exp being to sensitive...

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #6 from Yi Fan Yu  ---
(In reply to Bart Van Assche from comment #5)
> Reverting commit 719d23b7a9c3 ("drd/tests/swapcontext: Improve portability")
> is not an option. Valgrind source code must build and run on all supported
> operating systems. Not all supported operating systems support poll().

seems like Mac doesn't support poll, maybe select would be a better choice?
I tested the "proposed patch" and test passes.

any advice to solve this issue?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #4 from Yi Fan Yu  ---
I do know that the commit I reverted mentioned portability.
Do you know which platform has problems with timerfd?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #3 from Yi Fan Yu  ---
Created attachment 137186
  --> https://bugs.kde.org/attachment.cgi?id=137186&action=edit
proposed patch

revert commit 719d23b7a9c3b02411dee7d5d4d3744938bb768c

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #2 from Yi Fan Yu  ---
What is the purpose of nanosleep, can it be safely removed?

Is there a filter to allow both scenario (stopped in f and stopped in
nanosleep) to be correct?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 434775] drd/tests/swapcontext.c doesn't build with musl

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=434775

Yi Fan Yu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #5 from Yi Fan Yu  ---
build with musl is successful.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

--- Comment #1 from Yi Fan Yu  ---
If i remove the nanosleep statement, inside of `f`

the original bug report 432381 's error message appears

drd: drd_main.c:378 (drd_stop_using_mem): Assertion 'a1 <= a2' failed

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 435160] New: drd/tests/swapcontext.c: threads are interrupted in nanosleep

2021-03-30 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=435160

Bug ID: 435160
   Summary: drd/tests/swapcontext.c: threads are interrupted in
nanosleep
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: drd
  Assignee: bart.vanassche+...@gmail.com
  Reporter: yifan...@windriver.com
  Target Milestone: ---

SUMMARY
on yocto/oe-core qemux86-64 glibc 3.17.0 release:
swapcontext.c fails because the threads were killed inside of nanosleep



STEPS TO REPRODUCE


OBSERVED RESULT

``` runqemu kvm
valgrind --tool=drd --read-var-info=yes --check-stack-var=yes
--show-confl-seg=no --num-callers=2 ./swapcontext
==277== drd, a thread error detector
==277== Copyright (C) 2006-2020, and GNU GPL'd, by Bart Van Assche.
==277== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==277== Command: ./swapcontext
==277==
==277==
==277== Process terminating with default action of signal 14 (SIGALRM)
==277==at 0x36C74C3943: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:43)
==277==by 0x36C74C8726: nanosleep (nanosleep.c:25)
==277==
==277== For lists of detected and suppressed errors, rerun with: -s
==277== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 26 from 2)
Alarm clock
```

EXPECTED RESULT

i think the test should pass because it generated 0 error.
the nanosleep is called inside of f

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 434775] drd/tests/swapcontext.c doesn't build with musl

2021-03-26 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=434775

--- Comment #3 from Yi Fan Yu  ---
I tried applying that patch to oe-core build and it still fails with this:

So musl does provide  as a header, but you cannot link to any of
the *context calls. The error is a linker failure.

```
/ala-lpggp31/yyu1/oe-core/build/tmp-musl/work/core2-64-oe-linux-musl/valgrind/3.17.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux-musl/../../libexec/x86_64-oe-linux-musl/gcc/x8:
|
/usr/src/debug/valgrind/3.17.0-r0/valgrind-3.17.0/memcheck/tests/linux/stack_changes.c:23:
undefined reference to `setcontext'
|
/ala-lpggp31/yyu1/oe-core/build/tmp-musl/work/core2-64-oe-linux-musl/valgrind/3.17.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux-musl/../../libexec/x86_64-oe-linux-musl/gcc/x8:
|
/usr/src/debug/valgrind/3.17.0-r0/valgrind-3.17.0/memcheck/tests/linux/stack_changes.c:31:
undefined reference to `getcontext'
|
/ala-lpggp31/yyu1/oe-core/build/tmp-musl/work/core2-64-oe-linux-musl/valgrind/3.17.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux-musl/../../libexec/x86_64-oe-linux-musl/gcc/x8:
|
/usr/src/debug/valgrind/3.17.0-r0/valgrind-3.17.0/memcheck/tests/linux/stack_changes.c:60:
undefined reference to `makecontext'
|
/ala-lpggp31/yyu1/oe-core/build/tmp-musl/work/core2-64-oe-linux-musl/valgrind/3.17.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux-musl/../../libexec/x86_64-oe-linux-musl/gcc/x8'
|
/ala-lpggp31/yyu1/oe-core/build/tmp-musl/work/core2-64-oe-linux-musl/valgrind/3.17.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux-musl/../../libexec/x86_64-oe-linux-musl/gcc/x8'
| collect2: error: ld returned 1 exit status

```

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 400162] Patch: Guard against __GLIBC_PREREQ for musl libc

2021-03-22 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=400162

Yi Fan Yu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #9 from Yi Fan Yu  ---
reopening this bug too.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 400162] Patch: Guard against __GLIBC_PREREQ for musl libc

2021-03-22 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=400162

Yi Fan Yu  changed:

   What|Removed |Added

 Attachment #115830|0   |1
is obsolete||
 Attachment #115831|0   |1
is obsolete||
 CC||yifan...@windriver.com

--- Comment #8 from Yi Fan Yu  ---
Created attachment 136948
  --> https://bugs.kde.org/attachment.cgi?id=136948&action=edit
refresh the previous patches by randy

the issue wasn't solved by the referenced commit

the patch was also updated.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 434775] drd/tests/swapcontext.c doesn't build with musl

2021-03-22 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=434775

--- Comment #1 from Yi Fan Yu  ---
Created attachment 136947
  --> https://bugs.kde.org/attachment.cgi?id=136947&action=edit
proposed patch (yocto/oe-core fix)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 434775] New: drd/tests/swapcontext.c doesn't build with musl

2021-03-22 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=434775

Bug ID: 434775
   Summary: drd/tests/swapcontext.c doesn't build with musl
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: drd
  Assignee: bart.vanassche+...@gmail.com
  Reporter: yifan...@windriver.com
  Target Milestone: ---

SUMMARY
drd/tests/swapcontext.c
calls makecontext and other context related API that are not supported by musl

also applies to
memcheck/tests/linux/stack_changes.c

STEPS TO REPRODUCE
1. make regtest with musl
2. 
3. 

OBSERVED RESULT

swapcontext.c will fail to build

EXPECTED RESULT

swapcontext.c builds/is skipped

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 432870] gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64

2021-03-08 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=432870

--- Comment #10 from Yi Fan Yu  ---
tested on qemuarm64 and qemux86-64 with glibc2.33

thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 432870] gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64

2021-02-17 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=432870

--- Comment #4 from Yi Fan Yu  ---
here are my findings i summarized to the yocto bugboard.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14223


## what changed in this patch to cause it to fail?

timeout argument the user passes no longer makes its way to the syscall.
Glibc copies it over and converts into a different format to call a different
syscall `pselect`

the failing test tries to modify said timeout argument to make the syscall end
faster. Unfortunately doesn't work.

## what about actually fixing this bug though?

talking to valgrind about the purpose of nlcontrolc test
- can we use a different syscall to sleep for a duration?
- what is the exact purpose if this test

## other questions that arise
Is glibc setting a new standard? what is the expected libc implementation of
select? 
Grey area... 

according to `man select`
```
On Linux, select() modifies timeout to reflect the amount of time not slept;
most other implementations do not do this. (POSIX.1-2001 permits either
behavior.) 
```
Did glibc violate the "linux standard"?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 432870] gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64

2021-02-17 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=432870

--- Comment #3 from Yi Fan Yu  ---
Here is a working call to sleepers *without* the select update patch in 2.33
it used to directly passes timeout to the underlying syscall. 
With 2.33, it doesn't anymore


```
root@qemux86-64:/usr/lib/valgrind/ptest/gdbserver_tests# valgrind
--trace-syscalls=yes  ./sleepers 10 10 10 BSBSBSBS 2>&1
| grep select
SYSCALL[6021,2](23) sys_select ( 0, 0x0, 0x0, 0x0, 0x4041b0 ) --> [async] ...
SYSCALL[6021,3](23) sys_select ( 0, 0x0, 0x0, 0x0, 0x4041c0 ) --> [async] ...
SYSCALL[6021,1](23) sys_select ( 0, 0x0, 0x0, 0x0, 0x4041a0 ) --> [async] ...
SYSCALL[6021,4](23) sys_select ( 0, 0x0, 0x0, 0x0, 0x4041d0 ) --> [async] ...
```

It used to pass timeout directly to `select`, now it calls `select6`
```
-__select (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
- struct timeval *timeout)
+__select64 (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
+   struct __timeval64 *timeout)
 {
-#ifdef __NR_select
-  return SYSCALL_CANCEL (select, nfds, readfds, writefds, exceptfds,
-timeout);
```

here is how it calls it now 
```
+  r = SYSCALL_CANCEL (pselect6, nfds, readfds, writefds, exceptfds, pts32,
+ NULL);
```

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 432870] gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64

2021-02-16 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=432870

--- Comment #1 from Yi Fan Yu  ---
this commit for glibc (present in 2.33 but not 2.32) is causing this test to
fail
when i rebuilt glibc with a patch to revert this commit, the test passes.

```
commit 2433d39b69743f100f972e7886f91a2e21795ef0
Author: Adhemerval Zanella 
Date:   Mon Jul 6 16:06:51 2020 -0300

linux: Add time64 select support

```

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 432870] New: gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64

2021-02-12 Thread Yi Fan Yu
https://bugs.kde.org/show_bug.cgi?id=432870

Bug ID: 432870
   Summary: gdbserver_tests:nlcontrolc hangs with newest glibc2.33
x86-64
   Product: valgrind
   Version: unspecified
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: yifan...@windriver.com
  Target Milestone: ---

SUMMARY

nlcontrolc hangs, first seen on the `yocto poky` master build after 
updating to glibc2.33. Confirmed with a archlinux build for x86-64

seen both on valgrind master and 3.16.1 release

STEPS TO REPRODUCE
get most recent archlinux packages and valgrind source repo
1. ./configure  --without-mpicc --enable-tls
2. make 
3. make regtest

OBSERVED RESULT

nlcontrolc hangs for more than 15 min

EXPECTED RESULT

test passes under a minute

SOFTWARE/OS VERSIONS
seen on most recent archlinux and yocto poky build

ADDITIONAL INFORMATION
might be related to https://bugs.kde.org/show_bug.cgi?id=338633
difference is glibc, gdb version and x86-64

-- 
You are receiving this mail because:
You are watching all bug changes.