Vtune 2022.1.0 Crash

[BDe_K]

Hi,

I've installed Vtune 2022.1.0 for Linux on my machine :

    OS        :  Ubuntu 18.04 LTS

    Kernel :  5.4.0-94-generic

    CPU     :  Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz

And vtune-gui starts fine...but as soon as I choose "Configure Analysis", Vtune generates an Unrecoverable Exception and I cannot go further (unusable).

(Please see the Exception message in the file "crash_Info.txt" attached here)

All VTune Kernel messages (see "dmesg log" in the file "crash_info-dmesg.txt attached here) seems fine accept for the last one which should correspond to the generated Exception :

       traps: vtune-gui[16990] trap int3 ip:55c3e7880128 sp:7ffeb04ab0f0 error:0 in vtune-gui[55c3e7572000+65ed000]

I believe that the Exception occurs as soon as VTune tries to probe the hardware to determine what capabilities it has in order to determine what analysis can be used.

How can I correct this problem ?

Am I missing some packages or have incompatible packages versions in my Ubuntu distribution ?

Or is there a BIOS switch that impairs VTune's hardware exploration ?

Or maybe some access permissions that need to be changed ?

Any help would be greatly appreciated since VTune is unusable for me because of this and I really need it

Best regards,

Bruno

[Andrey_I_Intel]

Hi Bruno,

You are right, it seems that something went wrong in the process of hardware probing. I have an idea about what could be the cause, so could you please post output of

ls -la /dev

as a file here?

Please also try to launch VTune as root if possible, as a potential workaround.

BR,

Andrey

[BDe_K]

Hi Andrey,

So nice of you to give me a hand, it's very much appreciated.

Here is the output of "ls -la /dev" in the attached file.

Also, I've already tried to launch VTune as root (sudo) without success...same problem.

Could it be some "security switches" (secure boot or other) in BIOS that prevents the Hardware Probing ?

Best regards and thanks again for your help,

Bruno

[Andrey_I_Intel]

I doubt this has anything to do with BIOS settings. I found a bug in the code that traverses /dev and can cause such an issue, but was only able to reproduce it by creating a symlink to an inaccessible subfolder there. The only suspicious entry in your case was "stlinkv2_14 -> sep5/s14", which looks obviously odd and was probably created by some other driver bug, but trying as root should have solved it.

On my system I could identify the problematic entry with this bash oneliner, maybe it would help finding a workaround on yours:

for f in /dev/*; do stat -L $f 1> /dev/null ; done

Anyway, a solid fix should be in the next release.

[BDe_K]

Hi Andrey,

You're a genius

That did the trick and now Vtune works fine (even without sudo).

I would have struggled to find that

The "stlinkv2" entries in "/dev" are coming from an install of TrueStudio (STM) and are devices to connect to and debug  an STM32Fx evaluation card.

It seem that one of the "/etc/udev/rules.d/" rule files for the creation of those nodes in "/dev" are somewhat screwed up.

And I will be correcting that permanently.

Thank you so much, you've made my day

Bruno

[BDe_K]

Hello Andrey,

Here is a little update that may help you to find and correct this bug.

In my "/etc/udev/rules.d", I had a "rule file" for STLink with the following rule which created the node entries in /dev :

               SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
               MODE:="0666", \
               SYMLINK+="stlinkv2-1_%n"

For some reason, when exploring "/sys/devices/virtual/", "udev" finds the "sep5" directory "/sys/devices/virtual/sep5" and decides that it matches this rule.

It thus creates the problematic node entry in "/dev".

My workaround is to add a rule specific to "sep5" in the rule file, to specifically skip over the STLink rule, such as :

                SUBSYSTEM=="sep5", GOTO="skip_rule_for_sep5"

                SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
                MODE:="0666", \
                SYMLINK+="stlinkv2-1_%n"

                LABEL="skip_rule_for_sep5"

And this works fine...no more problematic node entry with symbolic links to "sep5 nodes".

Maybe this will help you or others

Best regards and thanks again,

Bruno

[Andrey_I_Intel]

Glad this helped.

But I must note that this rule does not seem to work as expected. I think it is meant to pick specific ttyUSB* devices and create symlinks to it, but instead it picks all character devices that appear in /dev and messes their access permissions, seeing how you have sda allowed for write for everyone. This can create a security gap on your host, so I believe your udev configuration best be revised.

BR,

Andrey

[AlekhyaV_Intel]

Hi,

This bug is resolved in the latest version of VTune i.e. 2022.2. As this issue is resolved, Can we discontinue monitoring this thread?

Regards,

Alekhya

[AlekhyaV_Intel]

Hi @BDe_K ,

Could you please give us an update regarding this issue?

Regards,

Alekhya

[AlekhyaV_Intel]

Hi Bruno,

As we have not heard back from you, we will close this thread. If you need any further assistance, please post a new question as this thread will no longer be monitored by Intel.

Regards,

Alekhya