SUMMARY *** vex x86->IR: unhandled instruction bytes: 0xFB 0xFF 0xFF 0x8B Memcheck: the 'impossible' happened: memcheck:isAlwaysDefd:partial overlap host stacktrace: ==8958== at 0x5803C91F: ??? (in /usr/test/libexec/valgrind/memcheck-x86-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 8958) ==8958== at 0x44FC835: sessmgr_pgw_handle_new_call (sessmgr_pgw.c:34924) < SNIP > ==8958== by 0xBB107F9: main (sn_main.c:464) client stack range: [0xFE897000 0xFEB19FFF] client SP: 0xFE898670 valgrind stack range: [0x82A7F000 0x82B7EFFF] top usage: 7392 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports I need to know what is the instruction for these opcodes "0xFB 0xFF 0xFF 0x8B" I would like to know how to fix this ? and workaround ? *** STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT Process Crash due to vex x86->IR: unhandled instruction bytes: 0xFB 0xFF 0xFF 0x8B EXPECTED RESULT No Crash SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Well 0xFB is STI which sets the interrupt flag to enable interrupts which is presumably a privileged instruction that a user mode program shouldn't be trying to use. It seems more likely that you've somehow jumped to a bogus address and are trying to execute something that isn't a valid instruction stream, or you have self modifying code that valgrind hasn't detected. Does --smc-check=all help at all?
Thank you Tom for your reply. I don't think we are using any kind of interrupt in the user program. The x86/IR unhandled instruction happens sometimes and not always. But I do see every time below message before going down. I am not getting what is wrong here. The system is 64bit kernel and 32-bit application running. The stack size of 8Kb Please give me some pointer to debug further. What is the below message mean? 1. ==9224== Warning: client switching stacks? SP change: 0xfee6836c --> 0xfec1dbc0 ==9224== to suppress, use: --max-stackframe=2402220 or greater 2. client stack range: [0xFEC1C000 0xFEE9EFFF] client SP: 0xFEC1D680 valgrind stack range: [0x82C41000 0x82D40FFF] top usage: 7392 of 1048576 ============================================================================ ==9224== Warning: client switching stacks? SP change: 0xfee6836c --> 0xfec1dbc0 ==9224== to suppress, use: --max-stackframe=2402220 or greater ==9224== Invalid write of size 4 ==9224== at 0x3637DDE: smgr_fsm_state_open (sessmgr_fsm.c:382) ==9224== by 0x3663AE5: smgr_callline_fsm (sessmgr_fsm.c:244) <-SNIP-> ==9224== by 0x7F59D27: egtpc_handle_gtp_message (egtpc_interface.c:3018) ==9224== Address 0xfec1dbcc is on thread 1's stack ==9224== in frame #0, created by smgr_fsm_state_open (sessmgr_fsm.c:382) Memcheck: the 'impossible' happened: memcheck:isAlwaysDefd:partial overlap host stacktrace: ==9224== at 0x5803C91F: ??? (in /usr/test/libexec/valgrind/memcheck-x86-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 9224) ==9224== at 0x44FC81B: sessmgr_pgw_handle_new_call (sessmgr_pgw.c:34926) ==9224== by 0x3638113: smgr_fsm_state_open (sessmgr_fsm.c:447) <-SNIP-> ==9224== by 0xBB107C9: main (sn_main.c:464) client stack range: [0xFEC1C000 0xFEE9EFFF] client SP: 0xFEC1D680 valgrind stack range: [0x82C41000 0x82D40FFF] top usage: 7392 of 1048576 ========================================================================
laas-setup:ssi# ps -ef | grep mem root 10037 6471 2 15:07 pts/0 00:01:00 /usr/test/bin/valgrind --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=12 -v --error-limit=no /usr/sbin/boxer laas-setup:ssi# cat /proc/10037/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 514939 514939 processes Max open files 8192 8192 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 514939 514939 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us laas-setup:ssi#
Well you've got an invalid write reported there so the first thing you should do is fix that - once an invalid write has happened the state of your program is undefined because something somewhere was been overwritten with something unintended. There's also an indication of something odd happening to your stack pointer - are you using some sort of user space threading to context switch? or creating very large arrays on the stack? Does adding the switch it suggested help?
Thank you Tom for the pointers. I will work on the fix invalid write.