segmentation fault - code attached

**Fredrik Tolf** · Nov 14 '05, 01:27 PM

Re: segmentation fault - code attached

On Sun, 2004-10-03 at 19:52 -0700, Narendran Kumaraguru Nathan wrote:[color=blue]
> Hi all,
> I am fairly experianced in C. I am writing a program in which I'm
> getting a segmentation fault. The problem is that it is getting the
> segmentation fault when executing calloc. I tried debugging it, with
> no use. I tried to figure out the common reasons (1) Using a memory
> location which is not allocated. (2) Using memory which is freed. (3)
> Function use before declaration.
> I didn't use any other debuggers or tools other than ddd. My
> platform is : RH linux 2.4.20-8 & gcc -v ouputs the following[/color]

If you're getting segfaults in a *alloc call, you're most likely doing
some core fandango somewhere. That can be one of the hardest errors to
debug, since your fault might well be in a completely different part of
the source, which may have been executed long before the actual fault.

<OT>
However, since you're running Linux on i386, I'd recommend that you
fetch Valgrind, which is _great_ for debugging such issues. It's an i386
emulator that catches suspicious access to suspicious memory locations.
</OT>

Fredrik Tolf

**Artie Gold** · Nov 14 '05, 01:27 PM

Re: segmentation fault - code attached

Narendran Kumaraguru Nathan wrote:[color=blue]
> Hi all,
> I am fairly experianced in C. I am writing a program in which I'm
> getting a segmentation fault. The problem is that it is getting the
> segmentation fault when executing calloc. I tried debugging it, with
> no use. I tried to figure out the common reasons (1) Using a memory
> location which is not allocated. (2) Using memory which is freed. (3)
> Function use before declaration.
> I didn't use any other debuggers or tools other than ddd. My
> platform is : RH linux 2.4.20-8 & gcc -v ouputs the following
>
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
>
> I don't understand what to do. I couldn't attach the program I am
> developing, hence have put that in geocities with a sample input. The
> files are under
> http://www.geocities.com/narenkumaraguru/vcdedit/
> The files are
> 1. main.c.c
> 2. vcd_read.c.c
> 3. vcd_read.h.c
> 4. Makefile.c
> 5. cntr.vcd.c
>
> Since I couldn't upload files with different names, I postfixed .c
> to all of them. Once downloaded please correct the names by removing
> the extra .c in them.
>
> Procedure to run it is
> 1. make
> 2. ./vcd_read
>
> I'm aint a C wizard. The program is to parse a file format called
> the VCD. It is used in VLSI for debugging and waveform dump in
> particular. I was writing a library for the format.
>
> Thanks,
> Naren.[/color]

Note the following (in vcd_Read.c):

case var:
if (!LastScope) { /* $scope should have preceeded */
fprintf(stderr, "Error %d: detected $var before $scope!\n",
line_no);
exit(1);
}
TempVar = (struct Var *)
calloc( 1, sizeof(struct Var *) );

ITYM:
calloc( 1, sizeof(struct Var) );

TempVar->msb_index = TempVar->lsb_index = -1;
if (!LastVar) {
LastScope->var = TempVar;
} else {
LastVar->next = TempVar;
}

The cast is unnecessary (you may see previous discussions in
news:comp.lang. c for details) -- but the problem is that you've only
allocated enough space for a pointer to `struct Var' not an instance of
`struct Var'. This is why the recommended form of use members of the
malloc/calloc family is, for example:

ptr = calloc(1, sizeof *ptr);

HTH,
--ag
--
Artie Gold -- Austin, Texas

"If you don't think it matters, you're not paying attention."

**Artie Gold** · Nov 14 '05, 01:27 PM

Re: segmentation fault - code attached

Artie Gold wrote:[color=blue]
> Narendran Kumaraguru Nathan wrote:
>[color=green]
>> Hi all,
>> I am fairly experianced in C. I am writing a program in which I'm
>> getting a segmentation fault. The problem is that it is getting the
>> segmentation fault when executing calloc. I tried debugging it, with
>> no use. I tried to figure out the common reasons (1) Using a memory
>> location which is not allocated. (2) Using memory which is freed. (3)
>> Function use before declaration.
>> I didn't use any other debuggers or tools other than ddd. My
>> platform is : RH linux 2.4.20-8 & gcc -v ouputs the following
>>
>> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>> --infodir=/usr/share/info --enable-shared --enable-threads=posix
>> --disable-checking --with-system-zlib --enable-__cxa_atexit
>> --host=i386-redhat-linux
>> Thread model: posix
>> gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
>>
>> I don't understand what to do. I couldn't attach the program I am
>> developing, hence have put that in geocities with a sample input. The
>> files are under
>> http://www.geocities.com/narenkumaraguru/vcdedit/
>> The files are
>> 1. main.c.c
>> 2. vcd_read.c.c
>> 3. vcd_read.h.c
>> 4. Makefile.c
>> 5. cntr.vcd.c
>>
>> Since I couldn't upload files with different names, I postfixed .c
>> to all of them. Once downloaded please correct the names by removing
>> the extra .c in them.
>>
>> Procedure to run it is
>> 1. make
>> 2. ./vcd_read
>>
>> I'm aint a C wizard. The program is to parse a file format called
>> the VCD. It is used in VLSI for debugging and waveform dump in
>> particular. I was writing a library for the format.
>>
>> Thanks,
>> Naren.[/color]
>
>
> Note the following (in vcd_Read.c):
>
> case var:
> if (!LastScope) { /* $scope should have preceeded */
> fprintf(stderr, "Error %d: detected $var before $scope!\n",
> line_no);
> exit(1);
> }
> TempVar = (struct Var *)
> calloc( 1, sizeof(struct Var *) );
>
> ITYM:
> calloc( 1, sizeof(struct Var) );
>
> TempVar->msb_index = TempVar->lsb_index = -1;
> if (!LastVar) {
> LastScope->var = TempVar;
> } else {
> LastVar->next = TempVar;
> }
>
>
> The cast is unnecessary (you may see previous discussions in
> news:comp.lang. c for details) -- but the problem is that you've only
> allocated enough space for a pointer to `struct Var' not an instance of
> `struct Var'. This is why the recommended form of use members of the
> malloc/calloc family is, for example:
>
> ptr = calloc(1, sizeof *ptr);
>[/color]

Oops, forgot to mention:

You didn't get a segfault right there -- but you did corrupt your free
store, causing a segfault on a future allocation.

HTH,
--ag

--
Artie Gold -- Austin, Texas

"If you don't think it matters, you're not paying attention."

**CBFalconer** · Nov 14 '05, 01:28 PM

Re: segmentation fault - code attached

Artie Gold wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> The cast is unnecessary (you may see previous discussions in
> news:comp.lang. c for details) -- but the problem is that you've
> only allocated enough space for a pointer to `struct Var' not an
> `struct Var'. This is why the recommended form of use members of
> the malloc/calloc family is, for example:
>
> ptr = calloc(1, sizeof *ptr);[/color]

The use of calloc to assign space for pointers is worthless. There
is no guarantee that "all bytes zero" represents a NULL pointer.
So the overhead of calloc is wasted, use malloc and explicitly set
it to NULL.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

**Artie Gold** · Nov 14 '05, 01:28 PM

Re: segmentation fault - code attached

CBFalconer wrote:[color=blue]
> Artie Gold wrote:
>
> ... snip ...
>[color=green]
>>The cast is unnecessary (you may see previous discussions in
>>news:comp.lan g.c for details) -- but the problem is that you've
>>only allocated enough space for a pointer to `struct Var' not an
>>`struct Var'. This is why the recommended form of use members of
>>the malloc/calloc family is, for example:
>>
>> ptr = calloc(1, sizeof *ptr);[/color]
>
>
> The use of calloc to assign space for pointers is worthless. There[/color]

The OP had -- mistakenly.
[color=blue]
> is no guarantee that "all bytes zero" represents a NULL pointer.
> So the overhead of calloc is wasted, use malloc and explicitly set
> it to NULL.
>[/color]

Agreed. The structs the OP was using, IIRC, consisted of integral fields
-- and I wasn't looking to get into the malloc/calloc discussion.

Cheers,
--ag

--
Artie Gold -- Austin, Texas

"If you don't think it matters, you're not paying attention."

**Narendran Kumaraguru Nathan** · Nov 14 '05, 01:28 PM

Re: segmentation fault - code attached

Do you guys suggest me that I sould never use the code
if(!ptr) { }
and I should explicitly equate it to NULL? as in
if(ptr == NULL) {}
???
Thanks,
Naren.

Artie Gold <artiegold@aust in.rr.com> wrote in message news:<2sd59hF1j c5ttU1@uni-berlin.de>...[color=blue]
> CBFalconer wrote:[color=green]
> > Artie Gold wrote:
> >
> > ... snip ...
> >[color=darkred]
> >>The cast is unnecessary (you may see previous discussions in
> >>news:comp.lan g.c for details) -- but the problem is that you've
> >>only allocated enough space for a pointer to `struct Var' not an
> >>`struct Var'. This is why the recommended form of use members of
> >>the malloc/calloc family is, for example:
> >>
> >> ptr = calloc(1, sizeof *ptr);[/color]
> >
> >
> > The use of calloc to assign space for pointers is worthless. There[/color]
>
> The OP had -- mistakenly.
>[color=green]
> > is no guarantee that "all bytes zero" represents a NULL pointer.
> > So the overhead of calloc is wasted, use malloc and explicitly set
> > it to NULL.
> >[/color]
>
> Agreed. The structs the OP was using, IIRC, consisted of integral fields
> -- and I wasn't looking to get into the malloc/calloc discussion.
>
> Cheers,
> --ag[/color]

**Narendran Kumaraguru Nathan** · Nov 14 '05, 01:28 PM

Re: segmentation fault - code attached

Thanks a lot Art,
Sometimes silly bugs like these elude my eyes :). Anyway I've never
used valgrind and on this occassion, you have prevented me from using
it - thanks for all those who helped ....
Regards,
Naren.

Artie Gold <artiegold@aust in.rr.com> wrote in message news:<2sbtoqF1j 0v4cU2@uni-berlin.de>...[color=blue]
> Artie Gold wrote:[color=green]
> > Narendran Kumaraguru Nathan wrote:
> >[color=darkred]
> >> Hi all,
> >> I am fairly experianced in C. I am writing a program in which I'm
> >> getting a segmentation fault. The problem is that it is getting the
> >> segmentation fault when executing calloc. I tried debugging it, with
> >> no use. I tried to figure out the common reasons (1) Using a memory
> >> location which is not allocated. (2) Using memory which is freed. (3)
> >> Function use before declaration.
> >> I didn't use any other debuggers or tools other than ddd. My
> >> platform is : RH linux 2.4.20-8 & gcc -v ouputs the following
> >>
> >> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
> >> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> >> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> >> --disable-checking --with-system-zlib --enable-__cxa_atexit
> >> --host=i386-redhat-linux
> >> Thread model: posix
> >> gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
> >>
> >> I don't understand what to do. I couldn't attach the program I am
> >> developing, hence have put that in geocities with a sample input. The
> >> files are under
> >> http://www.geocities.com/narenkumaraguru/vcdedit/
> >> The files are
> >> 1. main.c.c
> >> 2. vcd_read.c.c
> >> 3. vcd_read.h.c
> >> 4. Makefile.c
> >> 5. cntr.vcd.c
> >>
> >> Since I couldn't upload files with different names, I postfixed .c
> >> to all of them. Once downloaded please correct the names by removing
> >> the extra .c in them.
> >>
> >> Procedure to run it is
> >> 1. make
> >> 2. ./vcd_read
> >>
> >> I'm aint a C wizard. The program is to parse a file format called
> >> the VCD. It is used in VLSI for debugging and waveform dump in
> >> particular. I was writing a library for the format.
> >>
> >> Thanks,
> >> Naren.[/color]
> >
> >
> > Note the following (in vcd_Read.c):
> >
> > case var:
> > if (!LastScope) { /* $scope should have preceeded */
> > fprintf(stderr, "Error %d: detected $var before $scope!\n",
> > line_no);
> > exit(1);
> > }
> > TempVar = (struct Var *)
> > calloc( 1, sizeof(struct Var *) );
> >
> > ITYM:
> > calloc( 1, sizeof(struct Var) );
> >
> > TempVar->msb_index = TempVar->lsb_index = -1;
> > if (!LastVar) {
> > LastScope->var = TempVar;
> > } else {
> > LastVar->next = TempVar;
> > }
> >
> >
> > The cast is unnecessary (you may see previous discussions in
> > news:comp.lang. c for details) -- but the problem is that you've only
> > allocated enough space for a pointer to `struct Var' not an instance of
> > `struct Var'. This is why the recommended form of use members of the
> > malloc/calloc family is, for example:
> >
> > ptr = calloc(1, sizeof *ptr);
> >[/color]
>
>
> Oops, forgot to mention:
>
> You didn't get a segfault right there -- but you did corrupt your free
> store, causing a segfault on a future allocation.
>
> HTH,
> --ag[/color]

**Jens.Toerring@physik.fu-berlin.de** · Nov 14 '05, 01:28 PM

Re: segmentation fault - code attached

Narendran Kumaraguru Nathan <narenkumaragur u@yahoo.co.uk> wrote:

Please don't top-post.
[color=blue]
> Artie Gold <artiegold@aust in.rr.com> wrote in message news:<2sd59hF1j c5ttU1@uni-berlin.de>...[color=green]
>> CBFalconer wrote:[color=darkred]
>> > Artie Gold wrote:
>> >>`struct Var'. This is why the recommended form of use members of
>> >>the malloc/calloc family is, for example:
>> >>
>> >> ptr = calloc(1, sizeof *ptr);
>> >
>> >
>> > The use of calloc to assign space for pointers is worthless. There[/color]
>>
>> The OP had -- mistakenly.
>>[color=darkred]
>> > is no guarantee that "all bytes zero" represents a NULL pointer.
>> > So the overhead of calloc is wasted, use malloc and explicitly set
>> > it to NULL.
>> >[/color]
>>
>> Agreed. The structs the OP was using, IIRC, consisted of integral fields
>> -- and I wasn't looking to get into the malloc/calloc discussion.[/color][/color]
[color=blue]
> Do you guys suggest me that I sould never use the code
> if(!ptr) { }
> and I should explicitly equate it to NULL? as in
> if(ptr == NULL) {}
> ???[/color]

No. There is some additional compiler magic involved. Even when the
bit representation of a NULL pointer isn't all bits 0 a comparison
with NULL (or just 0) must always result in the expected result, i.e.
the compiler, when it sees that you compare a pointer to 0 must
do the comparison as if the pointer would be all bits 0. It will
also set the pointer to whatever represents a NULL pointer on your
machine when you assign NULL (or 0) to the pointer - but, as it has
been pointed out, that isn't guaranteed to be a value with all bits
set to 0 and thus calloc() can't do the right thing since it doesn't
know that the memory you allocate is going to be used for a pointer.

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

**Keith Thompson** · Nov 14 '05, 01:29 PM

Re: segmentation fault - code attached

narenkumaraguru @yahoo.co.uk (Narendran Kumaraguru Nathan) writes:[color=blue]
> Do you guys suggest me that I sould never use the code
> if(!ptr) { }
> and I should explicitly equate it to NULL? as in
> if(ptr == NULL) {}
> ???
> Thanks,
> Naren.[/color]

Please don't top-post. New material should follow quoted material,
and quoted material should usually be trimmed. See most of the
articles in this newsgroup for examples.

Assuming that you have an include directive for one of the headers
that defines the NULL macro, and assuming that ptr is a pointer
object, "if (!ptr) ..." and "if (ptr == NULL)" are exactly equivalent.
The "!" operator returns true if and only if its operand compares
equal to zero; for a pointer, comparison to zero is comparison to a
null pointer. See section 5 of the C FAQ, at
<http://www.eskimo.com/~scs/C-faq/top.html>. (Read the whole thing
while you're there.)

Which one you should use is a matter of style. Personally, I prefer
"ptr == NULL" because it's more explicit, but there are valid reasons
for preferring "!ptr". If you're going to be working with other
people's code (or with your own after you've written it), you need to
understand both forms.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

segmentation fault - code attached

segmentation fault - code attached

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment