Fatal Errors
In certain situations, the execution of the program can not be continued in a well-defined way. In ESP-IDF, these situations include:
- CPU Exceptions: Illegal Instruction, Load/Store Alignment Error, Load/Store Prohibited error, Double Exception.
- System level checks and safeguards:
- Interrupt watchdog timeout
- Task watchdog timeout (only fatal if CONFIG_ESP_TASK_WDT_PANIC is set)
- Cache access error
- Brownout detection event
- Stack overflow
- Stack smashing protection check
- Heap integrity check
- Undefined behavior sanitizer (UBSAN) checks
This guide explains the procedure used in ESP-IDF for handling these errors, and provides suggestions on troubleshooting the errors.
Panic Handler
Every error cause listed in the Overview will be handled by the panic handler.
The panic handler will start by printing the cause of the error to the console. For CPU exceptions, the message will be similar to
Guru Meditation Error: Core 0 panic'ed (IllegalInstruction). Exception was unhandled.
For some of the system level checks (interrupt watchdog, cache access error), the message will be similar to
Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed). Exception was unhandled.
In all cases, the error cause will be printed in parentheses. See Guru Meditation Errors for a list of possible error causes.
Subsequent behavior of the panic handler can be set using CONFIG_ESP_SYSTEM_PANIC configuration choice. The available options are:
- Print registers and reboot ( CONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT ) — default option. This will print register values at the point of the exception, print the backtrace, and restart the chip.
- Print registers and halt ( CONFIG_ESP_SYSTEM_PANIC_PRINT_HALT ) Similar to the above option, but halt instead of rebooting. External reset is required to restart the program.
- Silent reboot ( CONFIG_ESP_SYSTEM_PANIC_SILENT_REBOOT ) Do not print registers or backtrace, restart the chip immediately.
- Invoke GDB Stub ( CONFIG_ESP_SYSTEM_PANIC_GDBSTUB ) Start GDB server which can communicate with GDB over console UART port. This option will only provide read-only debugging or post-mortem debugging. See GDB Stub for more details.
The behavior of the panic handler is affected by three other configuration options.
- If CONFIG_ESP_DEBUG_OCDAWARE is enabled (which is the default), the panic handler will detect whether a JTAG debugger is connected. If it is, execution will be halted and control will be passed to the debugger. In this case, registers and backtrace are not dumped to the console, and GDBStub / Core Dump functions are not used.
- If the Core Dump feature is enabled, then the system state (task stacks and registers) will be dumped to either Flash or UART, for later analysis.
- If CONFIG_ESP_PANIC_HANDLER_IRAM is disabled (disabled by default), the panic handler code is placed in flash memory, not IRAM. This means that if ESP-IDF crashes while flash cache is disabled, the panic handler will automatically re-enable flash cache before running GDB Stub or Core Dump. This adds some minor risk, if the flash cache status is also corrupted during the crash. If this option is enabled, the panic handler code (including required UART functions) is placed in IRAM, and hence will decrease the usable memory space in SRAM. But this may be necessary to debug some complex issues with crashes while flash cache is disabled (for example, when writing to SPI flash) or when flash cache is corrupted when an exception is triggered.
- If CONFIG_ESP_SYSTEM_PANIC_REBOOT_DELAY_SECONDS is enabled (disabled by default) and set to a number higher than 0, the panic handler will delay the reboot for that amount of time in seconds. This can help if the tool used to monitor serial output does not provide a possibility to stop and examine the serial output. In that case, delaying the reboot will allow users to examine and debug the panic handler output (backtrace, etc.) for the duration of the delay. After the delay, the device will reboot. The reset reason is preserved.
The following diagram illustrates the panic handler behavior:
Register Dump and Backtrace
Unless the CONFIG_ESP_SYSTEM_PANIC_SILENT_REBOOT option is enabled, the panic handler prints some of the CPU registers, and the backtrace, to the console
Core 0 register dump: PC : 0x400e14ed PS : 0x00060030 A0 : 0x800d0805 A1 : 0x3ffb5030 A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000001 A5 : 0x3ffb50dc A6 : 0x00000000 A7 : 0x00000001 A8 : 0x00000000 A9 : 0x3ffb5000 A10 : 0x00000000 A11 : 0x3ffb2bac A12 : 0x40082d1c A13 : 0x06ff1ff8 A14 : 0x3ffb7078 A15 : 0x00000000 SAR : 0x00000014 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000000 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0xffffffff Backtrace: 0x400e14ed:0x3ffb5030 0x400d0802:0x3ffb5050
The register values printed are the register values in the exception frame, i.e., values at the moment when the CPU exception or another fatal error has occurred.
A Register dump is not printed if the panic handler has been executed as a result of an abort() call.
In some cases, such as interrupt watchdog timeout, the panic handler may print additional CPU registers (EPC1-EPC4) and the registers/backtrace of the code running on the other CPU.
The backtrace line contains PC:SP pairs, where PC is the Program Counter and SP is Stack Pointer, for each stack frame of the current task. If a fatal error happens inside an ISR, the backtrace may include PC:SP pairs both from the task which was interrupted, and from the ISR.
If IDF Monitor is used, Program Counter values will be converted to code locations (function name, file name, and line number), and the output will be annotated with additional lines:
Core 0 register dump: PC : 0x400e14ed PS : 0x00060030 A0 : 0x800d0805 A1 : 0x3ffb5030 0x400e14ed: app_main at /Users/user/esp/example/main/main.cpp:36 A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000001 A5 : 0x3ffb50dc A6 : 0x00000000 A7 : 0x00000001 A8 : 0x00000000 A9 : 0x3ffb5000 A10 : 0x00000000 A11 : 0x3ffb2bac A12 : 0x40082d1c A13 : 0x06ff1ff8 0x40082d1c: _calloc_r at /Users/user/esp/esp-idf/components/newlib/syscalls.c:51 A14 : 0x3ffb7078 A15 : 0x00000000 SAR : 0x00000014 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000000 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0xffffffff Backtrace: 0x400e14ed:0x3ffb5030 0x400d0802:0x3ffb5050 0x400e14ed: app_main at /Users/user/esp/example/main/main.cpp:36 0x400d0802: main_task at /Users/user/esp/esp-idf/components/esp32/cpu_start.c:470
To find the location where a fatal error has happened, look at the lines which follow the “Backtrace” line. Fatal error location is the top line, and subsequent lines show the call stack.
GDB Stub
If the CONFIG_ESP_SYSTEM_PANIC_GDBSTUB option is enabled, the panic handler will not reset the chip when a fatal error happens. Instead, it will start a GDB remote protocol server, commonly referred to as GDB Stub. When this happens, a GDB instance running on the host computer can be instructed to connect to the ESP32 UART port.
If IDF Monitor is used, GDB is started automatically when a GDB Stub prompt is detected on the UART. The output looks like this:
Entering gdb stub now. $T0b#e6GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-gff1f415) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_apple-darwin16.3.0 --target=xtensa-esp32-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". Reading symbols from /Users/user/esp/example/build/example.elf. done. Remote debugging using /dev/cu.usbserial-31301 0x400e1b41 in app_main () at /Users/user/esp/example/main/main.cpp:36 36 *((int*) 0) = 0; (gdb)
The GDB prompt can be used to inspect CPU registers, local and static variables, and arbitrary locations in memory. It is not possible to set breakpoints, change the PC, or continue execution. To reset the program, exit GDB and perform an external reset: Ctrl-T Ctrl-R in IDF Monitor, or using the external reset button on the development board.
RTC Watchdog Timeout
The RTC watchdog is used in the startup code to keep track of execution time and it also helps to prevent a lock-up caused by an unstable power source. It is enabled by default (see CONFIG_BOOTLOADER_WDT_ENABLE ). If the execution time is exceeded, the RTC watchdog will restart the system. In this case, the ROM bootloader will print a message with the RTC Watchdog Timeout reason for the reboot.
rst:0x10 (RTCWDT_RTC_RESET)
The RTC watchdog covers the execution time from the first stage bootloader (ROM bootloader) to application startup. It is initially set in the ROM bootloader, then configured in the bootloader with the CONFIG_BOOTLOADER_WDT_TIME_MS option (9000 ms by default). During the application initialization stage, it is reconfigured because the source of the slow clock may have changed, and finally disabled right before the app_main() call. There is an option CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE which prevents the RTC watchdog from being disabled before app_main . Instead, the RTC watchdog remains active and must be fed periodically in your application’s code.
Guru Meditation Errors
This section explains the meaning of different error causes, printed in parens after the Guru Meditation Error: Core panic’ed message.
See the Guru Meditation Wikipedia article for historical origins of “Guru Meditation”.
IllegalInstruction
This CPU exception indicates that the instruction which was executed was not a valid instruction. The most common reasons for this error include:
- FreeRTOS task function has returned. In FreeRTOS, if a task function needs to terminate, it should call vTaskDelete() and delete itself, instead of returning.
- Failure to read next instruction from SPI flash. This usually happens if:
- Application has reconfigured the SPI flash pins as some other function (GPIO, UART, etc.). Consult the Hardware Design Guidelines and the datasheet for the chip or module for details about the SPI flash pins.
- Some external device has accidentally been connected to the SPI flash pins, and has interfered with communication between ESP32 and SPI flash.
InstrFetchProhibited
This CPU exception indicates that the CPU could not read an instruction because the address of the instruction does not belong to a valid region in instruction RAM or ROM.
Usually, this means an attempt to call a function pointer, which does not point to valid code. PC (Program Counter) register can be used as an indicator: it will be zero or will contain a garbage value (not 0x4xxxxxxx ).
LoadProhibited, StoreProhibited
These CPU exceptions happen when an application attempts to read from or write to an invalid memory location. The address which has been written/read is found in the EXCVADDR register in the register dump. If this address is zero, it usually means that the application has attempted to dereference a NULL pointer. If this address is close to zero, it usually means that the application has attempted to access a member of a structure, but the pointer to the structure is NULL. If this address is something else (garbage value, not in 0x3fxxxxxx — 0x6xxxxxxx range), it likely means that the pointer used to access the data is either not initialized or has been corrupted.
IntegerDivideByZero
Application has attempted to do an integer division by zero.
LoadStoreAlignment
Application has attempted to read or write a memory location, and the address alignment does not match the load/store size. For example, a 32-bit read can only be done from a 4-byte aligned address, and a 16-bit write can only be done to a 2-byte aligned address.
LoadStoreError
This exception may happen in the following cases:
- If the application has attempted to do an 8- or 16- bit read to, or write from, a memory region which only supports 32-bit reads/writes. For example, dereferencing a char* pointer to instruction memory (IRAM, IROM) will result in such an error.
- If the application has attempted to write to a read-only memory region, such as IROM or DROM.
Unhandled Debug Exception
This CPU exception happens when the instruction BREAK is executed.
Interrupt Watchdog Timeout on CPU0/CPU1
Indicates that an interrupt watchdog timeout has occurred. See Watchdogs for more information.
Cache disabled but cached memory region accessed
In some situations, ESP-IDF will temporarily disable access to external SPI Flash and SPI RAM via caches. For example, this happens when spi_flash APIs are used to read/write/erase/mmap regions of SPI Flash. In these situations, tasks are suspended, and interrupt handlers not registered with ESP_INTR_FLAG_IRAM are disabled. Make sure that any interrupt handlers registered with this flag have all the code and data in IRAM/DRAM. Refer to the SPI flash API documentation for more details.
Other Fatal Errors
Brownout
ESP32 has a built-in brownout detector, which is enabled by default. The brownout detector can trigger a system reset if the supply voltage goes below a safe level. The brownout detector can be configured using CONFIG_ESP_BROWNOUT_DET and CONFIG_ESP_BROWNOUT_DET_LVL_SEL options.
When the brownout detector triggers, the following message is printed:
Brownout detector was triggered
The chip is reset after the message is printed.
Note that if the supply voltage is dropping at a fast rate, only part of the message may be seen on the console.
Corrupt Heap
ESP-IDF’s heap implementation contains a number of run-time checks of the heap structure. Additional checks (“Heap Poisoning”) can be enabled in menuconfig. If one of the checks fails, a message similar to the following will be printed:
CORRUPT HEAP: Bad tail at 0x3ffe270a. Expected 0xbaad5678 got 0xbaac5678 assertion "head != NULL" failed: file "/Users/user/esp/esp-idf/components/heap/multi_heap_poisoning.c", line 201, function: multi_heap_free abort() was called at PC 0x400dca43 on core 0
Consult Heap Memory Debugging documentation for further information.
Stack overflow
FreeRTOS End of Stack Watchpoint
ESP-IDF provides a custom FreeRTOS stack overflow detecting mechanism based on watchpoints. Every time FreeRTOS switches task context, one of the watchpoints is set to watch the last 32 bytes of stack.
Generally, this may cause the watchpoint to be triggered up to 28 bytes earlier than expected. The value 32 is chosen because it is larger than the stack canary size in FreeRTOS (20 bytes). Adopting this approach ensures that the watchpoint triggers before the stack canary is corrupted, not after.
Not every stack overflow is guaranteed to trigger the watchpoint. It is possible that the task writes to memory beyond the stack canary location, in which case the watchpoint will not be triggered.
If watchpoint triggers, the message will be similar to:
Debug exception reason: Stack canary watchpoint triggered (task_name)
This feature can be enabled by using the CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK option.
FreeRTOS Stack Checks
Stack Smashing
Stack smashing protection (based on GCC -fstack-protector* flags) can be enabled in ESP-IDF using CONFIG_COMPILER_STACK_CHECK_MODE option. If stack smashing is detected, message similar to the following will be printed:
Stack smashing protect failure! abort() was called at PC 0x400d2138 on core 0 Backtrace: 0x4008e6c0:0x3ffc1780 0x4008e8b7:0x3ffc17a0 0x400d2138:0x3ffc17c0 0x400e79d5:0x3ffc17e0 0x400e79a7:0x3ffc1840 0x400e79df:0x3ffc18a0 0x400e2235:0x3ffc18c0 0x400e1916:0x3ffc18f0 0x400e19cd:0x3ffc1910 0x400e1a11:0x3ffc1930 0x400e1bb2:0x3ffc1950 0x400d2c44:0x3ffc1a80 0
The backtrace should point to the function where stack smashing has occurred. Check the function code for unbounded access to local arrays.
Undefined Behavior Sanitizer (UBSAN) Checks
Undefined behavior sanitizer (UBSAN) is a compiler feature which adds run-time checks for potentially incorrect operations, such as:
- overflows (multiplication overflow, signed integer overflow)
- shift base or exponent errors (e.g., shift by more than 32 bits)
- integer conversion errors
See GCC documentation of -fsanitize=undefined option for the complete list of supported checks.
Enabling UBSAN
UBSAN is disabled by default. It can be enabled at file, component, or project level by adding the -fsanitize=undefined compiler option in the build system.
When enabling UBSAN for code which uses the SOC hardware register header files ( soc/xxx_reg.h ), it is recommended to disable shift-base sanitizer using -fno-sanitize=shift-base option. This is due to the fact that ESP-IDF register header files currently contain patterns which cause false positives for this specific sanitizer option.
To enable UBSAN at project level, add the following code at the end of the project’s CMakeLists.txt file:
idf_build_set_property(COMPILE_OPTIONS "-fsanitize=undefined" "-fno-sanitize=shift-base" APPEND)
Alternatively, pass these options through the EXTRA_CFLAGS and EXTRA_CXXFLAGS environment variables.
Enabling UBSAN results in significant increase of code and data size. Most applications, except for the trivial ones, will not fit into the available RAM of the microcontroller when UBSAN is enabled for the whole application. Therefore it is recommended that UBSAN is instead enabled for specific components under test.
To enable UBSAN for a specific component ( component_name ) from the project’s CMakeLists.txt file, add the following code at the end of the file:
idf_component_get_property(lib component_name COMPONENT_LIB) target_compile_options($ PRIVATE "-fsanitize=undefined" "-fno-sanitize=shift-base")
See the build system documentation for more information about build properties and component properties .
To enable UBSAN for a specific component ( component_name ) from CMakeLists.txt of the same component, add the following at the end of the file:
target_compile_options($ PRIVATE "-fsanitize=undefined" "-fno-sanitize=shift-base")
UBSAN Output
When UBSAN detects an error, a message and the backtrace are printed, for example:
Undefined behavior of type out_of_bounds Backtrace:0x4008b383:0x3ffcd8b0 0x4008c791:0x3ffcd8d0 0x4008c587:0x3ffcd8f0 0x4008c6be:0x3ffcd950 0x400db74f:0x3ffcd970 0x400db99c:0x3ffcd9a0
When using IDF Monitor , the backtrace will be decoded to function names and source code locations, pointing to the location where the issue has happened (here it is main.c:128 ):
0x4008b383: panic_abort at /path/to/esp-idf/components/esp_system/panic.c:367 0x4008c791: esp_system_abort at /path/to/esp-idf/components/esp_system/system_api.c:106 0x4008c587: __ubsan_default_handler at /path/to/esp-idf/components/esp_system/ubsan.c:152 0x4008c6be: __ubsan_handle_out_of_bounds at /path/to/esp-idf/components/esp_system/ubsan.c:223 0x400db74f: test_ub at main.c:128 0x400db99c: app_main at main.c:56 (discriminator 1)
The types of errors reported by UBSAN can be as follows:
Incorrect pointer value: null, unaligned, not compatible with the given type.
add_overflow , sub_overflow , mul_overflow , negate_overflow
Integer overflow during addition, subtraction, multiplication, negation.
Integer division by 0 or INT_MIN .
Overflow in left or right shift operators.
Access outside of bounds of an array.
Unreachable code executed.
Non-void function has reached its end without returning a value (C++ only).
Size of variable length array is not positive.
Value of bool or enum (C++ only) variable is invalid (out of bounds).
Null argument passed to a function which is declared with a nonnull attribute.
Null value returned from a function which is declared with returns_nonnull attribute.
__builtin_unreachable function called.
Overflow in pointer arithmetic.
© Copyright 2016 — 2023, Espressif Systems (Shanghai) Co., Ltd.
- Built with Sphinx using a theme based on Read the Docs Sphinx Theme.
- Download PDF
Status illegal instruction что за ошибка
Примечание: используется ТОЛЬКО для жалоб на спам, рекламу и проблемные сообщения (например, нападки, оскорбления или грубости).
© Valve Corporation. Все права защищены. Все торговые марки являются собственностью соответствующих владельцев в США и других странах. Часть географических сведений на этом сайте предоставлена geonames.org.
Политика конфиденциальности | Правовая информация | Соглашение подписчика Steam | Файлы cookieHow to Resolve The Error “Illegal instruction (core dumped)” when Running “import tensorflow” in a Python Program
There are several ways to install TensorFlow on Ubuntu. The easiest way is to install via pip . Unfortunately, this easy installation may result in a bumpy first time experience of running TensorFlow. Consider the following one line Python script:
$ python -c 'import tensorflow as tf;'
This should be where the excitement begins, the moment where conviction about the new era of AI-powered banalities starts to bloom. Yet, the reality can be unexpectedly different. Executing the command may immediately raise this very infamous error:
Illegal instruction (core dumped)
This means that TensorFlow has crashed even before it does anything. What a surprise!
The good thing is that we can run gdb to debug Python and start analyzing the call stack. But what’s even better is that we can save the brilliance for later. This error has been repeatedly reported and has conveniently sat on its fame for a while, as reflected on the issue page.
In brief, the error will be thrown if we’re running recent TensorFlow binaries on CPU(s) that do not support Advanced Vector Extensions (AVX), an instruction set that enables faster computation especially for vector operations. Starting from TensorFlow 1.6, pre-built TensorFlow binaries use AVX instructions. An excerpt from TensorFlow 1.6 release announcement:
. Breaking Changes Prebuilt binaries are now built against CUDA 9.0 and cuDNN 7. Prebuilt binaries will use AVX instructions. This may break TF on older CPUs. .
This implicitly means that the latest version, which is TensorFlow 1.10 by the time this article is written, also use AVX instructions. Hence, the crash on older CPUs.
Verifying AVX Support
Assumption can mislead and should be proven with validation. Despite presuming that the crash might be caused by the absence of AVX support in the CPU, we may need to verify this. We do so by obtaining the information about CPU features and filtering to the features to find out about AVX availability. We use the following command to list all the CPU features.
$ more /proc/cpuinfo | grep flags
Compare these two sample outputs, the first is from a machine with old CPU and the latter is from another machine with more modern CPU.
. flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 hypervisor lahf_lm .
. flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb invpcid_single retpoline kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts .
As you can immediately observe, the newer CPU is shipped with many more features, including AVX and AVX2 instruction sets. This is a stark contrast compared to the older CPU, which provides more limited features, hence less performance optimization opportunity.
So, what is the resolve if the CPU in your current machine does not support AVX? We have two possible options:
1. Downgrading to TensorFlow 1.5, which does not use AVX instruction in the binaries
2. Compile TensorFlow and install with only possible CPU optimizationDowngrading to TensorFlow 1.5
The downgrade process is very simple as outlined below.
Step 1: Uninstall the currently installed TensorFlow module
$ pip uninstall tensorflow
Step 2: Install TensorFlow 1.5
$ pip install tensorflow==1.5
Step 3: Verify that the error disappears when running TensorFlow
$ python -c 'import tensorflow as tf; print(tf.__version__)'
After completing the downgrade, we will now be able to run TensorFlow code for serving a model. However, we are running somewhat older version of TensorFlow and may suffer from other bugs or issues that have not been resolved for that version. If running the latest TensorFlow is a preferred route, you can take a look at the explanation in the next section
Installing TensorFlow from Source (Custom Build)
The TensorFlow official documentation provides the guide for building TensorFlow from source. However, the documentation did not really specify how to optimize the source build especially for TensorFlow with CPU support-only. Build optimization takes place by appending additional flags to -march=native, which is the default optimization flag. Optimization flags vary from one machine to another.
To find possible optimization flags in the current machine, we run this command on the command line prompt:
$ grep flags -m1 /proc/cpuinfo | cut -d ":" -f 2 | tr '[:upper:]' '[:lower:]' | < read FLAGS; OPT="-march=native"; for flag in $FLAGS; do case "$flag" in "sse4_1" | "sse4_2" | "ssse3" | "fma" | "cx16" | "popcnt" | "avx" | "avx2") OPT+=" -m$flag";; esac; done; MODOPT=$; echo "$MODOPT"; >
From the previous two CPU samples, we will have “-march=native -mcx16” flags for the older CPU and “-march=native -mssse3 -mfma -mcx16 -msse4_1 -msse4_2 -mpopcnt -mavx -mavx2” flags for the more modern CPU. We supply these flags to the build configurator and then generate the WHL file that can be installed to the system.
The full instruction for building TensorFlow that targets CPU optimization is explained in this article.
Github Repository TensorFlow CPU Custom Build
For some reasons, you may find it less practical to build from source and will prefer a more convenient way to install the custom TensorFlow CPU build. If you want to go this route, you can check this Github repository that hosts TensorFlow custom builds, starting from TensorFlow 1.10. Custom builds for future releases will also be added to this repository, subject to the availability of machines and other resources to perform the source build.
- How to Build and Install The Latest TensorFlow without CUDA GPU and with Optimized CPU Performance on Ubuntu
- Resolving Error “ImportError: No module name named hypothesis”
- Eclipse Quick Tip: Resolving Error “The import javax.servlet cannot be resolved”
- Guide: Installing Tensor Flow 1.8 with GPU Support against CUDA 9.1 and cuDNN 7.1 on Ubuntu 16.04
- Command Cheatsheet: Checking Versions of Installed Software / Libraries / Tools for Deep Learning on Ubuntu 16.04
12 thoughts on “ How to Resolve The Error “Illegal instruction (core dumped)” when Running “import tensorflow” in a Python Program ”
- BenOctober 13, 2018 at 3:50 pm Thanks for the info!
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Illegal instruction (core dumped) after running import tensorflow #17411
konnerthg opened this issue Mar 4, 2018 · 100 comments
Illegal instruction (core dumped) after running import tensorflow #17411
konnerthg opened this issue Mar 4, 2018 · 100 comments
stat:awaiting response Status — Awaiting response from authorComments
konnerthg commented Mar 4, 2018 •
System information
- Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 16.04
- TensorFlow installed from (source or binary): binary
- TensorFlow version (use command below):
1.6.0-cp27-cp27mu-manylinux1_x86_64 (can only guess since python -c «import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)» gives me an error already) - Python version: Python 2.7.12
- Exact command to reproduce: import tensorflow
I created a fresh virtual environment: virtualenv -p python2 test_venv/
And installed tensorflow: pip install —upgrade —no-cache-dir tensorflow
import tensorflow gives me Illegal instruction (core dumped)Please help me understand what’s going on and how I can fix it. Thank you.
-cpu description: CPU product: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz bus info: cpu@0 version: CPU Version capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm arat cpufreq
EDIT
Stacktrace obtained with gdb:#0 0x00007fffe5793880 in std::pair >, false, true>, bool> std::_Hashtable >, std::allocator > >, std::__detail::_Select1st, std::equal_to, tensorflow::StringPieceHasher, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_emplace > >(std::integral_constant, std::pair >&&) () from /media/gerry/hdd_1/ws_hdd/test_venv/local/lib/python2.7/site-packages/tensorflow/python/../libtensorflow_framework.so #1 0x00007fffe5795735 in tensorflow::UnaryVariantOpRegistry::RegisterDecodeFn(std::string const&, std::function const&) () from /media/gerry/hdd_1/ws_hdd/test_venv/local/lib/python2.7/site-packages/tensorflow/python/../libtensorflow_framework.so #2 0x00007fffe5770a7c in tensorflow::variant_op_registry_fn_registration::UnaryVariantDecodeRegistration::UnaryVariantDecodeRegistration(std::string const&) () from /media/gerry/hdd_1/ws_hdd/test_venv/local/lib/python2.7/site-packages/tensorflow/python/../libtensorflow_framework.so #3 0x00007fffe56ea165 in _GLOBAL__sub_I_tensor.cc () from /media/gerry/hdd_1/ws_hdd/test_venv/local/lib/python2.7/site-packages/tensorflow/python/../libtensorflow_framework.so #4 0x00007ffff7de76ba in call_init (l=, argc=argc@entry=2, argv=argv@entry=0x7fffffffd5c8, env=env@entry=0xa7b4d0) at dl-init.c:72 #5 0x00007ffff7de77cb in call_init (env=0xa7b4d0, argv=0x7fffffffd5c8, argc=2, l=) at dl-init.c:30 #6 _dl_init (main_map=main_map@entry=0xa11920, argc=2, argv=0x7fffffffd5c8, env=0xa7b4d0) at dl-init.c:120 #7 0x00007ffff7dec8e2 in dl_open_worker (a=a@entry=0x7fffffffb5c0) at dl-open.c:575 #8 0x00007ffff7de7564 in _dl_catch_error (objname=objname@entry=0x7fffffffb5b0, errstring=errstring@entry=0x7fffffffb5b8, mallocedp=mallocedp@entry=0x7fffffffb5af, operate=operate@entry=0x7ffff7dec4d0 , args=args@entry=0x7fffffffb5c0) at dl-error.c:187 #9 0x00007ffff7debda9 in _dl_open ( file=0x7fffea7cbc34 "/media/gerry/hdd_1/ws_hdd/test_venv/local/lib/python2.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so", mode=-2147483646, caller_dlopen=0x51ad19 , nsid=-2, argc=, argv=, env=0xa7b4d0) at dl-open.c:660 #10 0x00007ffff75ecf09 in dlopen_doit (a=a@entry=0x7fffffffb7f0) at dlopen.c:66 #11 0x00007ffff7de7564 in _dl_catch_error (objname=0x9b1870, errstring=0x9b1878, mallocedp=0x9b1868, operate=0x7ffff75eceb0 , args=0x7fffffffb7f0) at dl-error.c:187 #12 0x00007ffff75ed571 in _dlerror_run (operate=operate@entry=0x7ffff75eceb0 , args=args@entry=0x7fffffffb7f0) at dlerror.c:163 #13 0x00007ffff75ecfa1 in __dlopen (file=, mode=) at dlopen.c:87 #14 0x000000000051ad19 in _PyImport_GetDynLoadFunc () #15 0x000000000051a8e4 in _PyImport_LoadDynamicModule () #16 0x00000000005b7b1b in ?? () #17 0x00000000004bc3fa in PyEval_EvalFrameEx () #18 0x00000000004c136f in PyEval_EvalFrameEx () #19 0x00000000004b9ab6 in PyEval_EvalCodeEx () #20 0x00000000004b97a6 in PyEval_EvalCode () #21 0x00000000004b96df in PyImport_ExecCodeModuleEx () #22 0x00000000004b2b06 in ?? () #23 0x00000000004a4ae1 in ?? ()
EDIT 2
Bazel version: N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/AAfter downgrading to an older version of tensorflow the error goes away. I’ve been advised that my CPU (see information above) might not work with some improvements in the new API. If this is the case, I suppose there’s no solution for my problem. Therefore, I will close this thread. Feel free to correct me though. Thank you for your support
The text was updated successfully, but these errors were encountered: