Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have an array of pointers to pointers:
void ** buckets.
Each of these pointers point to some blob of memory, which contains a pointer to another blob of memory.
I am trying to get at one of the pointers which point to some blob of memory like this:
void *cell = cm->buckets[0] // for the first blob it is pointing to.
However, it is giving me a segfault and the gdb is not very useful. Why is this happening and what is the proper way of handling this case?
Check the address value stored in buckets. Most likely, it has not been initialized (using new, malloc, etc.) and the address inside buckets is some random protected mem address.
buckets[0] is equivalent to *buckets or dereferencing the value inside buckets. So the system tries to access the contents of this protected address causing a segfault.
There are two possible places that may be generating this fault in your example code: cm and buckets. In GDB, before you execute this line, first check cm to make sure it is pointing where you expect it to. If so, make sure buckets is pointing to a reasonable location.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I have an assignment on memory blocks. We have a struct Record that I need to save in these memory blocks. Each block holds 5 Records, which i memcpy one after another in a list of blocks and an int CountOfRecords.
We also have a DeleteRecord function that deletes (duh) a particular record from the memory block. Now, other than reducing the Count and shifting all next Records forward as to practically delete that Record, is there any way to ACTUALLY delete what is written with memcpy? Like writing something like a NULL as a struct instance? Memmove does not seem to offer such an application.
EDIT: I write the records as such
//block is the pointer to block,int is for the Count, and record is placed
memcpy(block+sizeof(int)+sizeof(Record),&record,sizeof(Record));
You basically don't want to move data around but instead set the memory to zero, how about memset?
memset(block+sizeof(int)+sizeof(Record), 0, sizeof(Record));
But you somehow have to remember, that the record at this point is zeroed out (not used), best by some property.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I wondered and still have not found an answer to it.
Its essence is as follows: the address "a" and address a [0]match, But at the same time at the same address are 2 different values.
The name of the array is a pointer to its first element, therefore, in its value has the address "a [0]" and everything is logical here, but when I look at the address "a [0]" it coincides with the address "a". At the same time, the meanings "a" and "a [0]" are different!
Why?!
I can't even count how many C/C++ learners were burnt by this wrong assumption (apparently still taught in schools) that a name of C/C++ built-in array is a pointer to the first element.
This assumption leads to deep misunderstanding and distrust of built-in type system, and it is simply wrong. It is true that in some usage scenarios (a lot of them, actually) the name of array is converted (decayed it is said) to the address of the first element. But it is a conversion.
The truth is, the first element of the array resides in a certain address. If you get an address of this first element, you will end up with a pointer to the first element type. If you get an address of the array itself, you will get a pointer to the array, it is a different pointer type.
The fact that those two pointers might have the same byte representation (i.e. point to the same physical memory) is irrelevant and moot. The sooner you understand and accept it, the fewer "why why why" experiences you will live through.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I am trying to inject executable code in memory using C. The executable should be able to read it's own code and copy it to some other location referenced by a pointer. The general template code is as follows
int
main(){
int (*main_ptr)();
main_ptr=main; // make the pointer point to start of main
/*
* rest of the code.
*
*/
/*Now I am trying to print the first 10 bytes of the main function.
* just to see if it is possible to access main's code.
*/
for(int i=0;i<10;i++)
printf("%x ",*main_ptr++);
return 0;
}
but the output is the value of the pointer (i.e. address of main function), not the value to which it points (the code of the main function). I had read somewhere that C does not dereference function pointers. But I do not know why. Is there a way to get around this?
Or, is there another way for a program to access its own code section?
P.S. I understand that many may think this is a stupid question and does not contribute significantly to research and all that. But I'am trying to understand how malware is written and given the absence of material on the web, it has been frustrating, so I decided to try this myself. Any help would be great.
There are 2 issue with your code (even though as such it is UB to be strict).
But even from any implementations point of view there are the following issues
None of the implementations define the * operator for function pointer.
None of the implementations define the ++ operator on the function pointers because size of a function is not defined.
But most implementations do define casting a fptr to void* and then to other data pointers even though it is UB.
You can make use of that fact.
I tried the simple modification of your code -
for(i=0;i<10;i++)
printf("%x ",*((int*)main_ptr++));
And it produced the "expected" behavior with gcc (MinGW64), compared the output against objdump.
Finally this goes with the warning that none of the approaches are portable. Perhaps there is no portable way to achieve what you are doing.
If you just have to get the same code as main, one way could be to read the actual binary (pointed by arg[0]). Parse the headers to find main and then read the bytes from there. Since reading the file would give you a data pointer there is no UB there.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What is the main reason to use function returning pointer? Basically its return the pointer value but there are we can also return the value through pointer.
So why we need function returning pointer?? Is it reduce the size of code or any else?
Is there any application where we use function returning pointer?
Not sure what you are asking but yes? you could copy a 2Gb variable or an address to that variable that is orders of magnitude smaller. You tell me which is quicker/more efficient ;)
Here is a tutorial that explains their usage:
C pointers
Right off the bat it explains how it is easy to use numbers to lookup a safety deposit box so you can go access it.
without the ability to return pointers there would be no point to even having pointers at all. i.e. when you allocated memory for data, a function returns the pointer to its location. So without that you would never know were the memory you allocated is.
So I guess the functionality of returning pointers is arguably to allow the presence of pointers themselves?
One example, you can return a pointer to a value. Anyone who has that pointer can then change the value.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I pasted my code here: http://pastebin.com/tPvRHrkW
Compiled with gcc.
It seems the error occurred because I defined a struct too big for the compiler. I took the struct out into another single source file and tested it, no error occurred this time. So why am I getting SIGSEGV and is there any limit on the size of a struct?
There isn't a limit to the size of the struct, the problem is with how you're using it. MGraph is the huge structure type, and in two places you're using it in a manner that places it on the stack; once as a parameter to a function and again as a local variable. Stack space is often not something that is permitted to grow to huge proportions.
I would suggest two changes. First, use dynamic allocation for instances of this type. Second, pass pointers as parameters to it, rather than the actual data.
Generally you're only limited by available memory and the addressing capabilities of your system. However in your case you're declaring a local variable, which will be allocated on the stack. The stack is likely much more limited in capacity.
#define MAXV 20000 .. int edges[MAXV][MAXV];
is 20000 * 20000 * 4 ~ 1.5 Gigs of memory on stack.
You should probably use malloc & dynamically allocate instead.