Skip to content

Update OpenVINO EP to latest version - 2019 R3.1 - #7

Closed
psfoley wants to merge 26 commits into
masterfrom
openvino_R3
Closed

Update OpenVINO EP to latest version - 2019 R3.1#7
psfoley wants to merge 26 commits into
masterfrom
openvino_R3

Conversation

@psfoley

@psfoley psfoley commented Oct 29, 2019

Copy link
Copy Markdown

Description: Brings the OpenVINO EP up to date with the latest available version (2019 3.1)

Motivation and Context

Functional and Security Updates
Support for 10th generation Intel® Core™ processors
Network Loading Optimizations
For more details, please look at the link below
https://software.intel.com/en-us/articles/OpenVINO-RelNotes

Comment thread cmake/external/openvino.cmake Outdated
@psfoley
psfoley requested review from smkarlap and suryasidd October 29, 2019 17:17
Comment thread cmake/onnxruntime_providers.cmake
Comment thread cmake/onnxruntime_providers.cmake Outdated
Comment thread onnxruntime/core/providers/openvino/openvino_graph.cc
Comment thread cmake/onnxruntime_providers.cmake Outdated
# whose value is set in INTEL_CVSDK_DIR variable by running the setupvars.sh script
if (onnxruntime_USE_OPENVINO_BINARY)
if ($ENV{INTEL_CVSDK_DIR} MATCHES "2019.1")
if ($ENV{INTEL_CVSDK_DIR} MATCHES "2019.3")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check can be moved to Line 284 as

if ( NOT $ENV{INTEL_CVSDK_DIR} MATCHES "2019.3" )
  message(FATAL_ERROR ...)
endif()

And the rest of the code no longer needs to be enclosed within if blocks for version checks

@smkarlap

Copy link
Copy Markdown

Also, run clang-format tool to format the source according to ONNXRuntime specs.

cd <ov-ep-source-folder>
clang-format -style=file -i *.cc *.h

@smkarlap

Copy link
Copy Markdown

Looks good to me

Comment thread cmake/onnxruntime_providers.cmake Outdated
"${ONNXRUNTIME_ROOT}/core/providers/openvino/openvino_mo/*.py"
)

message($ENV{INTEL_CVSDK_DIR})

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please remove the message here?


if (node->OpType() == "Mul" || node->OpType() == "Add" || node->OpType() == "Div" || node->OpType() == "Sub") {
for (size_t i = 0; i < node->InputDefs().size(); i++) {
if (node->InputDefs()[i]->TypeAsProto()->tensor_type().elem_type() == ONNX_NAMESPACE::TensorProto_DataType::TensorProto_DataType_INT64) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should have a logic to reject for all unsupported data types? I can see George asking why only int64, this is not generic.

@psfoley psfoley closed this Jan 27, 2020
@psfoley

psfoley commented Jan 27, 2020

Copy link
Copy Markdown
Author

Merged to MSFT/OnnxRuntime Master

@psfoley
psfoley deleted the openvino_R3 branch January 27, 2020 21:29
sfatimar pushed a commit that referenced this pull request Aug 28, 2023
### Description
Release OrtEnv before main function returns. Before this change, OrtEnv
is deleted when C/C++ runtime destructs all global variables in ONNX
Runtime's core framework.
The callstack is like this:
```
  * frame #0: 0x00007fffee39f5a6 libonnxruntime.so.1.16.0`onnxruntime::Environment::~Environment(this=0x00007fffee39fbf2) at environment.h:20:7
    frame #1: 0x00007fffee39f614 libonnxruntime.so.1.16.0`std::default_delete<onnxruntime::Environment>::operator()(this=0x00007ffff4c30e50, __ptr=0x0000000005404b00) const at unique_ptr.h:85:2
    frame #2: 0x00007fffee39edca libonnxruntime.so.1.16.0`std::unique_ptr<onnxruntime::Environment, std::default_delete<onnxruntime::Environment>>::~unique_ptr(this=0x5404b00) at unique_ptr.h:361:17
    frame #3: 0x00007fffee39e2ab libonnxruntime.so.1.16.0`OrtEnv::~OrtEnv(this=0x00007ffff4c30e50) at ort_env.cc:43:1
    frame #4: 0x00007fffee39fa96 libonnxruntime.so.1.16.0`std::default_delete<OrtEnv>::operator()(this=0x00007fffefff8f78, __ptr=0x00007ffff4c30e50) const at unique_ptr.h:85:2
    frame #5: 0x00007fffee39f394 libonnxruntime.so.1.16.0`std::unique_ptr<OrtEnv, std::default_delete<OrtEnv>>::~unique_ptr(this=0x7ffff4c30e50) at unique_ptr.h:361:17
    frame #6: 0x00007ffff78574b5 libc.so.6`__run_exit_handlers + 261
    frame #7: 0x00007ffff7857630 libc.so.6`exit + 32
    frame #8: 0x00007ffff783feb7 libc.so.6`__libc_start_call_main + 135
    frame #9: 0x00007ffff783ff60 libc.so.6`__libc_start_main@@GLIBC_2.34 + 128
    frame #10: 0x0000000000abbdee node`_start + 46
```
After this change, OrtEnv will be deleted before the main function
returns and nodejs is still alive.
RyanMetcalfeInt8 pushed a commit to RyanMetcalfeInt8/onnxruntime that referenced this pull request Jul 25, 2025
hdharpure9922 pushed a commit that referenced this pull request Jul 28, 2026
…rosoft#29880)

### Description

`import onnxruntime` segfaults during `dlopen` of
`onnxruntime_pybind11_state.so` on Linux. This removes the global
initializer in `onnxruntime_pybind_state.cc` that eagerly calls
`Env::Default()`, and resolves the platform `Env` on first use at its
two call sites instead.

### Motivation and Context

The module has a namespace-scope dynamic initializer:

```cpp
static Env& platform_env = Env::Default();
```

Since POSIX telemetry landed (microsoft#27379), `Env::Default()` constructs
`PosixEnv`, whose `PosixTelemetry` member initializes the 1DS SDK in its
constructor. That path reads `defaultRuntimeConfig`, a namespace-scope
`static ILogConfiguration` defined in the 1DS SDK's
`RuntimeConfig_Default.hpp`, which lives in a **different translation
unit of the same shared library**.

Dynamic initialization order across translation units is unspecified,
and the pybind TU's initializer runs first. `Variant::merge_map`
therefore iterates a still zero-initialized `std::map`: `_M_node_count
== 0`, but `_M_header._M_left` is `nullptr` rather than self-pointing,
so `begin() != end()` and the loop dereferences null.

Textbook static initialization order fiasco. Backtrace (Release build
relinked without `--strip-all` to recover symbols):

```
#0  std::map<..., Variant>::lower_bound        stl_map.h:1307
#1  std::map<..., Variant>::operator[]         stl_map.h:509
#2  Variant::merge_map                         VariantType.hpp:508
#3  RuntimeConfig_Default::RuntimeConfig_Default  RuntimeConfig_Default.hpp:97
#4  LogManagerImpl::LogManagerImpl             LogManagerImpl.cpp:183
#5  LogManagerFactory::Create                  LogManagerFactory.cpp:36
#6  LogManagerFactory::lease
#7  LogManagerFactory::Get                     LogManagerFactory.hpp:71
#8  LogManagerProvider::Get                    LogManagerProvider.cpp:16
#9  onnxruntime::PosixTelemetry::Initialize()
#10 onnxruntime::PosixTelemetry::PosixTelemetry()
#11 onnxruntime::(anonymous namespace)::PosixEnv::PosixEnv()
#12 onnxruntime::Env::Default()
#13 _GLOBAL__sub_I_onnxruntime_pybind_state.cc
#14 call_init                                  elf/dl-init.c:74
...
#21 _dl_open                                   elf/dl-open.c:905
```

The crash is independent of `LD_LIBRARY_PATH` and `CUDA_VISIBLE_DEVICES`
— it happens before any ORT runtime code runs. `libonnxruntime.so` is
unaffected because it contains no global initializer that reaches
`Env::Default()`, which is why C/C++ and onnxruntime-genai consumers do
not see it.

Both remaining uses of `platform_env` are inside pybind lambdas that run
long after load, so calling `Env::Default()` there is safe. This also
removes the now-stale `TODO: we may delay-init this variable` and a
pre-existing `#pragma warning(push)` that should have been `pop`.

Note for follow-up: `Env::Default()` is now unsafe to call from any
dynamic initializer. This was the only such call site in the tree, but
hardening `PosixTelemetry` to defer SDK initialization out of its
constructor would remove the hazard entirely.

### Tests

Verified on a Linux CUDA 13 Release build (`onnxruntime_USE_TELEMETRY`
enabled):

- `dlopen` of `onnxruntime_pybind11_state.so` succeeds (previously
SIGSEGV).
- `import onnxruntime` reports the version and
`['CUDAExecutionProvider', 'CPUExecutionProvider']`.
- `onnxruntime.enable_telemetry_events()` / `disable_telemetry_events()`
— the two call sites changed here — work.
- CPU and CUDA inference sessions produce correct results.
- Reproduced and verified with `LD_LIBRARY_PATH` unset and
`CUDA_VISIBLE_DEVICES` empty.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants