K
kj
I am trying to diagnose a bug in my code, but I can't understand
what's going on. I've narrowed things down to this:
I have a function, say foo, whose signature looks something like:
int foo( int w, int x, int y, int z, my_struct **results )
During its execution, foo initializes *results using calloc:
( *results ) = calloc( w+1, sizeof( my_struct ) );
and proceeds to fill the resulting array of my_struct's, keeping
track of how many elements of *results it has filled in some int
variable v. At the very end, right before returning, foo uses
realloc like this
realloc( *results, v * sizeof( my_struct ) );
and then foo returns v.
In normal operation, the value of w remains constant, and v never
exceeds w+1 (an assert statement ensures this). In the particular
test runs discussed below, w+1 always equals 2, and in the realloc
statement v also equals 2, always; therefore, if I understand
realloc correctly, in these test runs the realloc should not change
the amount of memory allocated to *result. (But somehow the realloc
is doing something that Electric Fence (EF) doesn't like...)
If before and after the realloc line above I insert *identical*
printf statements, like this:
printf( "%d\n", ( *results )->some_field ); /* always OK */
realloc( *results, v * sizeof( my_struct ) );
printf( "%d\n", ( *results )->some_field ); /* segfault under EF */
both printfs execute and the expected values get printed, but if
I compile with Electric Fence (-lefence) and re-run the program,
it fails with a segfault at the second printf, right after the
realloc.
(My compiler is gcc 3.3.5; I don't know how to determine the version
of EF that we have on our system, though the man page says 1993,
so I gather it's pretty ancient.)
I am very puzzled by the results described above. What am I doing
wrong? As mentioned above, the value of v is 2, so, if realloc
worked correctly, why would the second printf produce a segfault?
Is there anything better (and preferably free or cheap) than Electric
Fence to pinpoint the problem?
Thanks!
kj
what's going on. I've narrowed things down to this:
I have a function, say foo, whose signature looks something like:
int foo( int w, int x, int y, int z, my_struct **results )
During its execution, foo initializes *results using calloc:
( *results ) = calloc( w+1, sizeof( my_struct ) );
and proceeds to fill the resulting array of my_struct's, keeping
track of how many elements of *results it has filled in some int
variable v. At the very end, right before returning, foo uses
realloc like this
realloc( *results, v * sizeof( my_struct ) );
and then foo returns v.
In normal operation, the value of w remains constant, and v never
exceeds w+1 (an assert statement ensures this). In the particular
test runs discussed below, w+1 always equals 2, and in the realloc
statement v also equals 2, always; therefore, if I understand
realloc correctly, in these test runs the realloc should not change
the amount of memory allocated to *result. (But somehow the realloc
is doing something that Electric Fence (EF) doesn't like...)
If before and after the realloc line above I insert *identical*
printf statements, like this:
printf( "%d\n", ( *results )->some_field ); /* always OK */
realloc( *results, v * sizeof( my_struct ) );
printf( "%d\n", ( *results )->some_field ); /* segfault under EF */
both printfs execute and the expected values get printed, but if
I compile with Electric Fence (-lefence) and re-run the program,
it fails with a segfault at the second printf, right after the
realloc.
(My compiler is gcc 3.3.5; I don't know how to determine the version
of EF that we have on our system, though the man page says 1993,
so I gather it's pretty ancient.)
I am very puzzled by the results described above. What am I doing
wrong? As mentioned above, the value of v is 2, so, if realloc
worked correctly, why would the second printf produce a segfault?
Is there anything better (and preferably free or cheap) than Electric
Fence to pinpoint the problem?
Thanks!
kj