[valgrind] [Bug 359289] s390x: popcnt (B9E1) not implemented
https://bugs.kde.org/show_bug.cgi?id=359289 Florian Krohm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Florian Krohm --- (In reply to Andreas Arnez from comment #4) > > In opcodes.h you define POPCNT. Good! Why not use it in popcnt.c? > Just a matter of taste. I prefer leaving the choice of operand registers to > the compiler, like you would do in production code. I've added opcodes.h mainly to deal with certain issues in old binutils versions. I don't recall exactly what those problems were. > Can you add a check_popcnt call in popcnt.c where all input bits are 1? > Sure. Any particular reason for testing this specific value? I like to test boundary values. > > We also need configury to check whether the machine has the POPCNT insn. And > > only if the machine supports that opcode we should build the test. > Not sure about that one. The patch always emulates the instruction, > independent of the host capabilities. Right! Not sure what I was thinking. Thanks for the respin. I've added the patch as r15792 and VEX r3210 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359289] s390x: popcnt (B9E1) not implemented
https://bugs.kde.org/show_bug.cgi?id=359289 Florian Krohm changed: What|Removed |Added CC||flor...@eich-krohm.de --- Comment #3 from Florian Krohm --- (In reply to Andreas Arnez from comment #1) > Created attachment 97264 [details] > Implement popcnt for s390x > > Suggested fix for this Bug. Thanks for the patch. As Mark said: none/tests/s390x/Makefile.am needs adjustment. Otherwise the popcnt test does not get built during "make check". In opcodes.h you define POPCNT. Good! Why not use it in popcnt.c? Can you add a check_popcnt call in popcnt.c where all input bits are 1? We also need configury to check whether the machine has the POPCNT insn. And only if the machine supports that opcode we should build the test. Other than that the patch looks good. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359181] Buffer Overflow during Demangling
https://bugs.kde.org/show_bug.cgi?id=359181 Florian Krohm changed: What|Removed |Added CC||flor...@eich-krohm.de --- Comment #1 from Florian Krohm --- Thanks for letting us know. We'll watch upstream as the bug is in their shop. We just pull in the code from the GCC demangler. I believe that upstream is actually binutils rather than gcc as the demangling code is part of libiberty. If you don't get any response from gcc you might want to raise the bug there. BTW: the c++filt tool (part of binutils) has the same issue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356393] valgrind (vex) crashes because isZeroU happened
https://bugs.kde.org/show_bug.cgi?id=356393
--- Comment #5 from Florian Krohm ---
This is the guilty code:
case Iop_Xor8:
case Iop_Xor16:
case Iop_Xor32:
case Iop_Xor64:
case Iop_XorV128:
case Iop_XorV256:// < selecting this case
/* Xor8/16/32/64/V128(t,t) ==> 0, for some IRTemp t */
if (sameIRExprs(env, e->Iex.Binop.arg1, e->Iex.Binop.arg2)) {
// <=== false
e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
break;
}
/* XorV128(t,0) ==> t */
if (e->Iex.Binop.op == Iop_XorV128) {
if (isZeroV128(e->Iex.Binop.arg2)) {
e2 = e->Iex.Binop.arg1;
break;
}
//Disabled because there's no known test case right now.
//if (isZeroV128(e->Iex.Binop.arg1)) {
// e2 = e->Iex.Binop.arg2;
// break;
//}
} else {
/* Xor8/16/32/64(0,t) ==> t */
if (isZeroU(e->Iex.Binop.arg1)) { // <=== arriving here
BANG. isZeroU cannot handle Iop_XorV256 hence the assert.
This patch is likely going to fix it (still testing):
Index: VEX/priv/ir_opt.c
===
--- VEX/priv/ir_opt.c(revision 3206)
+++ VEX/priv/ir_opt.c(working copy)
@@ -2292,8 +2292,15 @@
e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
break;
}
+ /* XorV256(t,0) ==> t */
+ if (e->Iex.Binop.op == Iop_XorV256) {
+ if (isZeroV256(e->Iex.Binop.arg2)) {
+ e2 = e->Iex.Binop.arg1;
+ break;
+ }
+ }
/* XorV128(t,0) ==> t */
- if (e->Iex.Binop.op == Iop_XorV128) {
+ else if (e->Iex.Binop.op == Iop_XorV128) {
if (isZeroV128(e->Iex.Binop.arg2)) {
e2 = e->Iex.Binop.arg1;
break;
but the code is UGLY. Comments are out of date and the Boolean IRops And/Or/Xor
are handled differently. We really should keep as much code in common as
possible.
Extending isZeroU and isOneU to also handle V128 and V256 values makes sense to
me.Even if the function name then no longer exactly describes the set of
allowed values. Or we can change the function name as there are only aboout 10
invocations. So the ripple is acceptable IMHO.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 356393] valgrind (vex) crashes because isZeroU happened
https://bugs.kde.org/show_bug.cgi?id=356393 Florian Krohm changed: What|Removed |Added CC||flor...@eich-krohm.de --- Comment #4 from Florian Krohm --- (In reply to Darshit Shah from comment #0) > vex: the `impossible' happened: >isZeroU > vex storage: T total 983714392 bytes allocated > vex storage: P total 640 bytes allocated > > valgrind: the 'impossible' happened: >LibVEX called failure_exit(). > > host stacktrace: > ==16723==at 0x38083FA8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x380840C4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x38084301: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x3808432A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x3809F6C2: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x38148008: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x3815516D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x38159292: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x38159EC6: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x3815BDD8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x3815CE26: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x38145E0C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x380A1C4B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x380D295B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x380D45BF: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723==by 0x380E3936: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable (lwpid 16723) > ==16723==at 0x5EA6F40: ecp_nistz256_avx2_select_w7 (in > /usr/lib/libcrypto.so.1.0.0) > ==16723==by 0x5E765CF: EC_POINT_mul (in /usr/lib/libcrypto.so.1.0.0) > ==16723==by 0x5E75416: EC_POINT_new (in /usr/lib/libcrypto.so.1.0.0) > ==16723==by 0x5E7EE89: EC_KEY_generate_key (in > /usr/lib/libcrypto.so.1.0.0) > ==16723==by 0x5B422A4: ssl3_send_client_key_exchange (in > /usr/lib/libssl.so.1.0.0) > ==16723==by 0x5B45F67: ssl3_connect (in /usr/lib/libssl.so.1.0.0) > ==16723==by 0x5B50E9B: ssl23_connect (in /usr/lib/libssl.so.1.0.0) > ==16723==by 0x452B2F: ssl_connect_with_timeout_callback (openssl.c:506) > ==16723==by 0x44DDF3: run_with_timeout (utils.c:2046) > ==16723==by 0x4529A9: ssl_connect_wget (openssl.c:559) > ==16723==by 0x429A0F: establish_connection (http.c:2144) > ==16723==by 0x425BAE: gethttp (http.c:3055) > ==16723==by 0x4243C5: http_loop (http.c:3971) > ==16723==by 0x43FE0E: retrieve_url (retr.c:817) > ==16723==by 0x4365C2: main (main.c:1868) > > Valgrind crashed with the following message when trying to test GNU Wget. > The issue is triggered only by two specific tests that require Wget to > connect to a proxy server over HTTPS. It does not happen during normal > connections to HTTPS servers. Also, the issue occurs only when compiled with > OpenSSL. With GnuTLS there are no problems. > > P.S.: I'm using Valgrind 3.11 on Arch Linux. The version option is not > available in the form. The issue seems to be a regression since it doesn't > come up on an older version (3.7.0) during the CI builds on Travis. > > Reproducible: Always > > Steps to Reproduce: > 1. git clone http://git.savannah.gnu.org/r/wget.git > 2. cd wget > 3. ./bootstrap && ./configure --enable-valgrind-tests --with-ssl=openssl > 4. make check > > Actual Results: > The output present above I just built wget according those instructions on my x86-64. With stock valgrind 3.11.0 I do not get any errors: Testsuite summary for wget 1.17.1.11-b305 # TOTAL: 85 # PASS: 71 # SKIP: 14 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 and Testsuite summary for wget 1.17.1.11-b305 # TOTAL: 28 # PASS: 28 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Perhaps it's one of those skipped tests that is failing: SKIP: Test-ftp-iri.px SKIP: Test-ftp-iri-fallback.px SKIP: Test-ftp-iri-recursive.px SKIP: Test-ftp-iri-disabled.px SKIP: Test-idn-headers.px SKIP: Test-idn-meta.px SKIP: Test-idn-cmd.px SKIP: Test-idn-cmd-utf8.px SKIP: Test-idn-robots.px SKIP: Test-idn-robots-utf8.px SKIP: Test-iri.px SKIP: Test-iri-percent.px SKIP: Test-iri-forced-remote.px SKIP: Test-iri-list.px If it's one of these that is failin
[valgrind] [Bug 356817] valgrind.h triggers compiler errors on MSVC when defining NVALGRIND
https://bugs.kde.org/show_bug.cgi?id=356817 Florian Krohm changed: What|Removed |Added CC||flor...@eich-krohm.de Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Florian Krohm --- Fixed in r15762. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357887] Calls to VG_(fclose) does not close the file descriptor
https://bugs.kde.org/show_bug.cgi?id=357887 Florian Krohm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||flor...@eich-krohm.de --- Comment #1 from Florian Krohm --- (In reply to Nicolas Vienne from comment #0) > I'm using Valgrind 3.11.0 built from sources on Ubuntu x86. > While redirecting lackey's logs to files, I noticed that file descriptors > remained opened even after calling the method void VG_(fclose)( VgFile *fp ). > In that function, the "VG_(close)(fp->fd);" seems to be missing after > flushing the buffer. Oh yes, you're absolutely right. Thanks for reporting! I've fixed this in r15755. -- You are receiving this mail because: You are watching all bug changes.
