How is the array stored in memory?

Question

In order to deepen my understanding of how memory is allocated and stored, I wrote an application that can scan the address space of a memory, find a value, and write a new value.

I developed an example application with the ultimate goal to be able to programmatically find my array and overwrite it with a new sequence of numbers. In this situation, I created a one-dimensional array with 5 elements, for example

int[] array = new int[] {8,7,6,5,4}; 

I started the application and looked for a sequence of five numbers above. I searched for any value that fell between 4 and 8, for a total of 5 numbers in a row. Unfortunately, my consecutive numbers in the array corresponded to hundreds of results, since the numbers 4 through 8, not a single specific sequence, were located next to each other in memory in many situations.

Is there a way to distinguish a set of numbers in memory, is an array, and not integers that are next to each other? Is there any way to find out that if I find a specific value, that the corresponding values ​​correspond to an array?

I would suggest that when I declare an int[] array , it points to the first address of my array, which will provide some kind of metadata to what existed in the array, for example

 0x123456789 meta-data, 5 - 32 bit integers 0x123456789 + 32 "8" 0x123456789 + 64 "7" 0x123456789 + 96 "6" 0x123456789 + 128 "5" 0x123456789 + 160 "4" 

How do I retreat from the base?

Answer 1

Debugging + Windows + Memory + Memory 1, set the "Address" field to "array". You will see this when you switch the view to a "4-byte integer":

 0x018416BC 6feb2c84 00000005 00000008 00000007 00000006 00000005 00000004 

The first address is the address of the object in the garbage heap collected, as well as the part of the object header with a negative offset (syncblk index). You cannot guess this value, GC moves it. The second hexadecimal number is the "type descriptor" for the array type (method table pointer). You cannot guess this value; type descriptors are created at the request of the CLR. The third number is the length of the array. The rest of them are the values ​​of the elements of the array.

The chances of reliably finding this array at runtime without a debugger are pretty low. It makes no sense to try.

Answer 2

not to do. The array is stored on the heap and is being reinstalled due to garbage collection. You should use fixed if you need to make sure that the memory is not moved, which you can use, but only very carefully.

If you use high-performance arrays, use stackalloc and use your code scheme.

Answer 3

The memory is not always stored permanently. If you can be sure that this is so, then what you are asking is possible.

Answer 4

I don’t know for sure, but this article seems to suggest you get a pointer to your array with which I would think that you can determine the actual address.

Answer 5

Although I see that you are using C # and, presumably, .NET, most of your question in general terms is about memory. Keep in mind that in the most general sense, all memory is just bits if that memory contains an array, strings, or code.

Given this, if you cannot find the telltale signs of your current way of placing different types of data, there is no difference between memory containing arrays, strings, or code.

In addition, I would not make any assumptions about if the array "points" to the first element of the array. Maybe someone else can solve this problem on purpose, but I would suggest that some kind of header is involved.