It seemed to be functioning fine until I made some changes to stTepActionCmd structure (actually made it smaller) and I think the memory issues have now come to light.
Coding best practices aside, following the program, where the memory is allocated, it seems to be ok.
is it reasonable to assume that if the data is being copied correctly, data is pointing to the right place?
Online help regarding a page fault seems to suggest the allocated memory is deleted twice, leading to the error. I can’t understand how that could be if I am able to copy the correct data.
Are there tools in B&R which could help me debug this issue as I am complete stumped. I followed the backtrace to this exact point and the issue is repeatable.
but then ‘_tepCmd’ looks like a local variable of this function which is stored on stack and therefore will get lost after leaving the function.
However, it is difficult to understand what you do here.
It is better to switch to smart pointer or standard container.
i believe it is even better to do without heap allocations, as a fragmented heap is not tidied up.
Perhaps there is an expert for the Automation Runtime in the community who can shed more light on this.
What I understand is that _tepCmd is created, we store it’s address in the heap as a Dint in a global variable _feedItem.ItemAddress, then access the data by pointing to the address in another function.
if _tepCmd gets lost after leaving the function, how am I able to access its address and get information from another function?
If i can access the memory then why could there be a page fault when I try to delete it?
_tepCmd is a pointer itself which points then to a heap content
you pass this pointer to ::FeedTapActionCmd()
you then copy the pointer to the local (=stack) ‘_feedItem’
then you copy the content of ‘feedItem’ (including the pointer) to a queue '->FeederQueue
if _tepCmd gets lost after leaving the function, how am I able to access its address and get information from another function?
so even the locals get lost the pointer should go into the queue which is a static variable (e.g. when ‘_pIpmSlot’ really points to the global variable ).
that’s pretty exciting, but it looks still ok.
If i can access the memory then why could there be a page fault when I try to delete it?
Double Deletion: If you try to delete the same memory twice, it can lead to undefined behavior, which might cause your program to crash or behave unpredictably.
Deleting Invalid Pointers: Deleting a pointer that was not allocated with new (e.g., a pointer to a stack variable or a pointer that has already been deleted) also results in undefined behavior.
Memory Corruption: If the memory being deleted has been corrupted (e.g., due to buffer overflows), the behavior of the delete operator is undefined.
a good practice to prevent double deletion is to set the pointer to nullptr after deletion.
fine until I made some changes to stTepActionCmd structure (actually made it smaller)
that could be a hint. You can add some filling bytes for testing and watch if that improves. Could you post the stTepActionCmd structure (class ?)
at address 0x1a24b728 there is data stored in a stTepActionCmd structure.
The program converts 0x1a24b728 into a DINT
Another function uses this as an address for a pointer with structure stTepActionCmd.
The pointer successfully accesses the data
crash when deleting the reference
something is strange here and I followed the code throughout. There is another structure which pretty much does the exact same thing without issues. It is also a smaller structure, if that could somehow be the issue?
the size of the memory that you allocate with ‘new’ must of course be the same as the size that you release again with ‘delete’.
If it is not the same structure, this is of course fatal.
e.g. the type of the pointers must be equal.
+++
struct one {
char mem[10];
};
struct two {
double mem[10];
};
one* buffer = new one();
delete (two*)(buffer); // Undefined behavior
