Thread: use of printf prevents segfault!

I'm writing a function that takes a file, reads the file into a buffer while keeping count of the lines, then takes each line and plugs the content into a simple structure. I did it that way because the number of lines is variable and will determine, obviously, the number of structs needed. So I get the number of lines (nofl) and in the middle of the function do this:

struct thestruct new[nofl];

I was getting a segfault, so to make sure nofl was correct, i inserted the following line RIGHT BEFORE the last one:

printf("--%d--\n", nofl);

AND NOW NO SEGFAULT!!! Nothing else is changed, but adding and subtracting that one line makes all the difference. Really, really, really. More observations:
1) Up until now I've been declaring variables (inc. structs) at the beginning of a function, but I've never heard tell that it must be so. Does this have anything to do with it?
2) The segfault actually occurs later when new[1] (ie. the 2nd struct in the array) is called on (it turns out not to exist).
3) "nofl" is determined on the line immediately preceeding the printf statement.
4) if I put the printf statement after the struct declaration, the segfault returns.

Sounds like a classic stack corruption. Can you post your code?

QuantumPete

Originally Posted by QuantumPete

Sounds like a classic stack corruption. Can you post your code?

QuantumPete

Or quite possibly writing over the end of your allocated data at some point previously.

When problems change due to "irrelevant" changes in the code, it's usually because you are going across the line of some memory - adding/changing the code around will move the actual bits of memory used by different pieces of code, so the problem "moves", but it's actually not fixed, it's just overwriting something less harmful.

For example, calling printf will make sure the variable is stored on the stack, whilst not calling printf will not use the stack to store the local variable - so some bytes less used on the stack, so when you overwrite the end of an array, it no longer overwrites the variable, but some important data [such as the frame pointer or return address of the function].

--
Mats

Originally Posted by matsp

Or quite possibly writing over the end of your allocated data at some point previously.

My money is still on stack corruption

QuantumPete

Originally Posted by QuantumPete

My money is still on stack corruption

QuantumPete

Not at all saying you are wrong. Only reason I said overwriting dynamically allocated memory is that it's happening in new - but that's no good indication really.

--
Mats

Originally Posted by matsp

it's happening in new

It looks to me like the variable is called new (how that got by the compiler I don't know), no dynamic allocation.

QuantumPete

Originally Posted by MK27

In the meantime I heartily recommend people try ray[] for themselves...

nofl so far is less than 100.

hmm... I suggest that you post a minimal example of what is actually in the [...].

I see two possibilities: you are accessing your array out of bounds but escaping unscathed by luck, or the C99 variable length array language feature is at work. If it is the latter, fine, but if it is the former, then you may pay a heavy price for your mistake in the future.

Originally Posted by laserlight

hmm... I suggest that you post a minimal example of what is actually in the [...].

I see two possibilities: you are accessing your array out of bounds but escaping unscathed by luck, or the C99 variable length array language feature is at work. If it is the latter, fine, but if it is the former, then you may pay a heavy price for your mistake in the future.

Since it is a global variable, I expect that it won't be "variable length array". And the warning the compiler gives is explcitly saying that it's giving a size of 1 - so there is only one element in the array called ray.

--
Mats

I'm not sure what matsp's example is suppose to demonstrate -- that "accessing ray[]" will corrupt the other array? Why? Because the compiler handles arrays in the same way and hence the best chance of an overwrite is with another array?

You & laserlight could be right about this, I'll let you know when my tish fits the hand. I'm not sure if ray[] will count in C99 "variable length array":
http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
But at least there's the possibility...boldly going and all that...

[...] includes the determination of nofl (to recap: I'm doing what must be a common task -- reading a text file of indeterminate length, each line of which (eg. "name number section") is translated into a struct. I guess I could set ray[10000] or something.

But as of yet, there's no problem...and this is in a gtk_main() context, so there's a lot of storage going on...

I may have to investigate this "pragma" thing.

nofl IS NOT global, and if you think about reading lines not, perhaps, even necessary. The warning about size of one is probably because ray[] appears to have no size at all. But in the for (i) loop, ray[i] does function and retain it's value globally.

ps. my point about the warnings intrinsic to compiling, eg. the linux kernel and C libraries, would be that even the people who built all this can't seem to get rid of them. The one with strcasestr is:

warning: assignment makes pointer from integer without a cast

which doesn't appear with strstr (tho their use is identical).

Regarding what you example is supposed to show: I choose an array because that the simplest way to create a few variables worth of memory that I could write some "pattern" to. Did you actually try to implement that?

Your code probably will crash when you reach the next 4K boundary of ray - since we don't know what ray contains, it's impossible to predict when that would happen (and it may well be that other data is stored AFTER ray, and that it just happens that overwriting that causes nothing bad that you can detect). This is the problem with undefined behaviour - it's like crossing the road when "don't walk"/"red man" showing - some days you'd get across the road fine, other days you'd get run over by a bus, and further other days, Police Constable Plod grabs you by the collar and tells you off [yeah, ok, that's unlikely - but still...].

As to strcasestr(), are you sure you added the red part in your source code?

Code:

#define _GNU_SOURCE
#include <string.h>

--
Mats

nofl IS NOT global, and if you think about reading lines not, perhaps, even necessary. The warning about size of one is probably because ray[] appears to have no size at all. But in the for (i) loop, ray[i] does function and retain it's value globally.

Based on the available information (I still cannot fully understand variable length arrays as specified by C99 just by reading C99), I think matsp is right. ray is a global, so variable length arrays do not come into play here (from what I understand, the length of a variable length array is fixed for the duration of its lifetime: the length is variable in the sense that it is not fixed at compile time). Therefore it is just an array of length 1, in which case you have a case of array out of bounds access, which is a Bad Thing.

Okay! I tried it and matsp WAS WRONG!

Code:

#include <stdio.h>

struct thest {
        int one;
        int two;
} ray[];
int array[10];

int main () {   
        int i;
        for (i=0; i<10; i++) {
                array[i] = i*3;
        }   
        for (i=0; i<=4; i++) {
                ray[i].one = i;
                ray[i].two = i*2;
        }   
        for (i=0; i<=4; i++) printf("ray[&#37;d]: %d\t%d\n", i,ray[i].one,ray[i].two);
        for (i=0; i<10; i++) {
                if (array[i] != i*3) printf("array[%d] isn't %d, it's %d...\n",i,i*3,array[i]);
                else puts("No problem");
        }
}

Sorry the "code" tags don't work here (?!?). But the output is:

Code:

ray[0]: 0       0
ray[1]: 1       2
ray[2]: 2       4
ray[3]: 3       6
ray[4]: 4       8
No problem
No problem
No problem
No problem
No problem
No problem
No problem
No problem
No problem
No problem

But I clearly haven't hit a 4k boundary yet. Also,
#define _GNU_SOURCE
didn't make any difference with strcasestr.

Of course, now all subsequent unexplained segfaults will leave me paranoid...

Originally Posted by MK27

Okay! I tried it and matsp WAS WRONG!

Erm, actually, no he's not. It's up to the compiler how to arrange your variables in memory and it could well have put array before ray. Maybe because it arranges them by descending size or because of alignment. Pick a different compiler and you may well get a different result.

QuantumPete