seg fault and I don't know where

[James Leddy]

Hello,

I am making a program that encrypts and compresses plain text and indexes
them by date.

Needless to say, I have many alloc(), realloc(), calloc(), and free() calls.
There are also double pointers all over the place.

The program works fine except for one tiny detail. Every time I try to
extract a file, the program terminates with a segmentation fault. I used
the debugger and discovered that the segmentation fault did not occur
because of an out of bounds error or anything. The segmentation fault
occurs when the program exits.

I thought that the problem was that I did not free() some block of memory
that I had previousally allocated. I checked and made sure that I had
free()d all the memory.

Could someone possibly offer an explanition as to why this keeps happening?

Thanks,

[Artie Gold]

James Leddy wrote:

Hello,

I am making a program that encrypts and compresses plain text and indexes
them by date.

Needless to say, I have many alloc(), realloc(), calloc(), and free() calls.
There are also double pointers all over the place.

The program works fine except for one tiny detail. Every time I try to
extract a file, the program terminates with a segmentation fault. I used
the debugger and discovered that the segmentation fault did not occur
because of an out of bounds error or anything. The segmentation fault
occurs when the program exits.
Ah, but most likely it *is* an `out of bounds' situation -- just not
one that causes a crash when you exceeded the bounds of a buffer,
but at the point where whatever you overwrote was used.

I thought that the problem was that I did not free() some block of memory
that I had previousally allocated. I checked and made sure that I had
free()d all the memory.
Failure to free() allocated memory may be a Bad Thing, but will not
cause a program to crash.

Could someone possibly offer an explanition as to why this keeps happening?

Show us the smallest compilable snippet that exhibits the problem
and someone, no doubt, will.

HTH,
--ag
--
Artie Gold -- Austin, Texas
Oh, for the good old days of regular old SPAM.

[Gordon Burditt]

>I thought that the problem was that I did not free() some block of memory

that I had previousally allocated. I checked and made sure that I had
free()d all the memory.

It is unlikely that a segmentation fault would be caused by failure
to free memory you allocated. (Standards wizards: I think a
segfault for failure to free memory would not be allowed, as this
failure doesn't invoke undefined behavior. Opinions?)

It is quite possible that a segmentation fault would be caused
by free()ing something you DIDN'T allocate (with malloc & friends).
So could stomping on the malloc() arena caused by using more
memory than you actually allocated.

Gordon L. Burditt

[Noah Roberts]

James Leddy wrote:

Could someone possibly offer an explanition as to why this keeps happening?
You are derefrencing the NULL pointer on line 42.
Thanks,

No prob.

--
Noah Roberts
- "If you are not outraged, you are not paying attention."

[Allan Bruce]

"James Leddy" <jl*****@binghamton.edu> wrote in message
news:3f********@bingnews.binghamton.edu...

Hello,

I am making a program that encrypts and compresses plain text and indexes
them by date.

Needless to say, I have many alloc(), realloc(), calloc(), and free() calls. There are also double pointers all over the place.

The program works fine except for one tiny detail. Every time I try to
extract a file, the program terminates with a segmentation fault. I used
the debugger and discovered that the segmentation fault did not occur
because of an out of bounds error or anything. The segmentation fault
occurs when the program exits.

I thought that the problem was that I did not free() some block of memory
that I had previousally allocated. I checked and made sure that I had
free()d all the memory.

Could someone possibly offer an explanition as to why this keeps happening?
Thanks,

As an educated guess, I would say that you are accessing one of your arrays
out-of-bounds, and when you are coming to free it then you get your
segfault.
If you cant find it, then I would suggest getting a good memory wrapper for
your environment and testing thoroughly.
HTH
Allan

[pete]

Gordon Burditt wrote:

I thought that the problem was that I did not free()
some block of memory that I had previousally allocated.
I checked and made sure that I had free()d all the memory.
It is unlikely that a segmentation fault would be caused by failure
to free memory you allocated. (Standards wizards: I think a
segfault for failure to free memory would not be allowed, as this
failure doesn't invoke undefined behavior. Opinions?)

Yes, but ...
the failure to free, especially if in a loop,
may cause a memory shortage.
A memory shortage could cause malloc and friends to fail.
If malloc or friends fail,
and the code is written in such a way which always assumes success,
then all of that taken together, could lead to UB.
It is quite possible that a segmentation fault would be caused
by free()ing something you DIDN'T allocate (with malloc & friends).
So could stomping on the malloc() arena caused by using more
memory than you actually allocated.

That could do it too.

--
pete

[Irrwahn Grausewitz]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote:

"James Leddy" <jl*****@binghamton.edu> wrote in message
news:3f********@bingnews.binghamton.edu...

<snip>

I thought that the problem was that I did not free() some block of memory
that I had previousally allocated. I checked and made sure that I had
free()d all the memory.

Could someone possibly offer an explanition as to why this keeps

happening?

As an educated guess, I would say that you are accessing one of your arrays
out-of-bounds, and when you are coming to free it then you get your
segfault.

Any attempt to free() an _array_ always leads to undefined behaviour.

Regards
--
Irrwahn
(ir*******@freenet.de)

[Eric Sosman]

James Leddy wrote:

[...] Every time I try to
extract a file, the program terminates with a segmentation fault. I used
the debugger and discovered that the segmentation fault did not occur
because of an out of bounds error or anything. The segmentation fault
occurs when the program exits. [...]

In addition to the possibilities others have mentioned,
the fact that the crash occurs upon exit suggests two more
things you might want to check for:

- If you have used atexit() to register any functions
to be run when the program terminates, make sure
any data that those functions use is still "live."
If one of the registered functions refers to memory
already freed, or uses an already-closed FILE* stream,
or uses a pointer to an automatic variable in a
function that's already returned, pretty much
anything might happen.

- If you have used setvbuf() to designate an I/O
buffer of your own for some FILE* stream, make sure
(as above) that the buffer still exists until the
stream gets closed, either explicitly by your use
of fclose() or automatically as part of program
termination.

--
Er*********@sun.com

[Micah Cowan]

James Leddy <jl*****@binghamton.edu> writes:

Hello,

I am making a program that encrypts and compresses plain text and indexes
them by date.

Needless to say, I have many alloc(), realloc(), calloc(), and free() calls.
There are also double pointers all over the place.
There is no function alloc() in the Standard C library. Did you
mean malloc()?
The program works fine except for one tiny detail. Every time I try to
extract a file, the program terminates with a segmentation fault. I used
the debugger and discovered that the segmentation fault did not occur
because of an out of bounds error or anything. The segmentation fault
occurs when the program exits.

I thought that the problem was that I did not free() some block of memory
that I had previousally allocated. I checked and made sure that I had
free()d all the memory.

Could someone possibly offer an explanition as to why this keeps happening?

This sort of thing typically happens when free() was called with
a block of memory that was never allocated with malloc() or
calloc(), or when memory you did not have a right to touch was
accessed. This can be a *very* tricky situation to track down:
there are tools available to help detect illegal memory access,
such as Electric Fence (which is for UNIX systems only, I
believe).

HTH,
Micah