Internal warnings after LabVIEW upgrade

[vix]

I've just upgraded LabVIEW to version 16 and mass compiled and rebuilt a project previously developed with LV 2014.

As often happens after an upgrade of LV, the Internal Warning Reporter lists some warnings when I quit from LabVIEW. These warnings are listed every time I quit from LV after having worked on the project.

I send the report to NI (I did so many times in the past, but I haven't received any feedback from NI), but this behavior is quite annoying.

I wonder if there is a way to investigate these warnings and to detect if I should fix somehow my LV code or they come form a bug of LV.

[vix]

I forgot:

the warnings are a lot of DWARN in some .cpp files

As an example

<DEBUG_OUTPUT>
14/12/2016 15:36:42.220
DWarn 0x9A3507AE: FPDCO::DataPtr called before m_data was initialized
e:\builds\penguin\labview\branches\2016\dev\source\heapobjs\FPDCO.cpp(676) : DWarn 0x9A3507AE: FPDCO::DataPtr called before m_data was initialized
minidump id: bd0f07f8-9cdc-42ca-b975-fea8988aeeae
$Id: //labview/branches/2016/dev/source/heapobjs/FPDCO.cpp#8 $

</DEBUG_OUTPUT>

[Ben]

there is a tool called Heappeak (or something like that) that I have read about people using but I was never interested enough to spend time diggind into it.

If you can fix it by loading the entire project again and doing another mass-compile then I would pass the code to NI, let them figure out what is wrong and work from there. I would hope they would be interested in code that can repeatedly throw an error like that.

OR

You can start throwing away parts of what looks to be part of a GUI until you find the corrupted control/indicator (just guessing based on the"FPDCO.cpp" in the erro report).

[vix]

Hi Ben,

in the past I've already used the Heap Peak internal debug tool for a similar problem (an old project developed in LV 6 for Linux ported to LV 8.2 for Windows), but it was not so useful. In that case the NI support answered that it was a cosmetic element of one of the clusters on the front panel, but it was impossible to find which one.

That project was really big so I must keep that behavior.

If you can fix it by loading the entire project again and doing another mass-compile then I would pass the code to NI, let them figure out what is wrong and work from there. I would hope they would be interested in code that can repeatedly throw an error like that.

A new mass-compile didn't help, and I'm not sure if NI is interested in this kind of code (since they know I have this kind of code since I ported a project from LV 6 to LV 8.2). Maybe this time will be different...

This time the messages are quite different: they don't refer to a .vi file but to the underlying c++ files and functions.

I hope NI can analyze the internal reports I send them, but I don't know if they can send me a feedback.

Moreover I see they are warning (and not errors), but is it safe for me to release my software rebuilt with LV 2016? Or should I stay with LV 2015 SP1 in the meanwhile?

[Ben]

---

@vix wrote:

Hi Ben,

...

Moreover I see they are warning (and not errors), but is it safe for me to release my software rebuilt with LV 2016? Or should I stay with LV 2015 SP1 in the meanwhile?

---

"a little birdie" tells me "Do not go gentle into that good night". Let the dust settle a bit.

All I can say (nudge, nudge, wink, wink) (Monty Python)

Ben

[billko]

Was there some compelling reason to upgrade and work on the old project in the new version?  Hint: "Just 'cuz" is rarely a good reason.  Take whatever risks you want at home, but if you are in a business environment, "If it ain't broke, don't fix it," is a good rule of thumb.  The last thing you want to do is introduce unknowns into a stable environment.  I would revert back to the last known good software revision and continue to work on it in the old LV version.

[vix]

---

Was there some compelling reason to upgrade and work on the old project in the new version?

---

The project is old because it started several years ago, but it is under active development.

Since the customer installs this application on his own PC, I need to be up-to-date with the support of new OS. In the past I had a lot of problems when a LabVIEW application runs on an OS not officially supported by that LV version.

And so, every time a LV version is released, I open a new branch in my git repository and I started a test phase to decide if (after some months) the application can be ported to the new LV.

In this way, when I found bugs or strange behaviors, I have time to investigate and/or report to NI. This is why I would like a NI feedback for the reports automatically sent by LV.

If you do the porting when a customer need forces you, you can only pray that the porting goes smooths. Otherwise you're in a big trouble (time problem, that means money problem).

From my side, this is the best approach, but it is the best compromise (but it's only my opinion).

[billko]

---

@vix wrote:

---

Was there some compelling reason to upgrade and work on the old project in the new version?

---

The project is old because it started several years ago, but it is under active development.

Since the customer installs this application on his own PC, I need to be up-to-date with the support of new OS. In the past I had a lot of problems when a LabVIEW application runs on an OS not officially supported by that LV version.

And so, every time a LV version is released, I open a new branch in my git repository and I started a test phase to decide if (after some months) the application can be ported to the new LV.

In this way, when I found bugs or strange behaviors, I have time to investigate and/or report to NI. This is why I would like a NI feedback for the reports automatically sent by LV.

If you do the porting when a customer need forces you, you can only pray that the porting goes smooths. Otherwise you're in a big trouble (time problem, that means money problem).

From my side, this is the best approach, but it is the best compromise (but it's only my opinion).

---

This is about the best reason I can come up with.  I was hoping to hear that kind of an answer.  🙂