Jump to content

Potential memory corruption when (de-)serializing Sets in LabVIEW 2019 SP1 f3 (32-bit)

LogMAN

By LogMAN,
in LabVIEW Bugs

Followers 2

Recommended Posts

LogMAN

LogMAN 183

Posted
Posted (edited)

I discovered a potential memory corruption when using Variant To Flattened String and Flattened String To Variant functions on Sets. Here is the test code:

2053102155_LV2019SP1f3(32-bit)PotentialMemoryCorruptionwhen(de-)serializingSets.png.e31ac61a8ef3ee1d71ad471d67565015.png

In this example, the set is serialized and de-serialized without changing any data. The code runs in a loop to increase the chance of crashing LabVIEW.

Here is the type descriptor. If you are familiar with type descriptors, you'll notice that something is off:

image.png.36fcb733de6a787b78776e473e0540d9.png

Here is the translation:

  • 0x0008 - Length of the type descriptor in bytes, including the length word (8 bytes) => OK
  • 0x0073 - Data type (Set) => OK
  • 0x0001 - Number of dimensions (a set is essentially an array with dimension size 1) => OK
  • 0x0004 - Length of the type descriptor for the internal type in bytes, including the length word (4 bytes) => OK
  • ???? - Type descriptor for the internal data type (should be 0x0008 for U64) => What is going on?

It turns out that the last two bytes are truncated. The Flatten String To Variant function actually reports error 116, which makes sense because the type descriptor is incomplete, BUT it does not always return an error! In fact, half of the time, no error is reported and LabVIEW eventually crashes (most often after adding a label to the numeric type in the set constant). I believe that this corrupts memory, which eventually crashes LabVIEW. Here is a video that illustrates the behavior:

Can somebody please confirm this issue?

LV2019SP1f3 (32-bit) Potential Memory Corruption when (de-)serializing Sets.vi

Edited by LogMAN
TD length is in Bytes
Link to post
dadreamer

dadreamer 32

Posted
Posted
Just now, LogMAN said:

Can somebody please confirm this issue?

I confirm that in LabVIEW 2020 (both 32- and 64-bit) on Windows. 32-bit LabVIEW dies silently in case of the error, whereas 64-bit LabVIEW shows the following report.

2021-02-06_18-36-55.jpg.ebb457b71304b51a07040dadd746625d.jpg

  • Thanks 1
Link to post

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.

×
Followers 2
Go to topic listing

  • Similar Content

    • LogMAN
      LV2019 Set IPE Bug (aka. another way to crash LV)
      By LogMAN
      Here is another bug I discovered in LV2019+ which reliably crashes LV. Simply connect a set to the map input of the Map Get / Replace Value node on the IPE:

      This VI is executable in LV2019 SP1 f3, which means that you can actually build that into an executable without noticing.
      I have reported this, but there is no CAR yet.
    • 0_o
      Investigating LabVIEW Crashes - dmp file
      By 0_o
      Hi,
      My LabVIEW 2016 32 bit is crashing a lot.
      I can guess it is related to:
      1. incompatibility with DAQmx 9.1.5 and the related device driver which I need for LabVIEW 8.5.1 which I also use (NI's support jumped on that issue yet I think it is not related)
      2. an addon that I use to access OpenCV leaving some references open in the dlls
      3. Controls with same label or with no label (I believe that this is the issue -LV can't recover correctly in such cases)
      However, I don't want to guess like NI's support that it is point 1 and do nothing to prove it.
      I expect to see the reason in a log file yet the support wasn't able to show me where to find it.
      Searching around I found the dmp file under documents\LabVIEWdata
      Is that the way to check those crashes or one of you know of a better way to check it beside elimination?
      Thanks in advance
    • The Engineering Bear
      Troubleshooting Crashes and Hangs VI! Any feedback is appreciated
      By The Engineering Bear
      Hey y'all,
      Wanted to look for some feedback on some code I made for troubleshooting crashes and hangs for medium to large LabVIEW applications.  Wanted a way for a user experiencing a crash/hang to have a simple way of narrowing down where the problem is occurring.  The VI is named Crash Logger.vi and it only requires the VI itself to use.  No type def's, additional VI's, or other necessary parts.  The reason for this is so that a user can drop it in multiple parts of their application and have it log the current state and some information on system state to narrow down where a crash/hang is occurring.  I've gotten some feedback from friend's regarding making it a global variable that wrote to variables and had a separate VI to do the logging, but this takes away the "ease of use" I am going for for the user.  I've included an example application to show how it can be used for a simple state machine.
       
      I'd love getting more insight into what I could do better though which is why I'm coming here!  Let me know what y'all think!
       
      - Bear 


       
      Crash Logger Project and VI.zip
      Crash Logger.vi
       
       

    • Zyga
      LabVIEW crashes when calling OpenCV dll
      By Zyga
      Hi everyone. 
      I wrote wrapper in Visual Studio for OpenCV calibrateCamera() function. Every operation like converting 1D array of points to vector<vector<Point2f>>  etc, works ok, except most important thing.
      When function ()calibrateCamera is called, LabVIEW crashes. When this line is commented out, dll works ok (at least labview is still alive). Im out of ideas. I suspect that this is problem with memory management but i dont have an idea where it cames from. Function do not operate directly on data passed from LabVIEW.
      Ultimately I can compile code as exe and call it via cmd, but I'm curious why such a thing appears.
       
      Thanks for your precious time!
      Zyga


      dll source (if you need i can enclose some sample input data):
       
      #include <opencv2/core/core.hpp>
      #include <opencv2/calib3d/calib3d.hpp>
      #include <extcode.h>

      using namespace cv;
      using namespace std;


      static void calcBoardCornerPositions(Size boardSize, float squareSize, vector<Point3f> &corners);
      static void arr2vect(float *APoints,int *Asize, vector<vector<Point2f>> &imagePoints);

      extern "C"
      {
          float __declspec(dllexport)

      Calibrate(float *APoints, int *Asize, int width, int height, float squareSize)
      {
          //initialize variables
          vector<vector<Point2f>> imagePoints;
          Size boardSize;
          boardSize.height = height; boardSize.width = width;
          Mat cameraMatrix = Mat::eye(3, 3, CV_64F), distCoeffs = Mat::zeros(1, 1, CV_64F);
          cameraMatrix.at<double>(0,0) = 1.0;
          vector<Mat> rvecs, tvecs;
          vector<vector<Point3f>> objectPoints(1);
          Size imageSize; imageSize.width = 2040; imageSize.height = 2040;

      arr2vect(APoints, Asize, imagePoints); // prepare imagePoints
      calcBoardCornerPositions(boardSize, squareSize, objectPoints[0]); //prepare objectPoints
      objectPoints.resize(imagePoints.size(),objectPoints[0]);

      //calibrate
      double rms = calibrateCamera(objectPoints, imagePoints, imageSize, cameraMatrix, distCoeffs, rvecs, tvecs);
      return rms;
      }
      }
       
       
      //definitions
      static void arr2vect(float *APoints,int *Asize, vector<vector<Point2f>> &imagePoints)
      {
          int page = *(Asize); int row = *(Asize+1); int col = *(Asize +2);
          Point2f pointBuf;
          vector<Point2f> vectBuf;

          for (int i = 0; i<page; i++)
          {
              for (int j = 0; j<row; j++)
              {
                  pointBuf.x = *(APoints + (i*(row*col))+j*2);
                  pointBuf.y = *(APoints + (i*(row*col))+j*2+1);
                  vectBuf.push_back(pointBuf);
              }
              imagePoints.push_back(vectBuf);
              vectBuf.clear();
          }
          vectBuf.clear();
      }

      static void calcBoardCornerPositions(Size boardSize, float squareSize, vector<Point3f> &corners)
                                          
      {
          corners.clear();
                  for( int i = 0; i < boardSize.height; ++i )
                       for( int j = 0; j < boardSize.width; ++j )
                           corners.push_back(Point3f(float( j*squareSize ), float( i*squareSize ), 0));   

      }
    • ThomasGutzler
      VISA write (read) to USB instruments in parallel crashes LabVIEW
      By ThomasGutzler
      Hi,
       
      I have several USB instruments (Agilent/Keysight optical power meters) which I can talk to via USB.
      To minimise the time "wasted" by transferring data between the instruments and the PC I would like to query them in parallel. Unfortunately, LabVIEW doesn't agree with that strategy and reliably crashes when doing so. It doesn't matter which command I send, so here's a sample snippet, where I just query the instrument ID repeatedly. I don't even have to read the answer back (doing so won't make a difference):

      This will kill LabVIEW 2012 and 2014, both 64bit without even popping up the "We apologize for the inconvenience" crash reporter dialog.
       
      Has anyone had similar experiences?
      I've seen LabVIEW crash while communicating over RS232 (VISA) but it's much harder to reproduce.
        Is it outrageous to assume that communication to separate instruments via different VISA references should work in parallel?
      All my instrument drivers are separate objects. I can ensure that communication to a single type of instrument is done in series by making the vi that does the communication non-reentrant. But I have to communicate with multiple instruments of different types, most of which use some flavour of VISA (RS232, USB, GPIB).
       
      Am I just lucky that I haven't had more crashes when I'm talking to a lot of instruments?
      Could it be a bug specific to the USB part of VISA? I've only recently changed from GPIB to USB on those power meters to get faster data transfer rates. In the past everything went via GPIB, which isn't a parallel communication protocol anyway afaik.
       
      Tom
×
×
  • Create New...

Important Information

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

  I accept