[valgrind] [Bug 371396] helgrind and drd pth_cond_destroy_busy testcase hang with new glibc cond var implementation

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371396

--- Comment #1 from Mark Wielaard  ---
A workaround (skip the test if a newer glibc is detected) has been checked in
as valgrind r16097.

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

[valgrind] [Bug 371396] New: helgrind and drd pth_cond_destroy_busy testcase hang with new glibc cond var implementation

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371396

Bug ID: 371396
   Summary: helgrind and drd pth_cond_destroy_busy testcase hang
with new glibc cond var implementation
   Product: valgrind
   Version: 3.12 SVN
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: helgrind
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

A new conditional variable implementation being tested in fedora rawhide atm
will hang the helgrind and drd pth_cond_destroy_busy tests. This is because
they test a condition that triggers undefined behaviour. "Attempting to destroy
a  condition variable upon which other threads are currently blocked results in
undefined behavior." In the new implementation this causes the thread calling
pthread_cond_destroy will just hang in this situation.

There are a couple of ways we could work around this.
- Add some timer thread that kills the whole test after some time.
  This is what we did for the bar_bad tests. It causes some non-determinism,
extra thread events and you
  have to handle different code paths/warnings/error conditions.
- Add a generic timer/watchdog to vgregtest that kills hanging tests
  This would be nice in general to make sure make regtest does at least finish.
- Skip the test if a newer glibc is detected. This is what I am doing for now.
- Try to call pthread_cond_broadcast in HG_PTHREAD_COND_DESTROY_PRE when we
detect that pthread_cond_destroy is called on a variable that other threads are
waiting on. That should in theory wake them up making the pthread_cond_destroy
defined again.
- Just not call pthread_cond_destroy if we detect that it might hang.

The new implementation is:
https://sourceware.org/ml/libc-alpha/2016-06/msg00554.html
It is currently only applied in fedora rawhide glibc 2.24.90, but is expected
to eventually hit glibc master.

Reproducible: Always

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

[valgrind] [Bug 358213] helgrind/drd bar_bad testcase hangs or crashes with new glibc pthread barrier implementation

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358213

Mark Wielaard  changed:

   What|Removed |Added

Summary|helgrind/drd bar_bad|helgrind/drd bar_bad
   |testcase hangs with new |testcase hangs or crashes
   |glibc pthread barrier   |with new glibc pthread
   |implementation  |barrier implementation

--- Comment #8 from Mark Wielaard  ---
(In reply to Julian Seward from comment #7)
> Should we close this now?

No, I don't think it should. There is now a workaround in place that makes sure
the test doesn't hang. But now that test (non-deterministically) fails or even
crashes valgrind itself.

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

[valgrind] [Bug 370265] ISA 3.0 HW cap stuff needs updating

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370265

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #6 from Mark Wielaard  ---
(In reply to Carl Love from comment #5)
> Valgrind commit 16037.
> 
> Mark please take a look at the changes upstream and let me know if it all
> looks OK to you.  Thanks for catching this.

Looks OK to me and fixes the issue. Thanks.

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

[valgrind] [Bug 370265] ISA 3.0 HW cap stuff needs updating

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370265

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #3 from Mark Wielaard  ---
This updates the min_power_isa check to accept 3.00 instead of 3.0, but the
vbit test still uses 3.0 causing test failures in
memcheck/tests/vbit-test/vbit-test:

ERROR: invalid ISA version.  Valid versions numbers are:
   2.05, 2.06, 2.07, 3.00

I tested the following fix on gcc112.fsffrance.org a ppc64le (power8) setup:

diff --git a/memcheck/tests/vbit-test/irops.c
b/memcheck/tests/vbit-test/irops.c
index 67e6e47..5b1106a 100644
--- a/memcheck/tests/vbit-test/irops.c
+++ b/memcheck/tests/vbit-test/irops.c
@@ -1287,8 +1287,8 @@ get_irop(IROp op)
  case Iop_MulI128by10Carry:
  case Iop_MulI128by10E:
  case Iop_MulI128by10ECarry: {
-/* IROps require a processor that supports ISA 2.07 (Power 8) or
newer */
-rc = system(MIN_POWER_ISA " 3.0 ");
+/* IROps require a processor that supports ISA 3.00 (Power 9) or
newer */
+rc = system(MIN_POWER_ISA " 3.00 ");
 rc /= 256;
 /* MIN_POWER_ISA returns 0 if underlying HW supports the
  * specified ISA or newer. Returns 1 if the HW does not support
diff --git a/tests/min_power_isa.c b/tests/min_power_isa.c
index e4035ce..37d89f5 100644
--- a/tests/min_power_isa.c
+++ b/tests/min_power_isa.c
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
   return !(isa_level >= 8);

} else {
-  fprintf(stderr, "ERROR: invalid ISA version.  Valid versions numbers
are:\n" );
+  fprintf(stderr, "ERROR: invalid ISA version '%s'.  Valid versions
numbers are:\n", min_isa );
   fprintf(stderr, "   2.05, 2.06, 2.07, 3.00\n" );
   exit(2);
}

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

[valgrind] [Bug 369209] valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Mark Wielaard  ---
valgrind svn r15989

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

[valgrind] [Bug 369356] pre_mem_read_sockaddr syscall wrapper can crash with bad sockaddr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369356

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[valgrind] [Bug 369356] pre_mem_read_sockaddr syscall wrapper can crash with bad sockaddr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369356

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15990

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

[valgrind] [Bug 369359] msghdr_foreachfield can crash when handling bad iovec

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369359

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15991

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

[valgrind] [Bug 369360] Bad sigprocmask old or new sets can crash valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369360

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15992

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

[valgrind] [Bug 369361] vmsplice syscall wrapper crashes on bad iovec

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369361

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15993

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

[valgrind] [Bug 369362] Bad sigaction arguments crash valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369362

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15994

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

[valgrind] [Bug 369383] x86 sys_modify_ldt wrapper crashes on bad ptr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369383

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15995

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

[valgrind] [Bug 369402] Bad set/get_thread_area pointer crashes valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369402

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15996

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

[valgrind] [Bug 369441] bad lvec argument crashes process_vm_readv/writev syscall wrappers

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369441

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15997

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

[valgrind] [Bug 369446] valgrind crashes on unknown fcntl command

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369446

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Mark Wielaard  ---
valgrind svn r15998

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

[valgrind] [Bug 369209] valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

--- Comment #9 from Mark Wielaard  ---
(In reply to Ivo Raisr from comment #8)
> the new test case works ok (I am able to simulate the problem on Solaris)
> with 'make one component inaccessible'.

Thanks for testing. Lets go with this then.

> Please include "string[s].h" for proper strlen declaration.

Added.

> My apologies it took so long to verify it. I'm a bit overwhelmed these
> days...

No need to apologize. We are all busy all the time :)

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #30 from Mark Wielaard  ---
(In reply to Carl Love from comment #29)
> Please review the patch and let me know if you see any issues.  If everyone
> approves the patch and the ISA 3.0 Big endian test passes, I will commit the
> fix.  The fix will need to get staged for the upcoming Valgrind release.

Looks good to me and it passes the testsuite on my setup (power8 both ppc64 and
ppc64le).

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

[valgrind] [Bug 369446] valgrind crashes on unknown fcntl command

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369446

--- Comment #1 from Mark Wielaard  ---
Created attachment 101322
  --> https://bugs.kde.org/attachment.cgi?id=101322=edit
Don't crash, but warn and return EINVAL on unknown fcntl command.

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

[valgrind] [Bug 369446] New: valgrind crashes on unknown fcntl command

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369446

Bug ID: 369446
   Summary: valgrind crashes on unknown fcntl command
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

When encountering an unknown fcntl command valgrind crashes with an assertion
message: valgrind: m_syswrap/syswrap-linux.c:5490
(vgSysWrap_linux_sys_fcntl_before): Assertion 'Unimplemented functionality'
failed.

Valgrind should just warn the user the fcntl command is unimplemented and
return EINVAL like the kernel would.

LTP testcases/kernel/syscalls/fcntl/fcntl13

Reproducible: Always

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

[valgrind] [Bug 369441] New: bad lvec argument crashes process_vm_readv/writev syscall wrappers

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369441

Bug ID: 369441
   Summary: bad lvec argument crashes process_vm_readv/writev
syscall wrappers
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/cma/process_vm01 crashes valgrind:

==3940== Syscall param process_vm_readv(lvec) points to unaddressable byte(s)
==3940==at 0x4129977: syscall (in /usr/lib/libc-2.23.so)
==3940==by 0x804A414: test_process_vm_readv (process_vm.h:42)
==3940==by 0x804A414: cma_test_params_read (process_vm01.c:137)
==3940==by 0x8049E33: cma_test_iov_invalid (process_vm01.c:294)
==3940==by 0x8049E33: cma_test_errnos (process_vm01.c:410)
==3940==by 0x8049E33: main (process_vm01.c:91)
==3940==  Address 0x is not stack'd, malloc'd or (recently) free'd
==3940== 
--3940-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exit
ing
--3940-- si_code=1;  Faulting address: 0x3;  sp: 0x628dde4c

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==3940==at 0x380A3E79: vgSysWrap_linux_sys_process_vm_readv_before
(syswrap-linux.c:5012)

==3961== Syscall param process_vm_writev(lvec) points to unaddressable byte(s)
==3961==at 0x4129977: syscall (in /usr/lib/libc-2.23.so)
==3961==by 0x804A3C4: test_process_vm_writev (process_vm.h:55)
==3961==by 0x804A3C4: cma_test_params_write (process_vm01.c:145)
==3961==by 0x8049E33: cma_test_iov_invalid (process_vm01.c:294)
==3961==by 0x8049E33: cma_test_errnos (process_vm01.c:410)
==3961==by 0x8049E33: main (process_vm01.c:91)
==3961==  Address 0x is not stack'd, malloc'd or (recently) free'd
==3961== 
--3961-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exit
ing
--3961-- si_code=1;  Faulting address: 0x3;  sp: 0x629a8e4c

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==3961==at 0x380A40F9: vgSysWrap_linux_sys_process_vm_writev_before
(syswrap-linux.c:5050)


Reproducible: Always

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

[valgrind] [Bug 369441] bad lvec argument crashes process_vm_readv/writev syscall wrappers

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369441

--- Comment #1 from Mark Wielaard  ---
Created attachment 101321
  --> https://bugs.kde.org/attachment.cgi?id=101321=edit
Don't check bad iovec array in process_vm_readv/writev.

The TODO comment already said what to do.

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

[valgrind] [Bug 369409] null pointer dereference in vgPlain_do_syscall

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369409

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #1 from Mark Wielaard  ---
The description and second backtrace don't match the illegal instruction
message you are seeing.
Given this is with ubuntu I suspect this is:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1501545
Which was fixed upstream with:
https://bugs.kde.org/show_bug.cgi?id=353370

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

[valgrind] [Bug 369209] valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

--- Comment #7 from Mark Wielaard  ---
Created attachment 101309
  --> https://bugs.kde.org/attachment.cgi?id=101309=edit
new nocwd testcase

How about this variant of the test.
It tries a couple of things to make sure getcwd will fail.
Create a path that is > PATH_MAX, make one component inaccessible and remove
the current dir.
Although all these things can be done on a linux system there is no error
checking in case some different kernel doesn't allow any of these things.

The testcase should fail (loop indefinitely) with current valgrind, but succeed
with the patch.
(You can check by running with ./vg-in-place -d --trace-children=yes
none/test/nocwd and searching for "Getting the working directory at startup" -
with the patch it will probably say "main ... ".)

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

[valgrind] [Bug 369402] Bad set/get_thread_area pointer crashes valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369402

--- Comment #1 from Mark Wielaard  ---
Created attachment 101307
  --> https://bugs.kde.org/attachment.cgi?id=101307=edit
linux-x86 check get/set_thread_area pointer before use.

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

[valgrind] [Bug 369402] New: Bad set/get_thread_area pointer crashes valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369402

Bug ID: 369402
   Summary: Bad set/get_thread_area pointer crashes valgrind
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/set_thread_area/set_thread_area01 crashes
valgrind:

==5690== Syscall param set_thread_area(u_info) points to unaddressable byte(s)
==5690==at 0x4129977: syscall (in /usr/lib/libc-2.23.so)
==5690==by 0x8049A7B: main (set_thread_area01.c:77)
==5690==  Address 0xfff7 is not stack'd, malloc'd or (recently) free'd
==5690== 
--5690-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--5690-- si_code=1;  Faulting address: 0xFFF7;  sp: 0x62a5fe30

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==5690==at 0x380B5F3C: sys_set_thread_area (syswrap-x86-linux.c:641)


Reproducible: Always

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

[valgrind] [Bug 369383] x86 sys_modify_ldt wrapper crashes on bad ptr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369383

--- Comment #1 from Mark Wielaard  ---
Created attachment 101298
  --> https://bugs.kde.org/attachment.cgi?id=101298=edit
Fix crash in sys_modify_ldt wrapper on bad ptr.

Make sure ptr is safe_to_deref if not NULL.
Also fixup some corner case error return codes.
We have to do that ourselves since we never actually call into the kernel.

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

[valgrind] [Bug 369383] New: x86 sys_modify_ldt wrapper crashes on bad ptr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369383

Bug ID: 369383
   Summary: x86 sys_modify_ldt wrapper crashes on bad ptr
   Product: valgrind
   Version: 3.12 SVN
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/modify_ldt/modify_ldt01:

==30317== Syscall param modify_ldt(ptr) points to unaddressable byte(s)
==30317==at 0x412FFF9: modify_ldt (in /usr/lib/libc-2.23.so)
==30317==by 0x8049BCD: main (modify_ldt01.c:188)
==30317==  Address 0x805efff is 4095 bytes after the brk data segment limit
0x805e000
==30317== 
--30317-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--30317-- si_code=1;  Faulting address: 0x805F000;  sp: 0x62a5ce34

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==30317==at 0x380B70B7: read_ldt (syswrap-x86-linux.c:541)
==30317==by 0x380B70B7: sys_modify_ldt (syswrap-x86-linux.c:603)
==30317==by 0x380B70B7: vgSysWrap_x86_linux_sys_modify_ldt_before
(syswrap-x86-linux.c:1037)


Reproducible: Always

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #21 from Mark Wielaard  ---
Created attachment 101296
  --> https://bugs.kde.org/attachment.cgi?id=101296=edit
Patch to wrap _BCDstring128_helper address in fnptr_to_fnentry

After some debugging Julian suggested this fix. It makes the original testcase
PASS. But Julian claims this is impossible :)

There are other calls that arguably should use fnptr_to_fnentry to get/call the
actual function entry (instead the function descriptor). So either or testcases
are not stress testing things enough, or we still don't fully understand what
is going on.

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #20 from Mark Wielaard  ---
Created attachment 101295
  --> https://bugs.kde.org/attachment.cgi?id=101295=edit
Trace for smaller badness2 reproducer

Trace output for a smaller reproducer:

$ cat badness2.c

#include 

static vector unsigned long long vec_out, vec_inA, vec_inB;

int main ( void )
{
   memset(_inA, 0x12, sizeof(vec_inA));
   memset(_inB, 0x34, sizeof(vec_inB));
   memset(_out, 0x56, sizeof(vec_out));
   __asm__ __volatile__ ("bcdadd. %0, %1, %2, 0"
 : "=v" (vec_out): "v" (vec_inA),"v" (vec_inB));
   return 0;
}

$ gcc -Winline -Wall -g -O -mregnames -maltivec -m64 -o badness2 badness2.c
-mvsx -Wa,-mvsx -mcpu=power8 -Wa,-mpower8

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

[valgrind] [Bug 369362] Bad sigaction arguments crash valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369362

--- Comment #1 from Mark Wielaard  ---
Created attachment 101290
  --> https://bugs.kde.org/attachment.cgi?id=101290=edit
Fix crash in linux [rt_]sigaction wrapper with bad old/new sigaction handler.

Since we try to modify the old/new sigaction handler before passing it
to the kernel we must make sure that (if they aren't NULL) it is safe
to use. If not we should bail out early with EFAULT.

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

[valgrind] [Bug 369362] New: Bad sigaction arguments crash valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369362

Bug ID: 369362
   Summary: Bad sigaction arguments crash valgrind
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/rt_sigaction/rt_sigaction02 crashes valgrind:

--29814-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exi
ting
--29814-- si_code=1;  Faulting address: 0xA;  sp: 0x80327ad70

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==29814==at 0x380AF328: vgSysWrap_linux_sys_rt_sigaction_before
(syswrap-lin
ux.c:3376)
==29814==by 0x38092CDF: vgPlain_client_syscall (syswrap-main.c:1906)
==29814==by 0x3808F8B2: handle_syscall (scheduler.c:1118)
==29814==by 0x38090E76: vgPlain_scheduler (scheduler.c:1435)
==29814==by 0x380A027A: thread_wrapper (syswrap-linux.c:103)
==29814==by 0x380A027A: run_a_thread_NORETURN (syswrap-linux.c:156)


Reproducible: Always

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

[valgrind] [Bug 369361] vmsplice syscall wrapper crashes on bad iovec

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369361

--- Comment #1 from Mark Wielaard  ---
Created attachment 101289
  --> https://bugs.kde.org/attachment.cgi?id=101289=edit
Fix crash in vmsplice linux kernel wrapper when iovec is bad

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

[valgrind] [Bug 369361] New: vmsplice syscall wrapper crashes on bad iovec

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369361

Bug ID: 369361
   Summary: vmsplice syscall wrapper crashes on bad iovec
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/vmsplice/vmsplice02 crashes valgrind:
==32085== Syscall param vmsplice(iov) points to unaddressable byte(s)
==32085==at 0x4F2C173: __vmsplice_nocancel (syscall-template.S:81)
==32085==by 0x4028BC: vmsplice_verify (vmsplice02.c:119)
==32085==by 0x4028BC: main (vmsplice02.c:83)
==32085==  Address 0x615000 is not stack'd, malloc'd or (recently) free'd
==32085== 
==32085== Syscall param vmsplice(iov[...]) points to unaddressable byte(s)
==32085==at 0x4F2C173: __vmsplice_nocancel (syscall-template.S:81)
==32085==by 0x4028BC: vmsplice_verify (vmsplice02.c:119)
==32085==by 0x4028BC: main (vmsplice02.c:83)
==32085==  Address 0x80007 is not stack'd, malloc'd or (recently) free'd
==32085== 
--32085-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--32085-- si_code=1;  Faulting address: 0x615000;  sp: 0x80327ad70

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==32085==at 0x380B71DC: vgSysWrap_linux_sys_vmsplice_before
(syswrap-linux.c:5301)
==32085==by 0x38092CDF: vgPlain_client_syscall (syswrap-main.c:1906)
==32085==by 0x3808F8B2: handle_syscall (scheduler.c:1118)
==32085==by 0x38090E76: vgPlain_scheduler (scheduler.c:1435)
==32085==by 0x380A027A: thread_wrapper (syswrap-linux.c:103)
==32085==by 0x380A027A: run_a_thread_NORETURN (syswrap-linux.c:156)



Reproducible: Always

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

[valgrind] [Bug 369360] Bad sigprocmask old or new sets can crash valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369360

--- Comment #1 from Mark Wielaard  ---
Created attachment 101288
  --> https://bugs.kde.org/attachment.cgi?id=101288=edit
Fix crash when old/new sigprocmask isn't safe to dereference

Since we want to use the set and oldset for bookkeeping we also want
to make sure they are addressable otherwise, like the kernel, we EFAULT.
Also use EINVAL instead of EMFILE as failure when sigset size is wrong.

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

[valgrind] [Bug 369360] New: Bad sigprocmask old or new sets can crash valgrind

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369360

Bug ID: 369360
   Summary: Bad sigprocmask old or new sets can crash valgrind
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/rt_sigprocmask/rt_sigprocmask02 crashes valgrind:

==29826== Syscall param rt_sigprocmask(oldset) points to unaddressable byte(s)
==29826==at 0x4F25BF9: syscall (syscall.S:38)
==29826==by 0x402712: main (rt_sigprocmask02.c:107)
==29826==  Address 0x is not stack'd, malloc'd or (recently)
free'd
==29826== 
--29826-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--29826-- si_code=1;  Faulting address: 0x;  sp: 0x80327ad40

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==29826==at 0x380534BD: do_setmask (m_signals.c:1352)
==29826==by 0x380534BD: vgPlain_do_sys_sigprocmask (m_signals.c:1375)
==29826==by 0x380AF5F1: vgSysWrap_linux_sys_rt_sigprocmask_before
(syswrap-linux.c:3414)
==29826==by 0x38092CDF: vgPlain_client_syscall (syswrap-main.c:1906)
==29826==by 0x3808F8B2: handle_syscall (scheduler.c:1118)
==29826==by 0x38090E76: vgPlain_scheduler (scheduler.c:1435)
==29826==by 0x380A027A: thread_wrapper (syswrap-linux.c:103)
==29826==by 0x380A027A: run_a_thread_NORETURN (syswrap-linux.c:156)


Reproducible: Always

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

[valgrind] [Bug 369359] msghdr_foreachfield can crash when handling bad iovec

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369359

--- Comment #1 from Mark Wielaard  ---
Created attachment 101287
  --> https://bugs.kde.org/attachment.cgi?id=101287=edit
Fix crash in msghdr_foreachfield when iov_len isn't safe to dereference.

Also stop checking when max length of bytes have been reached.

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

[valgrind] [Bug 369359] New: msghdr_foreachfield can crash when handling bad iovec

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369359

Bug ID: 369359
   Summary: msghdr_foreachfield can crash when handling bad iovec
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/recvmsg/recvmsg01 crashes valgrind:

==29561== Syscall param recvmsg(msg.msg_iov[134]) points to unaddressable
byte(s)
==29561==at 0x4F2C690: __recvmsg_nocancel (syscall-template.S:81)
==29561==by 0x402B0E: main (recvmsg01.c:224)
==29561==  Address 0x6b636f7364750001 is not stack'd, malloc'd or (recently)
free'd
==29561== 
--29561-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--29561-- si_code=1;  Faulting address: 0x618008;  sp: 0x80327ad40

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==29561==at 0x38093BD5: msghdr_foreachfield (syswrap-generic.c:1063)
==29561==by 0x38092CDF: vgPlain_client_syscall (syswrap-main.c:1906)
==29561==by 0x3808F8B2: handle_syscall (scheduler.c:1118)
==29561==by 0x38090E76: vgPlain_scheduler (scheduler.c:1435)
==29561==by 0x380A027A: thread_wrapper (syswrap-linux.c:103)
==29561==by 0x380A027A: run_a_thread_NORETURN (syswrap-linux.c:156)


Reproducible: Always

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

[valgrind] [Bug 369356] pre_mem_read_sockaddr syscall wrapper can crash with bad sockaddr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369356

--- Comment #1 from Mark Wielaard  ---
Created attachment 101286
  --> https://bugs.kde.org/attachment.cgi?id=101286=edit
Fix pre_mem_read_sockaddr crash on invalid syscall arguments

Don't do any more checks if it isn't safe to inspect the address family.
Likewise, don't check sun_path if the string address isn't safe.

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

[valgrind] [Bug 369356] New: pre_mem_read_sockaddr syscall wrapper can crash with bad sockaddr

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369356

Bug ID: 369356
   Summary: pre_mem_read_sockaddr syscall wrapper can crash with
bad sockaddr
   Product: valgrind
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

LTP testcases/kernel/syscalls/bind/bind01 crashes valgrind:

==19407==at 0x4F2C427: bind (syscall-template.S:81)
==19407==by 0x402803: main (bind01.c:120)
==19407==  Address 0x is not stack'd, malloc'd or (recently)
free'd
==19407== 
--19407-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--19407-- si_code=1;  Faulting address: 0x;  sp: 0x802ea9d70

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==19407==at 0x38094231: pre_mem_read_sockaddr.part.12
(syswrap-generic.c:1131)
==19407==by 0x38092CDF: vgPlain_client_syscall (syswrap-main.c:1906)
==19407==by 0x3808F8B2: handle_syscall (scheduler.c:1118)
==19407==by 0x38090E76: vgPlain_scheduler (scheduler.c:1435)
==19407==by 0x380A027A: thread_wrapper (syswrap-linux.c:103)
==19407==by 0x380A027A: run_a_thread_NORETURN (syswrap-linux.c:156)


Reproducible: Always

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

[valgrind] [Bug 369264] Fedora 24 i686 and vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x10 0x3

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369264

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #1 from Mark Wielaard  ---
That is vmovups which is only supported by valgrind as amd64 (x86_64)
instruction.

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

[valgrind] [Bug 369209] valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

--- Comment #5 from Mark Wielaard  ---
(In reply to Ivo Raisr from comment #4)
> So this simple change fixes the warning:
> -   execlp ("echo", "echo", "Hello", "World", NULL);
> +  execlp ("echo", "echo", "Hello", "World", (char *) NULL);

Thanks, fixed. 

> As for the test itself, it cannot simulate invalid cwd on Solaris, because
> rmdir returns EINVAL:
>EINVAL  The  directory  to be removed is the current
> directory,
>or the final component of path is ".".
> 
> Is there any other way how to simulate invalid cwd?

Maybe the test doesn't make sense for Solaris if you cannot remove the cwd.
Then maybe we should move it under none/tests/linux.

Can you remove the cwd of another process?  Then we could fork/exec another
process
in the test, move the cwd and then remove the cwd of its parents process.
Then execution of echo (with --trace-children) will get a process without cwd
as we want.

Or is it possible to trigger any other getcwd failure?
Maybe chmod the cwd (or its parent dir) to 000?
Or create a directory hierarchy deeper than PATH_MAX?

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #17 from Mark Wielaard  ---
Since some of the output looks as if we jump into (or just read from?) the ODP
and that gives a permission error/SEGV, could you provide the section and
segments of the tool to double check everything is at the right place?
eu-readelf -Sl  none-ppc64be-linux

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #18 from Mark Wielaard  ---
Never mind the objdump -h gives the right information. The 0x3824B2B0 is indeed
in the middle of the ODP. The ODP is loaded and DATA (not CODE), which I assume
means it is readable (so we can load/read the actual function address and jump
to that) but not execute it.

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #9 from Mark Wielaard  ---
Assuming that is with remote vgdb attached then you should be able to get the
generated IR and assembly with:
 monitor v.translate 0x100016dc 0b0011

(See the manual or valgrind --help-debug for the explanation of the
--trace-flags)

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #6 from Mark Wielaard  ---
(In reply to Julian Seward from comment #3)
> I tried to reproduce this on gcc112.fsffrance.org (a P8 system) but failed --
> it runs OK.  I'd be happy to chase this if I could reproduce on a machine
> that I can access.

gcc112 is ppc64le which seems to work fine. Unfortunately the ppc64[be]
machines in the GCC compile farm are all power7, not power8 (as gcc112 is).

> (3) with --tool=none, run it with --trace-flags=10001110 and
>--trace-notbelow= set to the appropriate value so you actually
>get output for the failing block.  From that we might be able
>to guess what the problem is.

It is sometimes convenient to do that from gdb. Run with ./vg-in-place
--vgdb-error=0 none/tests/ppc64/test_isa_2_07_part1 in one terminal gdb
none/tests/ppc64/test_isa_2_07_part1 in another. Attach in gdb with target
remote | coregrind/vgdb. continue. It gets the SEGV. Find the address where it
crashed. Then use monitor v.translate  [] to dump the
block. The traceflags are the same. See
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.valgrind-monitor-commands

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

[valgrind] [Bug 369209] valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

Mark Wielaard  changed:

   What|Removed |Added

 CC||iv...@ivosh.net,
   ||rhysk...@gmail.com

--- Comment #2 from Mark Wielaard  ---
Ivo and Rhys could you double check that my patch does the right thing and the
new nocwd.vgtest passes on Solaris and Darwin?

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

[valgrind] [Bug 369209] valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

--- Comment #1 from Mark Wielaard  ---
Created attachment 101237
  --> https://bugs.kde.org/attachment.cgi?id=101237=edit
Don't require the current working directory to exist.

At startup valgrind fetches the current working directory and stashes
it way to be used later (in debug messages, read config files or create
log files). But if the current working directory didn't exist (or there
was some other error getting its path) then valgrind would go in a
endless loop. This was caused by assuming that any error meant a larger
buffer needed to be created to store the cwd path (ERANGE). However
there could be other reasons calling getcwd failed.

Fix this by only looping and resizing the buffer when the error is
ERANGE. Any other error just means we cannot fetch and store the current
working directory. Fix all callers to check get_startup_wd() returns
NULL. Only abort startup if a relative path needs to be used for
user supplied relative log files. Debug messages will just show
"". And skip reading any config files from the startup_wd
if it doesn't exist.

Also add a new testcase that tests executing valgrind in a non-existing
directory (none/tests/nocwd.vgtest).

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

[valgrind] [Bug 369209] New: valgrind loops and eats up all memory (very slowly) when the current working directory doesn't exist.

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369209

Bug ID: 369209
   Summary: valgrind loops and eats up all memory (very slowly)
when the current working directory doesn't exist.
   Product: valgrind
   Version: 3.12 SVN
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

The following code in record_startup_wd():

/* Simple: just ask the kernel */
SysRes res;
SizeT szB = 0;
do {
   szB += 500;
   startup_wd = VG_(realloc)("startup_wd", startup_wd, szB);
   VG_(memset)(startup_wd, 0, szB);
   res = VG_(do_syscall2)(__NR_getcwd, (UWord)startup_wd, szB-1);
} while (sr_isError(res));

Will loop forever when getcwd() produces any error. It should check that the
error is ERANGE.
Even when fixing that and returning an error (False) will make valgrind refuse
to run the program.
This isn't really necessary because often the startup_wd isn't really used or
needed.

Reproducible: Always

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

[valgrind] [Bug 368419] Perf Events ioctls not implemented

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368419

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #4 from Mark Wielaard  ---
(In reply to Keno Fischer from comment #3)
> > If I interpret this correctly, ARG3 is a C style zero-terminated string 
> > that the syscall
> > reads.  Is that correct?
> 
> Essentially yes, though with the caveat that if there's no NUL after
> PAGE_SIZE-1 bytes, it'll still accept that as far as I know (as a
> PAGE_SIZE-1 sized string), since it uses strndup_user(str, PAGE_SIZE) on the
> kernel side of things.

That seems a funny corner case that I cannot imagine anybody relies on (the
caller would have to explicitly not pass a zero terminated string larger than
PAGE_SIZE, which is different on different arches). If someone does I think a
warning from valgrind seems somewhat justified. So just using PRE_MEM_RASCIIZ
here should be fine.

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

[valgrind] [Bug 357932] vex amd64->IR: unhandled instruction bytes: 0xF2 0x49 0xF 0x5D and 0xF2 0x49 0xF 0x5F

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357932

--- Comment #4 from Mark Wielaard  ---
Or maybe Julian means the "redundant" REXB is altering the e register field and
so it needs further adjustment to get the correct register if REXB is set.

Anyway, a testcase and how to (or what) generates it would be appreciated.

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

[valgrind] [Bug 357932] vex amd64->IR: unhandled instruction bytes: 0xF2 0x49 0xF 0x5D and 0xF2 0x49 0xF 0x5F

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357932

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #3 from Mark Wielaard  ---
(In reply to Axel Müller from comment #2)
> (In reply to Julian Seward from comment #1)
> > f2 49 0f 5d 00  rex.WB minsd (%r8),%xmm0
> > f2 49 0f 5f 00  rex.WB maxsd (%r8),%xmm0
> > 
> > I'm sure these insns are handled really.  It's just the redundant rex.WB
> > prefix
> > that is causing them not to get decoded.
> So what would you suggest? To be honest I only modified another patch
> without really understanding the code.

I think you patch is ok. Maybe you could say:

  if (haveF2no66noF3(pfx)
  && (sz == 4
 || /* ignore redundant REX.W */ sz == 8 && getRexW(pfx) == 1))
{

But we would need a testcase. What generates these minsd/maxsd with extra
REX.W?

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

[valgrind] [Bug 368120] x86_linux asm _start functions do not keep 16-byte aligned stack pointer

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368120

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #1 from Mark Wielaard  ---
Note that this is also true for gcc x86[-32] now. The abi used to say, and
older gcc only guaranteed/relied upon, the stack being 4 byte aligned. But a
couple of years ago the abi and gcc got changed to align the stack at a 16 byte
boundary. See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
With gcc generated code it only seems an issue if the called function uses any
sse instructions.

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

[valgrind] [Bug 369169] ppc64 fails jm_int_isa_2_07 test

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369169

--- Comment #6 from Mark Wielaard  ---
(In reply to Carl Love from comment #5)
> Please test the patch and see if the regression test results are as expected
> on your machine.

They PASS. Thanks.

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

[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

--- Comment #1 from Mark Wielaard  ---
Note that running the program itself (not under valgrind) seems fine.
It is only when ran under valgrind that it produces the SIGSEGV:

==28394== Process terminating with default action of signal 11 (SIGSEGV)
==28394==  Bad permissions for mapped region at address 0x3828C978
==28394==at 0x100016D4: test_bcdadd (test_isa_2_07_part1.c:710)
==28394==by 0x10001A2B: test_av_bcd (test_isa_2_07_part1.c:1419)
==28394==by 0x420646B: generic_start_main.isra.0 (in
/usr/lib64/libc-2.17.so)
==28394==by 0x4206693: (below main) (in /usr/lib64/libc-2.17.so)

static int PS_bit;
static void test_bcdadd (void)
{
   if (PS_bit)
  __asm__ __volatile__ ("bcdadd. %0, %1, %2, 1" : "=v" (vec_out): "v"
(vec_inA),"v" (vec_inB));
   else
=>  __asm__ __volatile__ ("bcdadd. %0, %1, %2, 0" : "=v" (vec_out): "v"
(vec_inA),"v" (vec_inB));
}

=> is line 710.

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

[valgrind] [Bug 369175] New: jm_vec_isa_2_07 test crashes on ppc64

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369175

Bug ID: 369175
   Summary: jm_vec_isa_2_07 test crashes on ppc64
   Product: valgrind
   Version: 3.12 SVN
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

none/tests/ppc64/jm_vec_isa_2_07.vgtest runs fine on ppc64le, but crashes on a
ppc64[be] setup:

gcc-4.8.5-11.el7.ppc64
binutils-2.25.1-22.base.el7.ppc64
glibc-2.17-157.el7.ppc64
glibc-2.17-157.el7.ppc
kernel-3.10.0-508.el7.ppc64

processor: 0
cpu: POWER8 (architected), altivec supported
clock: 3425.00MHz
revision: 2.1 (pvr 004b 0201)

timebase: 51200
platform: pSeries
model: IBM,8247-22L
machine: CHRP IBM,8247-22L

none/tests/ppc64/jm_vec_isa_2_07.stderr.diff says:

+Process terminating with default action of signal 11 (SIGSEGV)
+ Bad permissions for mapped region at address 0x
+   at 0x: test_bcdadd (test_isa_2_07_part1.c:710)
+   by 0x: test_av_bcd (test_isa_2_07_part1.c:1419)
+   by 0x: generic_start_main.isra.0 (in /...libc...)
+   by 0x: (below main)

Up to that point the stdout output looks like expected.

Reproducible: Always

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

[valgrind] [Bug 369169] ppc64 fails jm_int_isa_2_07 test

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369169

--- Comment #4 from Mark Wielaard  ---
The diffs are the same because the none/tests/ppc64/jm_int_isa_2_07.stdout.exp
and none/tests/ppc64/jm_int_isa_2_07.stdout.exp-LE expect files are the same.

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

[valgrind] [Bug 369169] ppc64 fails jm_int_isa_2_07 test

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369169

--- Comment #3 from Mark Wielaard  ---
Created attachment 101220
  --> https://bugs.kde.org/attachment.cgi?id=101220=edit
diff with LE expected output

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

[valgrind] [Bug 369169] ppc64 fails jm_int_isa_2_07 test

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369169

--- Comment #2 from Mark Wielaard  ---
Created attachment 101219
  --> https://bugs.kde.org/attachment.cgi?id=101219=edit
diff with expected output

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

[valgrind] [Bug 369169] ppc64 fails jm_int_isa_2_07 test

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369169

--- Comment #1 from Mark Wielaard  ---
Created attachment 101218
  --> https://bugs.kde.org/attachment.cgi?id=101218=edit
test output

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

[valgrind] [Bug 369169] New: ppc64 fails jm_int_isa_2_07 test

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369169

Bug ID: 369169
   Summary: ppc64 fails jm_int_isa_2_07 test
   Product: valgrind
   Version: 3.12 SVN
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: vex
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

On ppc32 and ppc64le the jm_int_isa_2_07 test passes.
But on ppc64[be] ./none/tests/ppc64/jm_int_isa_2_07.stdout.out doesn't match
either the jm_int_isa_2_07.stdout.exp or jm_int_isa_2_07.stdout.exp-LE

This system has:
gcc-4.8.5-11.el7.ppc64
binutils-2.25.1-22.base.el7.ppc64
glibc-2.17-157.el7.ppc64
glibc-2.17-157.el7.ppc
kernel-3.10.0-508.el7.ppc64

processor   : 0
cpu : POWER8 (architected), altivec supported
clock   : 3425.00MHz
revision: 2.1 (pvr 004b 0201)

timebase: 51200
platform: pSeries
model   : IBM,8247-22L
machine : CHRP IBM,8247-22L

Reproducible: Always

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

[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596
Bug 339596 depends on bug 369000, which changed state.

Bug 369000 Summary: AMD64 fma4 instructions unsupported. vex amd64->IR: 
unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=369000

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[valgrind] [Bug 369000] AMD64 fma4 instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369000

Mark Wielaard  changed:

   What|Removed |Added

 Blocks||369053

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

[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

Mark Wielaard  changed:

   What|Removed |Added

 Depends on||369053

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

[valgrind] [Bug 369053] New: AMD64 fma4 instructions missing 256 bit support

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369053

Bug ID: 369053
   Summary: AMD64 fma4 instructions missing 256 bit support
   Product: valgrind
   Version: 3.9.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: vex
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com
CC: andreas.boer...@w84u.org, bellamy.b...@gmail.com,
dra...@shaw.ca, m...@redhat.com, p4pl...@gmail.com,
smj...@gmail.com, t...@compton.nu
Depends on: 369000
Blocks: 339596

Lets clone this once again. We now have fma4 support, but only for the
128bit/xmm cases. There are already tests (in none/tests/amd64/fma4.c) for the
256bit/ymm cases, but these are disabled for now because those aren't
implemented yet. This would need to check getVexL(pfx) and extend the
operations to the full 256bits.

+++ This bug was initially created as a clone of Bug #369000 +++

Lets split the fma4 and xop instructions into separate bugs & patches.
(I have already looked at the fma4 ones, but haven't had time for the xop
instructions.)

+++ This bug was initially created as a clone of Bug #339596 +++

When running valgrind upon program startup I immediately run into an illegal
instruction.  My first action was to try using the latest source from SVN, this
however, did not help.  Below are a few extra details on the instruction in
question, my system, and anything else I can think of.

vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5
0xF9
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==16432== valgrind: Unrecognised instruction at address 0x5adb623.
==16432==at 0x5ADB623: findChar(QChar const*, int, QChar, int,
Qt::CaseSensitivity) (in /usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5AEC0C9: QString::split(QChar, QString::SplitBehavior,
Qt::CaseSensitivity) const (in /usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5BC8E61:
QStandardPaths::standardLocations(QStandardPaths::StandardLocation) (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5B7D9B7:
QStandardPaths::locate(QStandardPaths::StandardLocation, QString const&,
QFlags) (in /usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5BB6028: QLoggingRegistry::init() (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5C2BC8A: QCoreApplication::init() (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5C2BEF5:
QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5560718:
QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) (in
/usr/lib64/libQt5Gui.so.5.4.0)
==16432==by 0x4F8F23C: QApplication::QApplication(int&, char**, int) (in
/usr/lib64/libQt5Widgets.so.5.4.0)
==16432==by 0x40D62D: main (main.cpp:37)

I've run it through GDB and grabbed a disassembly output (More can be provided
if requested):
   0x05adb619 <+329>:mov%r8,%rax
   0x05adb61c <+332>:vmovups (%rax),%xmm0
   0x05adb620 <+336>:mov%rcx,%r8
=> 0x05adb623 <+339>:vpcomw $0x4,%xmm1,%xmm0,%xmm0
   0x05adb629 <+345>:vpmovmskb %xmm0,%esi
   0x05adb62d <+349>:test   %si,%si
   0x05adb630 <+352>:je 0x5adb610
<_ZL8findCharPK5QChariS_iN2Qt15CaseSensitivityE+320>
   0x05adb632 <+354>:bsf%esi,%esi
   0x05adb635 <+357>:sub%rdi,%rax

My system CPU is an AMD FX-8150, and Qt (where the instruction seems to
originate) is compiled with GCC 4.8.  I am running a Gentoo based system and
have used -march=native, -O2, and -fomit-frame-pointer as my only three default
CFLAGS.   

If it helps I can setup a VM with SSH access temporarily to aid in
testing/debugging of the problem.  However, for sanity sake I will only do this
Valgrind developers.

My final observersations seem to be that the XOP and FM4 instructions
introduced in the bulldozer generation AMD processors seem to cause the most
trouble.  But that may be beyond the scope of this bug report.

Reproducible: Always

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

[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

Mark Wielaard  changed:

   What|Removed |Added

 Blocks|369000  |
 Depends on||369000

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

[valgrind] [Bug 369000] AMD64 fma4 instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369000

Mark Wielaard  changed:

   What|Removed |Added

 Depends on|339596  |
 Blocks||339596
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[valgrind] [Bug 358213] helgrind/drd bar_bad testcase hangs with new glibc pthread barrier implementation

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358213

--- Comment #6 from Mark Wielaard  ---
I checked in a workaround for the hang based on the attachement as valgrind svn
r15962.

This does make sure that the tests don't hang indefenitely. But they do
introduce (more) non-determinism that occassionally causes these tests to fail
or even trigger an internal drd assert (drd_barrier.c:352
(vgDrd_barrier_pre_wait): Assertion 'p' failed.)

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

[valgrind] [Bug 369000] AMD64 fma4 instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369000

--- Comment #3 from Mark Wielaard  ---
VEX svn r3249 and valgrind svn r15961

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

[valgrind] [Bug 369000] AMD64 fma4 instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369000

--- Comment #2 from Mark Wielaard  ---
Created attachment 101170
  --> https://bugs.kde.org/attachment.cgi?id=101170=edit
Testcases for fma4 instructions.

This is an extension of the testcases for the fma4 instructions I wrote for bug
#339596.

There are tests for the 128bit and 256 bit instructions, but the 256 bit
variants are disabled for now since they aren't yet implemented.

I looked at the testcase (none/tests/arm64/fp_and_simd.c) Julian pointed out
and took the various zero/inf/nan/subnormal cases from there. But I don't
filter them out of the tests. Instead I explicitly add them and print them out
as +/-ZERO, +/-INF, NAN and SUBNORMAL. To do this correctly I had to split the
tests into ones that work on floats (ending in S) and those that work on
doubles (ending in D).

There is a little bit of duplication because you have to indicate whether the
instruction works on floats or doubles both when generating and when calling
the testcase (someone with stronger preprocessor foo might be able to "fix"
that).

Although the testcase tries to generate positive and negative NAN values the
test does not check for that (I don't believe NANs can be positive/negative).
If we would test for that the testcase would fail since we sometimes generate a
different representation for NAN that is positive/negative according to
signbit().

The testcase does produce and test for positive/negative SUBNORMALs, I am not
100% sure that makes sense. It doesn't impact the result though.

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

[valgrind] [Bug 369000] AMD64 fma4 instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369000

--- Comment #1 from Mark Wielaard  ---
Created attachment 101169
  --> https://bugs.kde.org/attachment.cgi?id=101169=edit
Implement AMD FMA4 instructions.

This is just the FMA4 part of the patch proposed in bug #339596. The original
patch is by p4pl...@gmail.com with some minor formatting cleanups and an
explicit clearing of the the upper 128 bits of the YMM registers these
instruction operate on. It only handles the 128bit variants (that is the
explicit 0==getVexL(pfx) check in the patch).

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

[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

Mark Wielaard  changed:

   What|Removed |Added

Summary|AMD64 fma4 and xop  |AMD64 xop instructions
   |instructions unsupported.   |unsupported. vex amd64->IR:
   |vex amd64->IR: unhandled|unhandled instruction
   |instruction bytes: 0x8F |bytes: 0x8F 0xE8 0x78 0xCD
   |0xE8 0x78 0xCD 0xC1 0x4 |0xC1 0x4 0xC5 0xF9
   |0xC5 0xF9   |

--- Comment #22 from Mark Wielaard  ---
I split this bug into a xop (this) one and fma4 (bug #369000) one.
I had some time to look at the fma4 instructions, but not yet at the xop one.
So I split the patch in two.

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

[valgrind] [Bug 339596] AMD64 fma4 and xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

Mark Wielaard  changed:

   What|Removed |Added

 Blocks||369000

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

[valgrind] [Bug 369000] New: AMD64 fma4 instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369000

Bug ID: 369000
   Summary: AMD64 fma4 instructions unsupported. vex amd64->IR:
unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1
0x4 0xC5 0xF9
   Product: valgrind
   Version: 3.9.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: vex
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com
CC: andreas.boer...@w84u.org, bellamy.b...@gmail.com,
dra...@shaw.ca, m...@redhat.com, p4pl...@gmail.com,
smj...@gmail.com, t...@compton.nu
Depends on: 339596

Lets split the fma4 and xop instructions into separate bugs & patches.
(I have already looked at the fma4 ones, but haven't had time for the xop
instructions.)

+++ This bug was initially created as a clone of Bug #339596 +++

When running valgrind upon program startup I immediately run into an illegal
instruction.  My first action was to try using the latest source from SVN, this
however, did not help.  Below are a few extra details on the instruction in
question, my system, and anything else I can think of.

vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5
0xF9
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==16432== valgrind: Unrecognised instruction at address 0x5adb623.
==16432==at 0x5ADB623: findChar(QChar const*, int, QChar, int,
Qt::CaseSensitivity) (in /usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5AEC0C9: QString::split(QChar, QString::SplitBehavior,
Qt::CaseSensitivity) const (in /usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5BC8E61:
QStandardPaths::standardLocations(QStandardPaths::StandardLocation) (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5B7D9B7:
QStandardPaths::locate(QStandardPaths::StandardLocation, QString const&,
QFlags) (in /usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5BB6028: QLoggingRegistry::init() (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5C2BC8A: QCoreApplication::init() (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5C2BEF5:
QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (in
/usr/lib64/libQt5Core.so.5.4.0)
==16432==by 0x5560718:
QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) (in
/usr/lib64/libQt5Gui.so.5.4.0)
==16432==by 0x4F8F23C: QApplication::QApplication(int&, char**, int) (in
/usr/lib64/libQt5Widgets.so.5.4.0)
==16432==by 0x40D62D: main (main.cpp:37)

I've run it through GDB and grabbed a disassembly output (More can be provided
if requested):
   0x05adb619 <+329>:mov%r8,%rax
   0x05adb61c <+332>:vmovups (%rax),%xmm0
   0x05adb620 <+336>:mov%rcx,%r8
=> 0x05adb623 <+339>:vpcomw $0x4,%xmm1,%xmm0,%xmm0
   0x05adb629 <+345>:vpmovmskb %xmm0,%esi
   0x05adb62d <+349>:test   %si,%si
   0x05adb630 <+352>:je 0x5adb610
<_ZL8findCharPK5QChariS_iN2Qt15CaseSensitivityE+320>
   0x05adb632 <+354>:bsf%esi,%esi
   0x05adb635 <+357>:sub%rdi,%rax

My system CPU is an AMD FX-8150, and Qt (where the instruction seems to
originate) is compiled with GCC 4.8.  I am running a Gentoo based system and
have used -march=native, -O2, and -fomit-frame-pointer as my only three default
CFLAGS.   

If it helps I can setup a VM with SSH access temporarily to aid in
testing/debugging of the problem.  However, for sanity sake I will only do this
Valgrind developers.

My final observersations seem to be that the XOP and FM4 instructions
introduced in the bulldozer generation AMD processors seem to cause the most
trouble.  But that may be beyond the scope of this bug report.

Reproducible: Always

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

[valgrind] [Bug 355188] valgrind should intercept all malloc related global functions by default

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=355188

Mark Wielaard  changed:

   What|Removed |Added

 CC||y...@tsoft.com

--- Comment #6 from Mark Wielaard  ---
*** Bug 368861 has been marked as a duplicate of this bug. ***

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

[valgrind] [Bug 368861] Please make valgrind work with programs using google-perftools malloc library

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368861

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Mark Wielaard  ---
This should already work when using --soname-synonyms=somalloc=xxx (see the
manual). In valgrind 3.12 this should even work out of the box without the user
having to specify the malloc library by intercepting any interposed malloc
related functions. See bug #355188.

*** This bug has been marked as a duplicate of bug 355188 ***

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

[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=322935

--- Comment #34 from Mark Wielaard  ---
(In reply to Peter Maydell from comment #33)
> (In reply to Mark Wielaard from comment #32)
> > valgrind should already intercept the memcmp from glibc. This one however is
> > in a different library libcofi_rpi.so which looks like some kind of hack to
> > interpose some standard libc functions. It seems this is actually preloaded
> > somehow. So it might be as simple as removing the preload hack when running
> > under valgrind?
> 
> The idea would be to do something which works out of the box; otherwise you
> won't stop the trickle of bug reports (and probably larger set of users who
> just decide valgrind doesn't work without reporting a bug).

Sure. But that requires someone with a raspi and knowledge of what this
libcofi_rpi.so hackery really is.

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

[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=322935

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #32 from Mark Wielaard  ---
(In reply to Peter Maydell from comment #31)
> Alternatively, if valgrind could do a redirection of memcmp() in the
> offending .so file to its own implementation (the way it already does for a
> bunch of other functions) that would be a very raspi-specific hack but would
> cover 90%+ of the complaints I suspect

valgrind should already intercept the memcmp from glibc. This one however is in
a different library libcofi_rpi.so which looks like some kind of hack to
interpose some standard libc functions. It seems this is actually preloaded
somehow. So it might be as simple as removing the preload hack when running
under valgrind?

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

[valgrind] [Bug 364948] Add IBM ISA 3.0 support, patch set 5

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364948

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #11 from Mark Wielaard  ---
This was already committed as VEX svn r3244 and valgrind svn r15938

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

[valgrind] [Bug 359503] Add missing syscalls for aarch64 (arm64)

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359503

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #12 from Mark Wielaard  ---
Added adjtimex for arm64 and fixed a bug in the syscall wrapper.
valgrind svn r15953.

Please open a new bug for missing syscalls next time instead of reusing this
one.

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

[valgrind] [Bug 368791] unhandled syscall: 167

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368791

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #2 from Mark Wielaard  ---
amd64-linux syscall 167 is swapon for which valgrind only has an implementation
for mip64, but no other arches apparently.

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

[valgrind] [Bug 368791] unhandled amd64-linux syscall: 167 (swapon)

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368791

Mark Wielaard  changed:

   What|Removed |Added

Summary|unhandled syscall: 167  |unhandled amd64-linux
   ||syscall: 167 (swapon)

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

[valgrind] [Bug 361726] WARNING:unhandled syscall on ppc64 and amd64 (membarrier)

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361726

--- Comment #6 from Mark Wielaard  ---
BTW. This is an awesome overview of all the linux syscalls by architectures:
https://fedora.juszkiewicz.com.pl/syscalls.html

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

[valgrind] [Bug 361726] WARNING:unhandled syscall on ppc64 and amd64 (membarrier)

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361726

Mark Wielaard  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|WAITINGFORINFO  |---
Summary|WARNING:unhandled syscall   |WARNING:unhandled syscall
   |on ppc64|on ppc64 and amd64
   ||(membarrier)
 CC||m...@redhat.com
 Status|NEEDSINFO   |CONFIRMED

--- Comment #5 from Mark Wielaard  ---
The membarrier() system call was added in Linux 4.3.
http://www.man7.org/linux/man-pages/man2/membarrier.2.html
Which contains a small test program that also fails on amd64-linux.
WARNING: unhandled amd64-linux syscall: 324

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

[valgrind] [Bug 358620] ARM: disInstr(arm): unhandled instruction: 0xF1010200

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358620

Mark Wielaard  changed:

   What|Removed |Added

Summary|ARM: unhandled syscall: 357 |ARM: disInstr(arm):
   ||unhandled instruction:
   ||0xF1010200
 CC||m...@redhat.com

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

[valgrind] [Bug 368412] False positive result for altivec capability check

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368412

--- Comment #6 from Mark Wielaard  ---
Thanks, pushed as valgrind svn r15952

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

[valgrind] [Bug 359181] Buffer Overflow during Demangling

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359181

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Mark Wielaard  ---
valgrind svn r15951

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

[valgrind] [Bug 368412] False positive result for altivec capability check

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368412

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #3 from Mark Wielaard  ---
You are changing the AC_DEFINE from HAS_ALTIVEC to COMPILER_SUPPORTS_ALTIVEC.
But COMPILER_SUPPORTS_ALTIVEC is never used as C preprocessor symbol, so I
think you should just remove it.

HAS_ALTIVEC is used as an C preprocessor symbol in none/tests/ppc32/jm-insns.c
but there it is defined in the Makefile depending on the AM_CONDITIONAL
HAS_ALTIVEC. So that should be fine (although the comment in the code implies
it comes from config.h, which isn't true anymore).

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

[valgrind] [Bug 359181] Buffer Overflow during Demangling

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359181

Mark Wielaard  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|jsew...@acm.org |m...@redhat.com
 Status|UNCONFIRMED |ASSIGNED
 CC||m...@redhat.com

--- Comment #2 from Mark Wielaard  ---
Created attachment 101012
  --> https://bugs.kde.org/attachment.cgi?id=101012=edit
Update libiberty demangler

This particular bug (and many more issues) has been fixed upstream now.

Update the libiberty demangler using the auxprogs/update-demangler
script. There were various extensions and bug fixes since our last
import. Add new D language demangler file d-demangle.c and update
the vg_libciface.h header with some new constructs used (strtol,
xmalloc_failed, xmemdup, XDELETEVEC, XDUPVEC).

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

[valgrind] [Bug 339596] AMD64 fma4 and xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

Mark Wielaard  changed:

   What|Removed |Added

Summary|vex amd64->IR: unhandled|AMD64 fma4 and xop
   |instruction bytes: 0x8F |instructions unsupported.
   |0xE8 0x78 0xCD 0xC1 0x4 |vex amd64->IR: unhandled
   |0xC5 0xF9   |instruction bytes: 0x8F
   ||0xE8 0x78 0xCD 0xC1 0x4
   ||0xC5 0xF9

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

[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

--- Comment #19 from Mark Wielaard  ---
Created attachment 100956
  --> https://bugs.kde.org/attachment.cgi?id=100956=edit
Current stdout.diff file for new fma4.vgtest and proposed patch

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

[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

--- Comment #18 from Mark Wielaard  ---
Created attachment 100955
  --> https://bugs.kde.org/attachment.cgi?id=100955=edit
Testcases for fma4 instructions

Here are some testcases for the FMA4 instructions. I haven't looked yet at the
XOP instructions.
Maybe it is an idea to do FMA4 and XOP as separate patches?

The testcase is based on the idea from the avx-1.c testcase. It creates a a
block of values loads some of the values into xmm/ymm registers and creates a
memory reference to another. Then it prints the contents of the block before
and after the various instructions. The expected output comes from running the
program on an actual processor having fma4 instructions. This is then compared
with the same program running under valgrind.

With the current patch there are some differences.

First the 256bit ymm operations aren't supported, so they have been disabled in
the testcase for now. But I am not sure we really should enable the fma4 cpuid
bit in valgrind before we really support them.

Secondly some 128bit xmm operations should clear the upper 128 bits
of the corresponding YMM register to zeros and don't do so at the moment.

Lastly the "full 0xFF" testcases do show some differences (but the zeros, ones
and random cases all look fine).

I'll also attach the stdout.diff next.

If you think doing full bit-indentical tests are not fair/achievable for these
instructions then let me know and we can see if we can create some testcases
that explicitly work on float/double results.

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

[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=339596

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #17 from Mark Wielaard  ---
About the testcase. The __builtin_ia32_xxx are really just internal compiler
details. They might or might not be there between versions of the same compiler
or between different compilers. They might not even implement the same thing or
take different arguments. For example the testcase uses __builtin_ia32_vpcomew
with an extra argument that says which kind of operation/memonic is really
meant, while gcc provides 8 separate __builtin_ia32_vpcom[xxx] to provide the
same functionality. The testcase uses separate __builtin_ia32_vfnmaddxx and
__builtin_ia32_vfnmsubxx functions, while gcc just provides one which takes a
positive or negative argument. There is also no guarantee that these functions
translate to some exact instruction (sequence).

So it would be better to rewrite the testcase to use explicit inline assembly
using the exact instructions that we want to test.

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

[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360571

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

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

[valgrind] [Bug 359952] Unrecognised PCMPESTRM variants

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359952

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@redhat.com

--- Comment #1 from Mark Wielaard  ---
Another unhandled x86 sse42 vpcmpestri variant (0x19) is generated by the
latest openjdk hotspot.

Imm8 Control Byte == 0x19. If I am reading the instruction manual correctly
0x19 (0011001) means:
- source data format is unsigned words (01)
- comparison type is match (10)
- post-procession option is NOT CmprSumm (01)
- indexed output option selection is the least significant set bit (0)

A workaround is running java -XX:-UseSSE42Intrinsics to disable the string
comparision optimisations when running under valgrind.

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

[valgrind] [Bug 364413] pselect sycallwrapper mishandles NULL sigmask

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364413

--- Comment #3 from Mark Wielaard  ---
I made a typo which caused:

...checking makefile consistency
none/tests/Makefile.am:1: error: pselect_sigmask_null.vgtest is missing in
EXTRA_DIST
none/tests/Makefile.am:1: error: pselect_signask_null.vgtest is in EXTRA_DIST
but doesn't exist

Fixed with valgrind svn r15894
Bug 364413 followup - fix signask -> sigmask typo in EXTRA_DIST

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

[valgrind] [Bug 364413] pselect sycallwrapper mishandles NULL sigmask

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364413

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Wielaard  ---
valgrind svn 15893

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

[valgrind] [Bug 364413] pselect sycallwrapper mishandles NULL sigmask

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364413

--- Comment #1 from Mark Wielaard  ---
Created attachment 99546
  --> https://bugs.kde.org/attachment.cgi?id=99546=edit
Proposed testcase and fix

When the last argument ss == NULL don't check whether it is valid and don't try
to copy the sigmask (which would crash because it is NULL), just pass through
the NULL sigmask to the kernel. Testcase provided by Paul Eggert in the
original bug report https://bugzilla.redhat.com/show_bug.cgi?id=1344082

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

[valgrind] [Bug 364413] New: pselect sycallwrapper mishandles NULL sigmask

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364413

Bug ID: 364413
   Summary: pselect sycallwrapper mishandles NULL sigmask
   Product: valgrind
   Version: 3.11 SVN
  Platform: Other
   URL: https://bugzilla.redhat.com/show_bug.cgi?id=1344082
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: m...@redhat.com

This is a regression caused by valgrind svn r15823 which fixed Bug 359871
"sanitize signal mask in ppoll and pselect syscalls".

The issue is caused by this C library/kernel ABI differences according to
http://man7.org/linux/man-pages/man2/pselect6.2.html

   The Linux pselect6() system call modifies its timeout argument.
   However, the glibc wrapper function hides this behavior by using a
   local variable for the timeout argument that is passed to the system
   call.  Thus, the glibc pselect() function does not modify its timeout
   argument; this is the behavior required by POSIX.1-2001.

   The final argument of the pselect6() system call is not a sigset_t *
   pointer, but is instead a structure of the form:

   struct {
   const sigset_t *ss; /* Pointer to signal set */
   size_t  ss_len; /* Size (in bytes) of object pointed
  to by 'ss' */
   };

   This allows the system call to obtain both a pointer to the signal
   set and its size, while allowing for the fact that most architectures
   support a maximum of 6 arguments to a system call.

What we are seeing is glibc modifying the timeout argument (NULL) and passing
it as a struct { NULL, 8 } (where 8 is the correct ss_len if ss wouldn't be
NULL).

valgrind doesn't check whether ss is NULL before calling PRE_MEM_READ on it and
so generates a bogus warning.

Reproducible: Always

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

[valgrind] [Bug 363680] add renameat2() support

[Mark Wielaard via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363680

Mark Wielaard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Mark Wielaard  ---
I see glibc also doesn't expose it yet. But the code looks fine.
Committed as valgrind svn r15889.
Thanks

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