tNIHeapPageManager.cpp Error

[Bob_Y.]

We have an RMC 8353. We have a custom LabVIEW application that is actually similar to VeriStand running on it. It was build before VeriStand was available. Over the weekend, we were reconfiguring some of the software on it and we got an error to show up on its display that I have not seen before. I am sure it is not from our software and I am not sure what caused it.

The error is

"

build\nimm\tNIHeapPageManager.cpp: 568

"

So it is a memory manager problem. Is there any way to tell what we did to get this? or is it a hardware issue?

It has shown up twice, but our software still seems to behave as expected. We are looking for confirmation that our system is not in danger of complete failure. Or that it is. . .

Thanks

Bob Young

[Lea_D]

Hey Bob,

I believe you're using RT. Is this correct?

I've been looking through some stuff on the system about this error and found something about it. It looks like "build\nimm\tNIHeapPageManager.cpp: 568" is an error that is thwon when a pointer is freed that has already been free'd and is non-Null. This is a non-fatal error.

However, I also found some instances where several of these errors repeating in one file caused a crash (the log file had several of these errors accumulating). I'd try cleaning some things up and making sure these values are only being freed once. Additionally, it would be a good idea to keep conscience if this error starts to accumulate and be aware to only free the HEAP memory once instead of multiple times.

I think this isn't an issue with the hardware itself, and I wouldn't expect a complete hardware failure. 

[Lea_D]

Hey Bob,

I believe you're using RT. Is this correct?

I've been looking through some stuff on the system about this error and found something about it. It looks like "build\nimm\tNIHeapPageManager.cpp: 568" is an error that is thwon when a pointer is freed that has already been free'd and is non-Null. This is a non-fatal error.

However, I also found some instances where several of these errors repeating in one file caused a crash (the log file had several of these errors accumulating). I'd try cleaning some things up and making sure these values are only being freed once. Additionally, it would be a good idea to keep conscience if this error starts to accumulate and be aware to only free the HEAP memory once instead of multiple times.

I think this isn't an issue with the hardware itself, and I wouldn't expect a complete hardware failure. 

[Bob_Y.]

Lea,

That is correct. It is an RT system with the application built in LabVIEW 2010 RT. I am not aware of how to free HEAP memory and let LabVIEW take care of all of that.

Unless maybe you mean closing refnums . . .

Thanks,

Bob Young

[Texas_Diaz]

Obviously the error with HEAP memory is in the bowels of the OS, where someone (who knows?) tried freeing memory that has already been free'd.  This can happen with any memory allocation/free that's happening due to LabVIEW code (e.g. opening/closing references), external code nodes, or library calls.  Usually when something like this happens, someone needs to check their references/pointers/allocations.  

-Danny