12-14-2016 09:17 AM
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.
12-14-2016 09:50 AM
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>
12-14-2016 12:06 PM
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).
12-15-2016 01:34 AM - edited 12-15-2016 01:35 AM
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?
12-15-2016 11:13 AM
@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
12-15-2016 12:24 PM
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.
12-16-2016 04:23 AM
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).
12-16-2016 10:51 AM
@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. 🙂