|
From: Emmanuel R. <emm...@er...> - 2017-10-26 14:19:40
Attachments:
test.c
|
Hi all,
I'm having an issue running a application under valgrind.
The application runs fine without it, but some code has a different
behaviour with valgrind.
I've managed to track and isolate the issue to the following piece (full
example is attached as test.c) :
//work4 = 0x e2 e3 d9
// S T R
if((offset = strspn((char*)work4, alphanumericOrNational)) !=
(unsigned) tulen - 1){
printf("name+%d character 0x%.2X is not alphanumeric or
national\n", offset + 1, work4[offset]);
}
else
{
printf("Ok.\n");
}
(it's ebcdic characters).
I upgrade to the latest but i had the same issue in an older version :
[user@vm01 valgrind]$ valgrind --version
valgrind-3.13.0
If i'm using GCC :
[user@vm01 valgrind]$ gcc test.c -o test
[user@vm01 valgrind]$ ./test
0xe2e3d9
Ok.
Offset = 3
[user@vm01 valgrind]$ valgrind ./test
==23848== Memcheck, a memory error detector
==23848== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et
al.
==23848== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
info
==23848== Command: ./test
==23848==
0xe2e3d9
name+1 character 0xE2 is not alphanumeric or national
Offset = 0
==23848==
==23848== HEAP SUMMARY:
==23848== in use at exit: 0 bytes in 0 blocks
==23848== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==23848==
==23848== All heap blocks were freed -- no leaks are possible
==23848==
==23848== For counts of detected and suppressed errors, rerun with: -v
==23848== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[user@vm01 valgrind]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto
--enable-plugin --enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
Same thing with clang :
[user@vm01 valgrind]$ clang test.c -o test
[user@vm01 valgrind]$ ./test
0xe2e3d9
Ok.
Offset = 3
[user@vm01 valgrind]$ valgrind ./test
==27955== Memcheck, a memory error detector
==27955== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et
al.
==27955== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
info
==27955== Command: ./test
==27955==
0xe2e3d9
name+1 character 0xE2 is not alphanumeric or national
Offset = 0
==27955==
==27955== HEAP SUMMARY:
==27955== in use at exit: 0 bytes in 0 blocks
==27955== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==27955==
==27955== All heap blocks were freed -- no leaks are possible
==27955==
==27955== For counts of detected and suppressed errors, rerun with: -v
==27955== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[user@vm01 valgrind]$ clang --version
clang version 3.8.0 (http://llvm.org/git/clang.git
81e96a3d20c4d1c3bdc6fdbc2a800d11f7347c7e) (http://llvm.org/git/llvm.git
f5ab7a4dbb3061b17b6cc010e6b5fa802e913a52)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
I dont understand the change in behaviour due to valgrind. Is this a
known issue or a bug?
Thanks!
Emmanuel Reynard
|
|
From: Philippe W. <phi...@sk...> - 2017-10-26 19:01:24
|
> I dont understand the change in behaviour due to valgrind. Is this a > known issue or a bug? This is a bug in the strspn replacement, used a.o. by memcheck, helgrind, ... I fixed it in commit c1eace647ca4f670ef9bec0d0fe72cdd25a96394 Now, your small test case works similarly with or without valgrind. You might get and compile the last git version, and double check it all works ok for you now. (I still have to add a test case for this, to be done in a follow-up) Thanks for the analysis/bug reproduction/small test case : this all helps a lot. Philippe |