Bug 395809 - Unrecognised instruction by std::random_device::_M_getval()
Summary: Unrecognised instruction by std::random_device::_M_getval()
Status: RESOLVED DUPLICATE of bug 353370
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.11.0
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-24 07:25 UTC by Mathias
Modified: 2018-06-24 08:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias 2018-06-24 07:25:58 UTC
Linux mathias 4.4.0-128-generic #154-Ubuntu SMP Fri May 25 14:15:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

==31421== Memcheck, a memory error detector
==31421== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==31421== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==31421== Command: ./bin/MiSQLTests
==31421== 
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
==31421== valgrind: Unrecognised instruction at address 0x5218335.
==31421==    at 0x5218335: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==31421==    by 0x52184D1: std::random_device::_M_getval() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==31421==    by 0x420BB4: RNG<int, std::uniform_int_distribution<int> >::RNG() (in /home/mathias/Bureau/Algo/MiSQLTests/bin/MiSQLTests)
==31421==    by 0x404384: _GLOBAL__sub_I_rng (in /home/mathias/Bureau/Algo/MiSQLTests/bin/MiSQLTests)
==31421==    by 0x429C5C: __libc_csu_init (in /home/mathias/Bureau/Algo/MiSQLTests/bin/MiSQLTests)
==31421==    by 0x5C437BE: (below main) (libc-start.c:247)
==31421== Your program just tried to execute an instruction that Valgrind
==31421== did not recognise.  There are two possible reasons for this.
==31421== 1. Your program has a bug and erroneously jumped to a non-code
==31421==    location.  If you are running Memcheck and you just saw a
==31421==    warning about a bad jump, it's probably your program's fault.
==31421== 2. The instruction is legitimate but Valgrind doesn't handle it,
==31421==    i.e. it's Valgrind's fault.  If you think this is the case or
==31421==    you are not sure, please let us know and we'll try to fix it.
==31421== Either way, Valgrind will now raise a SIGILL signal which will
==31421== probably kill your program.
==31421== 
==31421== Process terminating with default action of signal 4 (SIGILL)
==31421==  Illegal opcode at address 0x5218335
==31421==    at 0x5218335: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==31421==    by 0x52184D1: std::random_device::_M_getval() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==31421==    by 0x420BB4: RNG<int, std::uniform_int_distribution<int> >::RNG() (in /home/mathias/Bureau/Algo/MiSQLTests/bin/MiSQLTests)
==31421==    by 0x404384: _GLOBAL__sub_I_rng (in /home/mathias/Bureau/Algo/MiSQLTests/bin/MiSQLTests)
==31421==    by 0x429C5C: __libc_csu_init (in /home/mathias/Bureau/Algo/MiSQLTests/bin/MiSQLTests)
==31421==    by 0x5C437BE: (below main) (libc-start.c:247)
==31421== 
==31421== HEAP SUMMARY:
==31421==     in use at exit: 73,744 bytes in 2 blocks
==31421==   total heap usage: 2 allocs, 0 frees, 73,744 bytes allocated
==31421== 
==31421== LEAK SUMMARY:
==31421==    definitely lost: 0 bytes in 0 blocks
==31421==    indirectly lost: 0 bytes in 0 blocks
==31421==      possibly lost: 0 bytes in 0 blocks
==31421==    still reachable: 73,744 bytes in 2 blocks
==31421==         suppressed: 0 bytes in 0 blocks
==31421== Rerun with --leak-check=full to see details of leaked memory
==31421== 
==31421== For counts of detected and suppressed errors, rerun with: -v
==31421== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Instruction non permise (core dumped)
Comment 1 Mark Wielaard 2018-06-24 08:45:11 UTC

*** This bug has been marked as a duplicate of bug 353370 ***