This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
The following is a part of a function.
l->length[l->cl] = atoi(p->wds[p->cw]);
printf("FD %d\n", l->length[l->cl]);
p->cw = p->cw + 1;
l->cl = l->cl + 1;
printf("prevent from seg fault\n");
instr(p);
If I remove the printf("prevent from seg fault\n"); I get segmentation fault, but if I keep it it runs and go to the nest function and so on.
So my question is just in general why does this happen, I know I am not showing enough of my code so you can see why the segmentation happen, but if there is any general explanation for this, I also had this in another place in my program but at the end I could remove it?
Regards Orri
As far as the standard is concerned any changes made to a program that invokes undefined behaviour can have any result - there doesn't have to be a logic behind it. And in fact it is very seldom fruitful to try to reason about how a given implementation behaves when encountering undefined behaviour.
That said if a call to printf (or any other function) changes the behaviour of your program (beyond the obvious change of printing what it's supposed to, of course), one possible explanation is that you have an invalid pointer somewhere that points to a local variable that's out of scope. If that variable previously lived in the stack memory that's now used by printf for its own local variables, that means the memory that the pointer points to will now be overridden with a new value. And that can of course change the behaviour of any code that use the pointer.
Related
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm a newbie programmer
//allocating space for final output
//text_count is given by another function, let's just say i have a value for it
//out is my typedef struct
out *fin[text_count];
for(i=0; i<text_count; i++){
fin[i] = malloc(sizeof(out));
}
//this is a test
fin[1]->appearances = 1;
printf("%d",fin[1]->appearances);
// ..other code
I noticed that after this allocation, program suddenly outputs this:
1_
The underscore is blinking, indicating it needs an input.
What can be my problem here? Is it the allocation? Or the codes down below?
okay sorry, let me clarify this, im using codeblocks . so when i get a blinking cursor it means it needs an input. and after i got this output, an infinite loop of inputs seems to be happening.
You're simply seeing the text terminal's cursor. It may be blinking or it may not, that doesn't mean anything in itself.
You might want to add a linefeed:
printf("%d\n", fi[1]->appearances);
to get the output on a line of its own.
A cursor after your printf does not mean, that it is waiting for input.
You can confirm this, by using strace, if it is waiting at read syscall.
Usage:
strace ./myApplication arg1 arg2...
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
char * input = (char*)malloc(256);
scanf("%s", input);
Seg fault. Why? I have a lot of trouble with strings in C, but I feel like everything is done right here. I even followed an example from a 100k+ SO user to the letter.
The bug could be caused by:
malloc() failing to allocate any memory, check the result against NULL.
by a buffer overrun from scanf, more than 256 characters.
by forgetting to include <stdlib.h> and then typecasting the result of malloc. More info here.
You need to ensure your buffer is large enough, including enough space for the trailing NUL (0 byte) at the end of the string. Otherwise, you get a buffer overflow that may lead to a segfault.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
Sorry if my problem is not very clear.
I've a structure like this:
typedef struct
{
uint32_t typeSet;
}DataTypeTagInfo;
The following function is for unifying two typeSet:
DataTypeTagInfo* unifyTagInfo(DataTypeTagInfo* tag1, DataTypeTagInfo* tag2){
if(tag1 == NULL) return tag2;
else if(tag2 == NULL) return tag1;
tag1->typeSet |= tag2->typeSet;
return tag1;
}
The program exits while executing the following line:
tag1->typeSet |= tag2->typeSet;
On a sample run I've following value:
tag1->typeSet = 3917954189
tag2->typeSet = 2536589
There is no error message. Just quits. Please help.
The code you show is perfectly sound. Consequently, it's very likely that either tag1 or tag2 is an invalid pointer at the time of the abort. This will have nothing to do with the code you've posted. The pointers could be set invalid in many, many ways.
To figure out what's happening, I'd start with a careful review of the code setting tag1 and tag2 at the call site and then - if the answer does not appear - move on to using valgrind to check for memory overwrite errors.
NB this what makes C(++) so challenging.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm using the PellesC C compiler. Sometimes my code randomly stops working. A particular statement can trigger it. For example, I multiplied a variable by sin(c) (c is a double) and my code seemed to just finish execution with no result. Sometimes it freezes, sometimes it appears to just return, but I can always fix it by removing the offending statement or disabling compiler optimizations, specifically "maximize speed" or "maximize speed more". The freezing will also go away nearly 100% of the time if I add a printf statement somewhere near the point at which it crashes. I've never found anything to suggest that I am accessing memory improperly, I'm fairly sure its a compiler issue. I was wondering if anybody could shed some light on this. Is it possible that I am, in fact, doing something wrong? Or is this a known issue with the Pelles C compiler?
Edit:
Changing
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+2]=(unsigned char)(255.0*dtempA*(1-sin(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+1]=(unsigned char)(255.0*dtempA*(1+cos(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)]=(unsigned char)(255.0*dtempA*(1+sin(c)));
to (difference at the end of the last line)
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+2]=(unsigned char)(255.0*dtempA*(1-sin(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+1]=(unsigned char)(255.0*dtempA*(1+cos(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)]=(unsigned char)(255.0*dtempA*(1+1));
makes it work.
It could be either but a good bet is that it's you :) Variables that are not explicitly initialized will often get different values in a optimized vs an un-optimized build because the stack layout can change subtly depending on how aggressively the compiler removes temporaries, as well as other factors.
You're probably accidentally using undefined behavior somewhere, and changing random instructions in the program is breaking the very fragile alignment of the code on the stack that happens to make the program work.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have made a program in which I am handling files but I am getting this error
(I have run it through gdb)
Program received signal SIGSEGV, Segmentation fault.
0x0016e50b in vfprintf () from /lib/tls/i686/cmov/libc.so.6
I am not getting the exact line that contain error.
Can anybody tell me
what this error means
does it occur for any special reason
or is it general error occurring because of many reason?
What does this error mean?
It basically means that you're accessing memory that you're not supposed to be accessing.
Does it occur for any special reason?
A segmentation violation can occur for a huge number of reasons. However, since it's happening in vfprintf, it's likely to be limited to something like:
Invalid file pointer.
Not passing enough parameters for the format string.
Passing a NULL pointer for a C string.
Passing a non-null-terminated pointer for a C string.
Memory corruption from a totally different part of the program.
That's the most likely reasons.
Or is it a general error occurring because of many reasons?
As I said, it can occur for a vast number of reasons but it's probavly limited based on your circumstances.
Check all of the parameters before calling the printf call (not with printf of course, use some more robust debugging code such as printing each character of a string with flushing and fsyncing after each). And check that the file handle is valid and that the number of parameters passed to vprintf matches those specified in the format string.