Jump to content
Neil Pate

Missing external function in LV2019 64-bit executable

Recommended Posts

Thanks Rolf, that sounds quite plausible.
AQ this is a brand new CPU with a Ryzen 3600 in it. I would consider changing the CPU if NI could give some guidance on what to change it to.

Is there any sort of hot fix or patch I can try?

For now I am out of trouble as I have rewritten the VIs that I needed to use from that library (mine were really simple) , but I doubt others will be so lucky.

 

Share this post


Link to post
Share on other sites
2 hours ago, Neil Pate said:

this is a brand new CPU with a Ryzen 3600 in it.

I don't know if this is related to your issue or not, but there are known problems with some brand new AMD Ryzen CPUs: https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/

See if updating your BIOS helps at all. (Even if it doesn't solve this problem, I'd imagine you want a functional RNG on your PC!)

Share this post


Link to post
Share on other sites
9 hours ago, Aristos Queue said:

The MKL problem is in the wild? I thought that was something that was only affecting LV 2020 (now in beta) because we were updating to the latest MKL. The bug isn't on my team's plate... I just sit near the people who are handwringing a lot about it. If that's in the wild affecting already shipping MKL versions, then, yeah, that could be it. I still don't know how the node is rolling back to its last known good resolve path... I can't find that path stored anywhere... but if we assume it is binary encoded *somewhere* in the node's saved attributes, then this makes plausible sense. 

Workaround is to a) get a new CPU or b) wait until LV issues a new version where we do whatever we are doing to avoid calling certain CPU instructions (I'm unclear what the planned solution looks like). 

I definitely saw somewhere discussions about this that were not LabVIEW 2020 related. The solution was to create(edit) some environment variable for the MKL library itself where some thread configurations were forced explicitedly rather than letting MKL detect the right configuration automatically.

See this thread for some discussion of the problem and possible solutions. It seems to be related to latest AMD Ryzen CPUs with a specific SSE architecture.

That it falls back to trying to load from the penguin path is however rather strange. Generally these paths only exist in the executable as debug messages related to the source module the specific code was compiled from.

Edited by Rolf Kalbermatter
  • Thanks 2

Share this post


Link to post
Share on other sites

Thanks Rolf, that fix worked for me too! 👍🙏🙇‍♂️

I did search but never found that thread.

Phew, mystery solved!

 

Share this post


Link to post
Share on other sites
14 hours ago, Neil Pate said:

Phew, mystery solved!

For anyone else interested in how far this bug goes, I got this from one of my coworkers:

From my research it affects all processors based on the Zen 2 architecture (AMD processors that started being released in July of last year). AMD claimed that they dropped support in Zen 1 for fma4 instruction set, and the illegal instruction causing the crash is part of that set. The first series Ryzen processors sound like they may still work, but I didn't have access to any to verify one way or the other.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.