2016-09-24 3 views
6

나는 이런 식으로 뭔가 보이는 기능했습니다 -Valgrind의 : 주소에서 인식 할 수없는 명령 0x5111715

std::string func() 
{ 
    std::string result; 

    ... 

    auto seed = std::random_device()(); 
    std::mt19937 gen(seed); 
    std::uniform_int_distribution<> dis(0, 61); 

    ... 
    return result; 
} 

컴파일러의 다양성과 그 버전에서 잘 컴파일,하지만 여전히 우분투에 Valgrind의 테스트를 통과하지. 우분투가 아치 리눅스 설치가되어있는 내 컴퓨터에서 성공적으로 통과했기 때문에 우분투를 명시 적으로 언급했습니다.

두 valgrind 설치 버전은 모두 valgrind-3.11.0으로보고합니다. 유일한 차이점은 가상 머신이없는 내 컴퓨터에 아치 리눅스 설치가 있다는 것입니다. Ubuntu 테스트는 일종의 가상화가 적용되는 DO/CI 서버에서 수행되었습니다. 하지만 그게 중요할까요?

--- stderr --- 
==13849== Memcheck, a memory error detector 
==13849== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. 
==13849== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info 
==13849== Command: file/path/here 
==13849== 
vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF0 0x89 0x6 0xF 0x42 0xC1 
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=0F 
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 
==13849== valgrind: Unrecognised instruction at address 0x5111715. 
==13849== at 0x5111715: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22) 
==13849== by 0x51118B1: std::random_device::_M_getval() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22) 
==13849== by 0x4809FB: std::random_device::operator()() (random.h:1612) 
==13849== by 0x47F0C2: isaac::deviceList::genId[abi:cxx11](unsigned int) (deviceList.cpp:21) 
==13849== by 0x47F2A7: isaac::deviceList::place(isaac::deviceType, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator>) (deviceList.cpp:38) 
==13849== by 0x40D06E: DeviceList_place_Test::TestBody() (test.cpp:194) 
==13849== by 0x45D5A7: void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2078) 
==13849== by 0x4588D2: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2114) 
==13849== by 0x43EBB3: testing::Test::Run() (gtest.cc:2151) 
==13849== by 0x43F3F5: testing::TestInfo::Run() (gtest.cc:2326) 
==13849== by 0x43FA52: testing::TestCase::Run() (gtest.cc:2444) 
==13849== by 0x446911: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4315) 
==13849== Your program just tried to execute an instruction that Valgrind 
==13849== did not recognise. There are two possible reasons for this. 
==13849== 1. Your program has a bug and erroneously jumped to a non-code 
==13849== location. If you are running Memcheck and you just saw a 
==13849== warning about a bad jump, it's probably your program's fault. 
==13849== 2. The instruction is legitimate but Valgrind doesn't handle it, 
==13849== i.e. it's Valgrind's fault. If you think this is the case or 
==13849== you are not sure, please let us know and we'll try to fix it. 
==13849== Either way, Valgrind will now raise a SIGILL signal which will 
==13849== probably kill your program. 
==13849== 
==13849== Process terminating with default action of signal 4 (SIGILL): dumping core 
==13849== Illegal opcode at address 0x5111715 
==13849== at 0x5111715: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22) 
==13849== by 0x51118B1: std::random_device::_M_getval() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22) 
==13849== by 0x4809FB: std::random_device::operator()() (random.h:1612) 
==13849== by 0x47F0C2: isaac::deviceList::genId[abi:cxx11](unsigned int) (deviceList.cpp:21) 
==13849== by 0x47F2A7: isaac::deviceList::place(isaac::deviceType, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator>) (deviceList.cpp:38) 
==13849== by 0x40D06E: DeviceList_place_Test::TestBody() (test.cpp:194) 
==13849== by 0x45D5A7: void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2078) 
==13849== by 0x4588D2: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2114) 
==13849== by 0x43EBB3: testing::Test::Run() (gtest.cc:2151) 
==13849== by 0x43F3F5: testing::TestInfo::Run() (gtest.cc:2326) 
==13849== by 0x43FA52: testing::TestCase::Run() (gtest.cc:2444) 
==13849== by 0x446911: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4315) 
==13849== 
==13849== HEAP SUMMARY: 
==13849==  in use at exit: 84,300 bytes in 108 blocks 
==13849== total heap usage: 622 allocs, 514 frees, 530,112 bytes allocated 
==13849== 
==13849== LEAK SUMMARY: 
==13849== definitely lost: 0 bytes in 0 blocks 
==13849== indirectly lost: 0 bytes in 0 blocks 
==13849==  possibly lost: 0 bytes in 0 blocks 
==13849== still reachable: 84,300 bytes in 108 blocks 
==13849==   suppressed: 0 bytes in 0 blocks 
==13849== Rerun with --leak-check=full to see details of leaked memory 
==13849== 
==13849== For counts of detected and suppressed errors, rerun with: -v 
==13849== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 
------- 

편집 - - 여기


는 Valgrind의 실행에 대한 로그입니다 내가 수동으로 공식 소스에서 Valgrind의 구축과 설치를 시도했습니다,하지만 여전히 같은 오류가 발생합니다.

+1

우분투 컴퓨터에서 어떤 컴파일러 플래그를 사용 했습니까? 분명히 컴파일러는 불법적 인 명령어를 생성하고 있습니다. 우분투 컴퓨터에서'/ proc/cpuinfo'의 결과는 무엇입니까? –

+0

@MartinNyolt 두 빌드 모두 우분투'/ proc/cpuinfo'를 가지고 있습니다 - https://gist.github.com/agauniyal/c8d57b106097a16296b259b86fc93368 –

+1

그러나 * 정확히 * 플래그는 무엇입니까? 나는 * 왜 * 귀하의 컴파일러가 불법적 인 지시를 내리는 지 알아 내도록 도와 드리고 있습니다. 코드를 디버그하고 실행하려고하는 * 명령을 확인 했습니까? valgrind 중에 만 오류가 발생합니까? 아니면 정상 실행 중에도 SIGILL이 표시됩니까? –

답변

3

귀하의 Ubuntu 시스템에 사용자의 Valgrind 버전이 인식하지 못하는 RDRAND 명령어 (opcode 0x0f 0xc7)를 사용하는 난수 라이브러리가있는 것 같습니다. Arch 시스템은 분명히이 지침을 사용하지 않는 다른 구현을 사용합니다.

pre-Ivy Bridge CPU 용으로 다시 컴파일하면이 문제를 해결할 수 있습니다.

+0

내 시스템에서 컴파일 할 때처럼 다시 컴파일하십시오. CI 빌드에서이 바이너리를 다운로드하고 그것에 valgrind를 실행 하시겠습니까? –

+1

지시 사항이 libstdC++ 라이브러리에있는 것처럼 보입니다. 다시 컴파일해야 할 수도 있습니다.또한 이것이 valgrind와 관련된 알려진 문제인지 여부를 확인하고 수정해야 할 패치가 있는지 확인할 수 있습니다. –

+0

흠, 대신 정적으로 링크 할 수 없습니까? libstdC++ 라이브러리를 재 컴파일하는 것이 나에게있어 당연한 일은 아닌 것 같다 : p –

7

https://bugs.kde.org/show_bug.cgi?id=353370을 참조하십시오.

마지막 svn 버전 가져 오기/컴파일로이 문제가 해결됩니다.

만약 그렇지 않다면, 곧 릴리스 될 3.12 버전이 출시 될 것이므로 bugzilla에보고 해주십시오. 감사합니다.

+1

코멘트를 깜빡했으나 내 문제를 해결했습니다. :) –

관련 문제