- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
We're using vtune for profiling and tuning our code, and it's been working fine for us for a long time.
However, I've just updated to the lastest version:
Intel(R) VTune(TM) Profiler 2025.0.1 (build 629235) Command Line Tool
and we've started having problems with random crashes in vtune. Checking the core file shows:
(gdb) bt
#0 0x00007fd9c31bc4d2 in CRYPTO_THREAD_read_lock () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#1 0x00007fd9c3183f3e in ERR_lib_error_string () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#2 0x00007fd9c318409e in ossl_err_string_int.part () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#3 0x00007fd9c309639b in ossl_strerror () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#4 0x00007fd9c3099e65 in ossl_connect_step2 () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#5 0x00007fd9c309c534 in ossl_connect_common () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#6 0x00007fd9c3054cf3 in ssl_cf_connect () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#7 0x00007fd9c30605d0 in cf_setup_connect () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#8 0x00007fd9c309ef25 in cf_hc_connect () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#9 0x00007fd9c305c4c9 in Curl_conn_connect () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#10 0x00007fd9c3033581 in multi_runsingle () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#11 0x00007fd9c3034b82 in curl_multi_perform () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#12 0x00007fd9c3024ccb in curl_easy_perform () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#13 0x00007fd9c3024438 in SocketManagerImpl::transact(TransactionConfig&) () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#14 0x00007fd9c3007644 in OTELDirectMetricProvider::send_data(TransactionConfig&) () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#15 0x00007fd9c3008a76 in OTELDirectMetricProvider::flush_thread(OTELDirectMetricProvider*) ()
from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#16 0x00007fd9c3470fff in execute_native_thread_routine () from /opt/intel/oneapi/vtune/2025.0/lib64/libswip.so
#17 0x00007fd9d92a81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#18 0x00007fd9d932883c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
showing that the crash is buried at the bottom of libswip.so - vendored copies of libcurl and libssl. Why on earth is a profiler making https calls?
Checking with strace shows that the system is periodically doing DNS lookups for analytics.softwareimprovement.intel.com and then presumably sending data there.
This extra telemetry seems to have made vtune less reliable, and there's no mention of it anywhere in the docs, nor can I find a way to disable it to see if that fixes the crashes we're seeing. I guess we need to stick with the previous version of vtune for now.
(I've already sent a crash report using amplxe-feedback as requested)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
Are you able to share the console output or the VTune results so that we can check with the development team?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
Sure - console log is below, and the matching crash info file.
I can provide the core dump too if that's helpful. (It's too big to attach here, even compressed.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you try setting the environment variable using "export SWIP_NULL_SOCKET=1" and let us know if this resolves the crash?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
I've tested with that, and it changes behaviour. After a number of runs, it's now crashing in a different place:
(No debugging symbols found in /opt/intel/oneapi-new/vtune/latest/bin64/vtune)
[New LWP 464332]
[New LWP 464394]
[New LWP 464395]
[New LWP 464334]
[New LWP 464399]
[New LWP 464397]
[New LWP 464396]
[New LWP 464398]
[New LWP 464393]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/intel/oneapi-new/vtune/2025.0/bin64/vtune -q -run-pass-thru=--perf-threads'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f1ae0983b10 in OSSL_ERR_STATE_free () from /opt/intel/oneapi-new/vtune/2025.0/lib64/libswip.so
[Current thread is 1 (Thread 0x7f1af84bb8c0 (LWP 464332))]
(gdb) bt
#0 0x00007f1ae0983b10 in OSSL_ERR_STATE_free () from /opt/intel/oneapi-new/vtune/2025.0/lib64/libswip.so
#1 0x00007f1ae09ad538 in init_thread_stop.part () from /opt/intel/oneapi-new/vtune/2025.0/lib64/libswip.so
#2 0x00007f1ae09ad82d in OPENSSL_thread_stop () from /opt/intel/oneapi-new/vtune/2025.0/lib64/libswip.so
#3 0x00007f1ae09acc0b in OPENSSL_cleanup () from /opt/intel/oneapi-new/vtune/2025.0/lib64/libswip.so
#4 0x00007f1af6a5d55d in __run_exit_handlers (status=0, listp=0x7f1af6bf1840 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:116
#5 0x00007f1af6a5d69a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:146
#6 0x00007f1af6a46251 in __libc_start_call_main (main=main@entry=0x5649aaa1df80, argc=argc@entry=17, argv=argv@entry=0x7ffc41cd1418)
at ../sysdeps/nptl/libc_start_call_main.h:74
#7 0x00007f1af6a46305 in __libc_start_main_impl (main=0x5649aaa1df80, argc=17, argv=0x7ffc41cd1418, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc41cd1408) at ../csu/libc-start.c:360
#8 0x00005649aaa09934 in ?? ()
Again, I have a core file if that helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you try the hotspots analysis and check if this also causes the crash?
Meanwhile, we are working internally to fix this crash and have addressed the issue with the development engineers.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page