segmentation fault - code attached

[Narendran Kumaraguru Nathan]

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.

[Fredrik Tolf]

On Sun, 2004-10-03 at 19:52 -0700, Narendran Kumaraguru Nathan wrote:

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

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]

Narendran Kumaraguru Nathan wrote:

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.

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]

Artie Gold wrote:

Narendran Kumaraguru Nathan wrote:

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.

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);

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]

Artie Gold wrote:

.... snip ...
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);

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 (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Artie Gold]

CBFalconer wrote:

Artie Gold wrote:

... snip ...

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);

The use of calloc to assign space for pointers is worthless. There

The OP had -- mistakenly.
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.

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]

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 <ar*******@aust in.rr.com> wrote in message news:<2s******* ******@uni-berlin.de>...

CBFalconer wrote:

Artie Gold wrote:

... snip ...

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);

The use of calloc to assign space for pointers is worthless. There

The OP had -- mistakenly.

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.

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

[Narendran Kumaraguru Nathan]

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 <ar*******@aust in.rr.com> wrote in message news:<2s******* ******@uni-berlin.de>...

Artie Gold wrote:

Narendran Kumaraguru Nathan wrote:

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.

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);

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

[Jens.Toerring]

Narendran Kumaraguru Nathan <na************ *@yahoo.co.uk> wrote:

Please don't top-post.

Artie Gold <ar*******@aust in.rr.com> wrote in message news:<2s******* ******@uni-berlin.de>...

CBFalconer wrote:

> 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
The OP had -- mistakenly.

> 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.
>

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

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) {}
???

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 ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[Keith Thompson]

na************* @yahoo.co.uk (Narendran Kumaraguru Nathan) writes:

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.

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) ks***@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.