LINUX.ORG.RU

Некорректное поведение valgrind в Gentoo

 ,


0

2

Всем привет!
Эта тема была уже неоднократно прожёвана, однако ответы на неё разнятся, а сама суть по-прежнему проявляется. А суть в том, что valgrind сегфолтится(!) даже на простейшем хелловорлде.

ecko@localhost ~/develop $ cat test.c 
#include <stdio.h>

int main(void)
{
	int m = 5;
	printf("m=%d\n", m);
	return 0;
}

ecko@localhost ~/develop $ valgrind --leak-check=yes ./test
==17113== Memcheck, a memory error detector
==17113== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17113== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==17113== Command: ./test
==17113== 
vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xCE 0x3 0x1D 0x0
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.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==17113== valgrind: Unrecognised instruction at address 0x4011616.
==17113==    at 0x4011616: _dl_allocate_tls_storage (dl-tls.c:353)
==17113==    by 0x40010FF: init_tls (rtld.c:765)
==17113==    by 0x4003D3D: dl_main (rtld.c:1816)
==17113==    by 0x401543F: _dl_sysdep_start (dl-sysdep.c:249)
==17113==    by 0x4004C93: _dl_start (rtld.c:331)
==17113==    by 0x4001407: ??? (in /lib64/ld-2.19.so)
==17113== Your program just tried to execute an instruction that Valgrind
==17113== did not recognise.  There are two possible reasons for this.
==17113== 1. Your program has a bug and erroneously jumped to a non-code
==17113==    location.  If you are running Memcheck and you just saw a
==17113==    warning about a bad jump, it's probably your program's fault.
==17113== 2. The instruction is legitimate but Valgrind doesn't handle it,
==17113==    i.e. it's Valgrind's fault.  If you think this is the case or
==17113==    you are not sure, please let us know and we'll try to fix it.
==17113== Either way, Valgrind will now raise a SIGILL signal which will
==17113== probably kill your program.
==17113== 
==17113== Process terminating with default action of signal 4 (SIGILL)
==17113==  Illegal opcode at address 0x4011616
==17113==    at 0x4011616: _dl_allocate_tls_storage (dl-tls.c:353)
==17113==    by 0x40010FF: init_tls (rtld.c:765)
==17113==    by 0x4003D3D: dl_main (rtld.c:1816)
==17113==    by 0x401543F: _dl_sysdep_start (dl-sysdep.c:249)
==17113==    by 0x4004C93: _dl_start (rtld.c:331)
==17113==    by 0x4001407: ??? (in /lib64/ld-2.19.so)
==17113== Jump to the invalid address stated on the next line
==17113==    at 0x626: ???
==17113==  Address 0x626 is not stack'd, malloc'd or (recently) free'd
==17113== 
==17113== 
==17113== Process terminating with default action of signal 11 (SIGSEGV)
==17113==  Bad permissions for mapped region at address 0x626
==17113==    at 0x626: ???
==17113== 
==17113== HEAP SUMMARY:
==17113==     in use at exit: 0 bytes in 0 blocks
==17113==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17113== 
==17113== All heap blocks were freed -- no leaks are possible
==17113== 
==17113== For counts of detected and suppressed errors, rerun with: -v
==17113== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
Ошибка сегментирования

Конфиги здесь:

ecko@localhost /etc/portage $ cat package.env 
## Offtop skipped ##
sys-devel/gcc no-tmpfs.conf splitdebug.conf
sys-libs/glibc splitdebug.conf

ecko@localhost /etc/portage $ cat env/splitdebug.conf 
CFLAGS="${CFLAGS} -ggdb"
FEATURES="splitdebug"

Кто-нибудь, объясните, пожалуйста, внятно, что я здесь сделал не так! Заранее спасибо!

Deleted

Ответ на: комментарий от anonymous

Разумеется, без него всё хорошо.

ecko@localhost ~/develop $ ./test
m=5

Deleted
()
Ответ на: комментарий от anonymous
ecko@localhost ~/develop $ cat /etc/portage/make.conf | grep CFLAGS
CFLAGS="-march=native -O2 -pipe -msse4.2 -mcx16 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048"
CXXFLAGS="${CFLAGS}"
Deleted
()
Ответ на: комментарий от anonymous

Чёрт! Кажется, этот момент я упустил из виду. Спасибо! Попробую пересобрать — отпишусь.

Deleted
()
Ответ на: комментарий от Deleted

А какой процессор (вывод lscpu или cat /proc/cpuinfo)?

Кстати, при указанном march=native, вот это лишнее: -mcx16 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048.

backbone ★★★★★
()
Ответ на: комментарий от backbone

К сожалению, пока что на вопросы я смогу ответить только после 22:00.

Deleted
()
Ответ на: комментарий от anonymous

Увы, это не помогло.

ecko@peka ~ $ cat /etc/portage/env/splitdebug.conf 
CFLAGS="-march=native -O2 -pipe -ggdb"
FEATURES="splitdebug"
С этим конфигом получаю ту же ошибку.

Deleted
()
Ответ на: комментарий от backbone
ecko@peka ~ $ cat /proc/cpuinfo | head -n 26
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 16
model name	: AMD A10-4600M APU with Radeon(tm) HD Graphics
stepping	: 1
microcode	: 0x6001116
cpu MHz		: 2300.000
cache size	: 2048 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 16
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1
bogomips	: 4591.59
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro
ecko@peka ~ $ lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 16
Model name:            AMD A10-4600M APU with Radeon(tm) HD Graphics
Stepping:              1
CPU MHz:               2300.000
CPU max MHz:           2300,0000
CPU min MHz:           1400,0000
BogoMIPS:              4591.59
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             64K
L2 cache:              2048K
NUMA node0 CPU(s):     0-3
Deleted
()

у меня на твоём примере вообще вон что:

$ valgrind --leak-check=yes ./test.c
==6557== Memcheck, a memory error detector
==6557== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6557== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==6557== Command: ./test.c
==6557== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.
anonymous
()
Ответ на: комментарий от anonymous

у меня на твоём примере вообще вон что:

glibc собрана без отладочной инфы.

Lavos ★★★★★
()

У меня все ок, брат жив:

$ gcc -O2 -ggdb -march=native test.c -o test
$ valgrind --leak-check=yes ./test
==8721== Memcheck, a memory error detector
==8721== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8721== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==8721== Command: ./test
==8721==
m=5
==8721==
==8721== HEAP SUMMARY:
==8721==     in use at exit: 0 bytes in 0 blocks
==8721==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==8721==
==8721== All heap blocks were freed -- no leaks are possible
==8721==
==8721== For counts of detected and suppressed errors, rerun with: -v
==8721== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
$ grep -i cflags /etc/portage/make.conf
CFLAGS="-march=native -O2 -fomit-frame-pointer -pipe -ggdb"
CXXFLAGS="${CFLAGS}"
$ equery l valgrind ; equery l glibc ; equery l gcc
[IP-] [  ] dev-util/valgrind-3.9.0:0
[IP-] [  ] sys-libs/glibc-2.19-r1:2.2
[IP-] [  ] sys-devel/gcc-4.8.3:4.8

Lavos ★★★★★
()
Ответ на: комментарий от Deleted

Баг в багзилле похожий. Я бы зарегистрировался там и подтвердил, чтобы быстрее дело пошло.

Хотя найдётся один анонимус, который скажет, что я упорот, в остальном, даже такие флаги относительно безопасны:

CFLAGS="-O2 -pipe -march=native -msse4.2 -mavx -maes -mpclmul
USE="3dnow 3dnowext fpu mmx mmxext smp sse sse2 sse3 ssse3 sse4a sse4 sse41 sse4_1 sse42 sse4_2"

backbone ★★★★★
()
Последнее исправление: backbone (всего исправлений: 1)
Ответ на: комментарий от backbone

А почему именно в кедовом багтреккере? О_о и мне интересно было бы услышать Pinkbyte по этому поводу. Вдруг я действительно пропустил что-то очень глупое?

Deleted
()
Ответ на: комментарий от Deleted

К сожалению я не настолько знаток как потрохов valgrind-а, так и особенностей тонких оптимизационных флагов в gcc. В код я не смотрел(да и сомневаюсь что смог бы с наскоку понять в чём там проблема).

Так что, простите, но я пас.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от backbone

твои «даже такие» флаги всего-то разрешают gcc использовать инструкции (зачем, при -march=native?), те gcc не отвалится с ошибкой при попытке собрать ассемблерные вставки или использованные разработчиками intrinsics

и юзы, опять же включающие ассемблерные вставки от разработчиков софта, конечно это безопасно

для «даже такого» добавь -ftree-vectorize или -O3

anonymous
()
Ответ на: комментарий от Deleted

А почему именно в кедовом багтреккере?

А бог его знает, может это как-то связано с KCacheGrind - суперклассной штукой, которая написана под кеды и использует Valgrind...

backbone ★★★★★
()
Ответ на: комментарий от anonymous

твои «даже такие» флаги всего-то разрешают gcc использовать инструкции (зачем, при -march=native?), те gcc не отвалится с ошибкой при попытке собрать ассемблерные вставки или использованные разработчиками intrinsics

Gcc не отвалится, главное, чтобы эти вставки не отвалились потом.

зачем, при -march=native?

-march=native не включает sse4.2. Или зачем USE? Иногда CFLAGS могут быть переопределены в ebuilde.

и юзы, опять же включающие ассемблерные вставки от разработчиков софта, конечно это безопасно

Значит Вы - не тот Анонимус, который будет утверждать, что у разработчика может быть иная версия Gcc, что USE мог быть добавлен мэнтэйнером ebuild-а и т.п.

для «даже такого» добавь -ftree-vectorize или -O3

Вы знаете, что эти флаги ломают sed, xz-utils и что-то ещё...

backbone ★★★★★
()
Ответ на: комментарий от Lavos

Может быть, проблема действительно в процессоре? У меня разве что -fomit-frame-pointer не выставлен, но он автоматически включается с -O2. Ну, и версия gcc другая. Не уверен, что проблема может быть в этом. UPD: ну да, проблема явно не в гцц, ибо с этим же тестом, собранным шлангом, я получаю всё ту же ошибку сегментирования.

Deleted
()
Последнее исправление: ecko (всего исправлений: 1)
Ответ на: комментарий от backbone

Gcc не отвалится

да ты же сертифицированный gentoo спец

#include<iostream>
#include<immintrin.h>

int main(){
  volatile __m128i a={2,2};
  __m128i c=_mm_add_epi8(a,a);

  std::cerr<<sizeof c<<' '<<c[0]<<' '<<c[1]<<std::endl;}

$ g++ test.cc&& ./a.out
16 4 4

$ g++ test.cc -mno-sse2
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/xmmintrin.h:1258:0,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/immintrin.h:29,
                 from test.cc:32:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/emmintrin.h: In function 'int main()':
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/emmintrin.h:1007:1: error: inlining failed in call to always_inline '__m128i _mm_add_epi8(__m128i, __m128i)': target specific option mismatch
 _mm_add_epi8 (__m128i __A, __m128i __B)
 ^
test.cc:36:29: error: called from here
   __m128i c=_mm_add_epi8(a,a);

главное, чтобы эти вставки не отвалились потом

схрена они отвалятся?

-march=native не включает sse4.2

а в процессоре оно у тебя есть?

что у разработчика может быть иная версия Gcc

и на что это повлияет, по твоему

USE мог быть добавлен мэнтэйнером

от добавления юза sse99 avx99 код для их поддержки не напишется

Вы знаете, что эти флаги ломают

ну и что, ты же хочешь «зачётных оптимизаций»

anonymous
()
Ответ на: комментарий от anonymous

да ты же сертифицированный gentoo спец

Спасибо. Ошибка сборки - это не проблема по сравнению с ошибкой в runtime.

схрена они отвалятся?

Если процессор не поддерживает этих инструкций или есть ошибки в Gcc.

а в процессоре оно у тебя есть?

У ТС есть.

и на что это повлияет, по твоему

В разных версиях Gcc разные баги же.

от добавления юза sse99 avx99 код для их поддержки не напишется

Может быть, но даже обычный strcmp при включенных оптимизациях раскладывается в инструкции sse2, в том же Valgrind это можно увидеть.

ну и что, ты же хочешь «зачётных оптимизаций»

Ваше предположение ошибочно, стабильность меня волнует больше.

Я пишу не со зла, не принимайте близко к сердцу.

backbone ★★★★★
()
Ответ на: комментарий от backbone

обычный strcmp находится в glibc, которая детектит simd по cpuid и подставляет оптимизированные реализации

anonymous
()
Ответ на: комментарий от anonymous

Убейте, не вижу:

 18 #include <string.h>
 19 #include <memcopy.h>
 20
 21 #undef strcmp
 22
 23 /* Compare S1 and S2, returning less than, equal to or
 24    greater than zero if S1 is lexicographically less than,
 25    equal to or greater than S2.  */
 26 int
 27 strcmp (p1, p2)
 28      const char *p1;
 29      const char *p2;
 30 {
 31   const unsigned char *s1 = (const unsigned char *) p1;
 32   const unsigned char *s2 = (const unsigned char *) p2;
 33   unsigned char c1, c2;
 34
 35   do
 36     {
 37       c1 = (unsigned char) *s1++;
 38       c2 = (unsigned char) *s2++;
 39       if (c1 == '\0')
 40     return c1 - c2;
 41     }
 42   while (c1 == c2);
 43
 44   return c1 - c2;
 45 }
 46 libc_hidden_builtin_def (strcmp)    
(не говорю, что вы не правы, просто не найду, где, интересно)

Up. Вижу, sysdeps/x86_64/multiarch/strcmp-sse42.S, спасибо.

backbone ★★★★★
()
Последнее исправление: backbone (всего исправлений: 3)
Ответ на: комментарий от backbone

убиваю

$ find glibc-2.19 -name *strcmp*.S |sort
glibc-2.19/ports/sysdeps/aarch64/strcmp.S
glibc-2.19/ports/sysdeps/alpha/strcmp.S
glibc-2.19/ports/sysdeps/ia64/strcmp.S
glibc-2.19/sysdeps/i386/i686/multiarch/strcmp.S
glibc-2.19/sysdeps/i386/i686/multiarch/strcmp-sse4.S
glibc-2.19/sysdeps/i386/i686/multiarch/strcmp-ssse3.S
glibc-2.19/sysdeps/i386/i686/strcmp.S
glibc-2.19/sysdeps/powerpc/powerpc32/405/strcmp.S
glibc-2.19/sysdeps/powerpc/powerpc32/strcmp.S
glibc-2.19/sysdeps/powerpc/powerpc64/strcmp.S
glibc-2.19/sysdeps/s390/s390-32/strcmp.S
glibc-2.19/sysdeps/s390/s390-64/strcmp.S
glibc-2.19/sysdeps/sparc/sparc32/sparcv9/strcmp.S
glibc-2.19/sysdeps/sparc/sparc32/strcmp.S
glibc-2.19/sysdeps/sparc/sparc64/strcmp.S
glibc-2.19/sysdeps/x86_64/multiarch/strcmp.S
glibc-2.19/sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S
glibc-2.19/sysdeps/x86_64/multiarch/strcmp-sse42.S
glibc-2.19/sysdeps/x86_64/multiarch/strcmp-ssse3.S
glibc-2.19/sysdeps/x86_64/strcmp.S

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.