По какой-то причине мой valgrind не печатает номер строки и файл, в котором происходит ошибка.Это происходит в дистрибутиве Linux Ubuntu 16.04.4.
Вот как я его протестировал:
/ tmp / ac:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int main(int argc, char **argv)
{
char *buf = malloc(10);
strcpy(buf, argv[1]);
return 0;
}
Я выполнил все это сследующая команда: cd /tmp && gcc a.c -o hello -fno-stack-protector -fno-builtin -g && valgrind ./hello
$ cd /tmp && gcc a.c -o hello -fno-stack-protector -fno-builtin -g && valgrind ./hello ./hello
==23422== Memcheck, a memory error detector
==23422== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23422== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23422== Command: ./hello
==23422==
==23422== Invalid read of size 1
==23422== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23422== by 0x40119C: ??? (in /tmp/hello)
==23422== by 0x4E5A82F: (below main) (libc-start.c:291)
==23422== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23422==
==23422==
==23422== Process terminating with default action of signal 11 (SIGSEGV)
==23422== Access not within mapped region at address 0x0
==23422== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23422== by 0x40119C: ??? (in /tmp/hello)
==23422== by 0x4E5A82F: (below main) (libc-start.c:291)
==23422== If you believe this happened as a result of a stack
==23422== overflow in your program's main thread (unlikely but
==23422== possible), you can try to increase the size of the
==23422== main thread stack using the --main-stacksize= flag.
==23422== The main thread stack size used in this run was 8388608.
==23422==
==23422== HEAP SUMMARY:
==23422== in use at exit: 10 bytes in 1 blocks
==23422== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==23422==
==23422== LEAK SUMMARY:
==23422== definitely lost: 0 bytes in 0 blocks
==23422== indirectly lost: 0 bytes in 0 blocks
==23422== possibly lost: 0 bytes in 0 blocks
==23422== still reachable: 10 bytes in 1 blocks
==23422== suppressed: 0 bytes in 0 blocks
==23422== Rerun with --leak-check=full to see details of leaked memory
==23422==
==23422== For counts of detected and suppressed errors, rerun with: -v
==23422== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
Версия GCC: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) Версия Valgrind: valgrind-3.11.0
Я также пытался загрузить и скомпилировать последнюю версию valgrind (valgrind-3.13.0), нозакончилась той же проблемой.
РЕДАКТИРОВАТЬ:
Вывод с полными журналами:
$ valgrind -v --leak-check=full /tmp/a.out
==17717== Memcheck, a memory error detector
==17717== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17717== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17717== Command: /tmp/a.out
==17717==
--17717-- Valgrind options:
--17717-- -v
--17717-- --leak-check=full
--17717-- Contents of /proc/version:
--17717-- Linux version 4.4.0-119-generic (buildd@lcy01-amd64-013) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) ) #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018
--17717--
--17717-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--17717-- Page sizes: currently 4096, max supported 4096
--17717-- Valgrind library directory: /usr/lib/valgrind
--17717-- Reading syms from /tmp/a.out
--17717-- ELF section outside all mapped regions
--17717-- Reading syms from /lib/x86_64-linux-gnu/ld-2.23.so
--17717-- Considering /lib/x86_64-linux-gnu/ld-2.23.so ..
--17717-- .. CRC mismatch (computed aa979a42 wanted 9019bbb7)
--17717-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so ..
--17717-- .. CRC is valid
--17717-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--17717-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--17717-- .. CRC mismatch (computed eea41ea9 wanted 2009db78)
--17717-- object doesn't have a symbol table
--17717-- object doesn't have a dynamic symbol table
--17717-- Scheduler: using generic scheduler lock implementation.
--17717-- Reading suppressions file: /usr/lib/valgrind/default.supp
==17717== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-17717-by-rajiska-on-???
==17717== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-17717-by-rajiska-on-???
==17717== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-17717-by-rajiska-on-???
==17717==
==17717== TO CONTROL THIS PROCESS USING vgdb (which you probably
==17717== don't want to do, unless you know exactly what you're doing,
==17717== or are doing some strange experiment):
==17717== /usr/lib/valgrind/../../bin/vgdb --pid=17717 ...command...
==17717==
==17717== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==17717== /path/to/gdb /tmp/a.out
==17717== and then give GDB the following command
==17717== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=17717
==17717== --pid is optional if only one valgrind process is running
==17717==
--17717-- REDIR: 0x401cfd0 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e181 (???)
--17717-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--17717-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--17717-- .. CRC mismatch (computed 2567ccf6 wanted 49420590)
--17717-- object doesn't have a symbol table
--17717-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--17717-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--17717-- .. CRC mismatch (computed 0e27c9a8 wanted ac585421)
--17717-- object doesn't have a symbol table
==17717== WARNING: new redirection conflicts with existing -- ignoring it
--17717-- old: 0x0401cfd0 (strlen ) R-> (0000.0) 0x3809e181 ???
--17717-- new: 0x0401cfd0 (strlen ) R-> (2007.0) 0x04c31020 strlen
--17717-- REDIR: 0x401b920 (ld-linux-x86-64.so.2:index) redirected to 0x4c30bc0 (index)
--17717-- REDIR: 0x401bb40 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c320d0 (strcmp)
--17717-- REDIR: 0x401dd30 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35270 (mempcpy)
--17717-- Reading syms from /lib/x86_64-linux-gnu/libc-2.23.so
--17717-- Considering /lib/x86_64-linux-gnu/libc-2.23.so ..
--17717-- .. CRC mismatch (computed 7a8ee3e4 wanted a5190ac4)
--17717-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so ..
--17717-- .. CRC is valid
--17717-- REDIR: 0x4ec9a00 (libc.so.6:strcasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec5280 (libc.so.6:strcspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ecbcf0 (libc.so.6:strncasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec76f0 (libc.so.6:strpbrk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec7a80 (libc.so.6:strspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec914b (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec7400 (libc.so.6:rindex) redirected to 0x4c308a0 (rindex)
--17717-- REDIR: 0x4ebe130 (libc.so.6:malloc) redirected to 0x4c2db20 (malloc)
--17717-- REDIR: 0x4ec5160 (libc.so.6:strcpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4edf9d0 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c31040 (strcpy)
==17717== Invalid read of size 1
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17717==
==17717==
==17717== Process terminating with default action of signal 11 (SIGSEGV)
==17717== Access not within mapped region at address 0x0
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== If you believe this happened as a result of a stack
==17717== overflow in your program's main thread (unlikely but
==17717== possible), you can try to increase the size of the
==17717== main thread stack using the --main-stacksize= flag.
==17717== The main thread stack size used in this run was 8388608.
--17717-- REDIR: 0x4ebe4f0 (libc.so.6:free) redirected to 0x4c2ed80 (free)
==17717==
==17717== HEAP SUMMARY:
==17717== in use at exit: 10 bytes in 1 blocks
==17717== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==17717==
==17717== Searching for pointers to 1 not-freed blocks
==17717== Checked 62,704 bytes
==17717==
==17717== LEAK SUMMARY:
==17717== definitely lost: 0 bytes in 0 blocks
==17717== indirectly lost: 0 bytes in 0 blocks
==17717== possibly lost: 0 bytes in 0 blocks
==17717== still reachable: 10 bytes in 1 blocks
==17717== suppressed: 0 bytes in 0 blocks
==17717== Reachable blocks (those to which a pointer was found) are not shown.
==17717== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17717==
==17717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==17717==
==17717== 1 errors in context 1 of 1:
==17717== Invalid read of size 1
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17717==
==17717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
РЕДАКТИРОВАТЬ 2: После тестирования двоичного файла, скомпилированного в моей системе в системе Docker,кажется, что проблема та же самая, что приводит к мысли, что проблема заключается в самом бинарном файле.Компиляция с GCC системы Docker прекрасно работает с valgrind.
EDIT 3: Просто скомпилируйте последнюю версию GCC (8.1.0) и попытайтесь скомпилировать программу с ней: та же проблема.Кроме того, вы можете заметить, что valgrind не может разрешить функцию, в которой возникает проблема, даже если исполняемый файл не является чередованным.
Кроме того, в команде valgrind -v мы можем увидеть примечание ELF section outside all mapped regionsпри чтении символов исполняемого файла.
Я немного заблудился, похоже, что это не от GCC или Valgrind.Может быть, какая-то конфигурация системы?