LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Program pauses at RunUserInterface with HEAP error

Hello everyone, 

I am working on an app for automating a test bench. I have different threads for different functions (execution of test, speed control, pressure control, security system, ...). 

The main function contains the RunUserInterface call, and I have an other file with all the callbacks and other functions.

In each thread, I call the ProcessSystemEvents function for multithreading.

 

My problem is that when I execute a certain test, not for all tests, the program pauses on the RunUserInterface of my main function, like if it was a breakpoint, but without emitting any error. When I analyse the Debug Output, I saw that it is accompied by one of the following messages depending on the situation : 

HEAP[ACASYA.exe]: Invalid address specified to RtlFreeHeap( 01220000, 12618118 )

HEAP[ACASYA.exe]: HEAP: Free Heap block 128109B8 modified at 128109C8 after it was freed

This problem does not always occur in the same place of the code. 

At the moment, even with a lot of analysis, I couldn't find exactly where the error was occurring. It doesn't seem to be in any particular thread or function.

 

I'm open to any solutions, leads or ideas that might help me.

 

Thanks in advance for your help!

 

PS : I am working on LabWindows CVI 2015 Version 15.0.1.

0 Kudos
Message 1 of 8
(2,487 Views)

Have you tried to match the address given in the error message with the map file that can be generated during compilation? The map file gives the starting address of each function so you can narrow the origin of error on a particular function.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
Message 2 of 8
(2,429 Views)

Thank you Roberto for your answer.

I just tried this. I had this error message "HEAP[ACASYA.exe]: Invalid address specified to RtlFreeHeap( 01290000, 12A53818 )"

But the fact is that in the MAP file generated, addresses are from 00401000 (for the first function) to 0105A195 (for the last function) while the addresses in the error message are 01290000 and 12A53818.

I don't know what to make of it.

0 Kudos
Message 3 of 8
(2,404 Views)

I see! RtlFreeHeap is not mentioned in the map file: are you actually calling it anywhere in the code? If not, it may be called internally by some other function so it is not mapped.

From the text of the error is seems that some memory manipulation occurs after the block is freed, but this could be handled internally by some library you are using: if this is your situation you can only double check that you are not freeing some memory block on your own out of library control.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
Message 4 of 8
(2,394 Views)

Yes I did not mention that but I do not use the function RtlFreeHeap() in my code. And it is why it is difficult for me to know what is the origin of this error. 

I agree with the fact that this error is from a memory manipulation after a block has been freed. 

But in my code there is just about twenty calls to malloc() and free() functions. So it's easy to see if I use well the heap memory. And I do not see any problem with these uses.

So I am totally lost now. I tried a lot of things to find origin of this error but I haven't found anything.

0 Kudos
Message 5 of 8
(2,386 Views)

Hi

 

Try to drop the function ProcessSystemEvents() in the threads.

I saw in some apps that this can be the race conditions you are experiencing

 

Gabel Daniel

Message 6 of 8
(2,272 Views)

Hi Gabel,

Thank you for your answer!

I just tried to do it, but this is the same, the error occurs and the program stops... It changes nothing 😞

Yohan

0 Kudos
Message 7 of 8
(2,264 Views)

malloc() and free() are C runtime functions. But ultimately both in the Microsoft Visual C runtime library as well as in other alternate C runtime libraries, they call into the Windows Heap manager with HeapAlloc() and HeapFree(), which in turn call the actual RtlAllocHeap() and RtlFreeHeap() functions. So your calls of malloc() and free() are not yet out of the potential suspect list!

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 8
(2,075 Views)