Seg fault even though address space is accessible

[Ajay]

Hi All,

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
776 vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
#1 0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 0x080522c1 in main (argc=11, argv=0x8047348)
at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

 

[user923005]

Hi All,

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
    at compute_sticky_IP_per_ASN.c:776
776                     vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0  checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
    at compute_sticky_IP_per_ASN.c:776
#1  0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
    peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2  0x080522c1 in main (argc=11, argv=0x8047348)
    at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

Maybe an alignment problem.
Did you try the GNU groups?
http://www.nabble.com/Gnu---gdb-f1618.html
news:gnu.gdb.bug

 

[Ajay]

Maybe an alignment problem.
Did you try the GNU groups?http://www.nabble.com/Gnu---gdb-f1618.html
news:gnu.gdb.bug

Hmmm! I haven't, Let me try that.


But, how can I find if its an alignment problem?

However, I checked the address space which are function parameters.
And it appears it is aligned.

-Ajay.

 

[Ben Bacarisse]

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

The usual advice is to post code. Ideally code you have cut right
down but which still exhibits the problem. Doing this often isolates
the issue anyway, but without code to see it is tough...

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
776 vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
#1 0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 0x080522c1 in main (argc=11, argv=0x8047348)
at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

To me, this does not show anything interesting. The fault is with
'vector' not 'BFVecList' which is the only thing that has the value
0x84187a0 (as far as I can see). Did you miss out the 'print vector'
output showing it to be equal to 'BFVecList'? Why not just try to
print vector->nextVector rather than using some mysterious (to me)
address?

 

[Jens Thoms Toerring]

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

Wich is rather useless without seeing the code. Without it the
gdb output is mostly meaningless.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
776 vector = vector->nextVector;

What value has 'vector here? Did you check that it's an
address you can legally use as a pointer? Without seeing
your code there's nothing that indicates that 'vector'
has anything to do with the address 0x84187a0.

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
#1 0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 0x080522c1 in main (argc=11, argv=0x8047348)
at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector

I don't understand what you're doing here. Doing

p ((bitfieldItemStruct *) 0x84187a0)->nextVector
p ((struct bitfieldItem *) 0x84187a0)->nextVector

looks suspicious. Note that you use the same address in
both cases, just casting it to a different type - or is
it the same? If yes, why do you think it's relevant to
check the same thing twice?

Regards, Jens

 

[Ajay]

Hi All,

Thanks for all your replays.

I am posting the code here.


typedef struct bitfieldItem {
uint32_t BFVector;
const struct bitfieldItem *nextVector;
} bitfieldItemStruct, *bitfieldItemStructPtr;

main()
{
***
buildBFVectorList(currPeerDetailItem->bitfieldStr,
&(currPeerDetailItem->bitfieldVector));
checkBFVectorList(currPeerDetailItem->bitfieldVector,
currPeerDetailItem->bitfieldLength);

***

}


int checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int
BFlen)
{
bitfieldItemStruct *vector = *BFVecList;
float numVectors = ceil((float)BFlen/32.0);
float vector_id = 0;
printf ("Verifying BF vector\n");
printf ("BFlen = %d, numvectors = %f\n", BFlen, numVectors);
printf ("The BF vector is: ");
while (vector != NULL)
{
printf ("%d ", vector->BFVector);
vector = vector->nextVector;
vector_id++;
}
printf ("\nvector_id = %d\n", vector_id);
assert (vector_id == numVectors);
return 1;
}

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
char * bit;
unsigned int num_bits_pushed = 0;
unsigned int total_num_bits_pushed = 0;
unsigned int num_vectors = 0;

if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
bit = (char *) strtok(BFStr, ",");
BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));
BFVecHead->BFVector = 0;
BFVecHead->nextVector = NULL;
currBFVec = BFVecHead;
num_vectors = 1;
printf ("Before %u\n", BFVecHead->BFVector);

while (bit != NULL)
{
if (verboseLevel >= 9) printf ("%d: Current bit is %s\n",
total_num_bits_pushed+1, bit);
if (num_bits_pushed >= 32) {
printf ("\nAfter %u\n", currBFVec->BFVector);
if (tmpBFVec = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *)) == NULL) {
printf ("Memory reallocation failed for object of type
'bitfieldItemStruct*'.\n");
exit(-1);
}
tmpBFVec->BFVector= 0;
tmpBFVec->nextVector = NULL;
currBFVec->nextVector = tmpBFVec;
currBFVec = tmpBFVec;
num_bits_pushed = 0;
num_vectors++;
printf ("Before %u\n", currBFVec->BFVector);
}

currBFVec->BFVector = currBFVec->BFVector << 1;
printf ("%u", atoi(bit));
currBFVec->BFVector += atoi(bit);
num_bits_pushed++;
total_num_bits_pushed++;
bit = (char *) strtok(NULL, ",");
}
printf ("\nAfter %u\n", currBFVec->BFVector);
*BFVecList = BFVecHead;
printf ("The total number of bits in the BFvector is %d and num
vectors is %d.\n", total_num_bits_pushed, num_vectors);
return 1;
}

 

[Ben Bacarisse]

I am posting the code here.

Makes all the difference... BTW, top-posting is not in favour in the
group.

typedef struct bitfieldItem {
uint32_t BFVector;
const struct bitfieldItem *nextVector;
} bitfieldItemStruct, *bitfieldItemStructPtr;

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
char * bit;
unsigned int num_bits_pushed = 0;
unsigned int total_num_bits_pushed = 0;
unsigned int num_vectors = 0;

if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
bit = (char *) strtok(BFStr, ",");
BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));

This is wrong. There is no need for calloc (you set the memory
immediately), the cast is unnecessary, and you don't check the result.
However, the reason things go really wrong is the size is not right.

The comp.lang.c approved method is to write:

BFVecHead = malloc(sizeof *BFVecHead);

This way you can see the size is right (provided the type of the
pointer is correct) and you will get an error message if you have
forgotten to include stdlib.h.

 

[Ajay]

Makes all the difference...  BTW, top-posting is not in favour in the
group.








This is wrong.  There is no need for calloc (you set the memory
immediately), the cast is unnecessary, and you don't check the result.
However, the reason things go really wrong is the size is not right.

The comp.lang.c approved method is to write:

    BFVecHead = malloc(sizeof *BFVecHead);

This way you can see the size is right (provided the type of the
pointer is correct) and you will get an error message if you have
forgotten to include stdlib.h.

Hi Ben,

Thanks for your replay!
I was using malloc but after the error appeared, I tried using calloc.
I changed back the code to using malloc.
The Seg. fault error still persists.
The new code is posted below:

Thanks,
Ajay.



int
checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int BFlen)
{
bitfieldItemStruct *vector = *BFVecList;
float numVectors = ceil((float)BFlen/32.0);
float vector_id = 0;
printf ("Verifying BF vector\n");
printf ("BFlen = %d, numvectors = %f\n", BFlen, numVectors);
printf ("The BF vector is: ");
while (vector != NULL)
{
/* if (vector->BFVector != NULL) printf ("%u ", vector-

BFVector);

else { printf ("Error occured\n"); exit(-1); } */
/* printf ("%d ", vector->BFVector);*/
vector = vector->nextVector;
vector_id++;
}
printf ("\nvector_id = %d\n", vector_id);
assert (vector_id == numVectors);
return 1;
}

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
char * bit;
unsigned int num_bits_pushed = 0;
unsigned int total_num_bits_pushed = 0;
unsigned int num_vectors = 0;

if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
bit = (char *) strtok(BFStr, ",");
BFVecHead = malloc(sizeof(*BFVecHead));
if (BFVecHead == NULL) {
perror("Error: Memory could not be allocated:");
exit(-1);
}
BFVecHead->BFVector = 0;
BFVecHead->nextVector = NULL;
currBFVec = BFVecHead;
num_vectors = 1;
printf ("Before %u\n", BFVecHead->BFVector);

while (bit != NULL)
{
if (verboseLevel >= 9) printf ("%d: Current bit is %s\n",
total_num_bits_pushed+1, bit);
if (num_bits_pushed >= 32) {
printf ("\nAfter %u\n", currBFVec->BFVector);
tmpBFVec = malloc(sizeof(*tmpBFVec));
if (tmpBFVec == NULL) {
perror("Error: Memory could not be allocated:");
exit(-1);
}
tmpBFVec->BFVector= 0;
tmpBFVec->nextVector = NULL;
currBFVec->nextVector = tmpBFVec;
currBFVec = tmpBFVec;
num_bits_pushed = 0;
num_vectors++;
printf ("Before %u\n", currBFVec->BFVector);
}

currBFVec->BFVector = currBFVec->BFVector << 1;
printf ("%u", atoi(bit));
currBFVec->BFVector += atoi(bit);
num_bits_pushed++;
total_num_bits_pushed++;
bit = (char *) strtok(NULL, ",");
}
printf ("\nAfter %u\n", currBFVec->BFVector);
*BFVecList = BFVecHead;
printf ("The total number of bits in the BFvector is %d and num
vectors is %d.\n", total_num_bits_pushed, num_vectors);
return 1;
}

 

[Ike Naar]

{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
[snip]
BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));

This looks suspicious.
You allocate room for one pointer instead of room for one struct.
Also, the cast is unnecessary.

Regards,
Ike

 

[Ben Bacarisse]

Thanks for your replay!
I was using malloc but after the error appeared, I tried using calloc.
I changed back the code to using malloc.
The Seg. fault error still persists.
The new code is posted below:

Are you sure you are posting code you have compiled?

int
checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int BFlen)

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)

elsewhere you posted:

| main()
| {
| ***
| buildBFVectorList(currPeerDetailItem->bitfieldStr,
| &(currPeerDetailItem->bitfieldVector));
| checkBFVectorList(currPeerDetailItem->bitfieldVector,
| currPeerDetailItem->bitfieldLength);
|
| ***
|
| }

The types here do not match up -- the compiler should reject it.

 

[Ajay]

Are you sure you are posting code you have compiled?


elsewhere you posted:

| main()
| {
|    ***
|  buildBFVectorList(currPeerDetailItem->bitfieldStr,
| &(currPeerDetailItem->bitfieldVector));
|  checkBFVectorList(currPeerDetailItem->bitfieldVector,
| currPeerDetailItem->bitfieldLength);
|
|  ***
|
| }

The types here do not match up -- the compiler should reject it.

Yes, you are right. The compiler did gave warning which I did not
notice.

Thanks a lot!
-Ajay.

 

[Antoninus Twink]

Ajay said:

There's a guy around here somewhere who can debug your problem (no matter
what it is) using only the debugger. Impressive. But if by some strange
chance he doesn't have time to answer your question, you'll have to rely
on the rest of us, and I'm afraid we tend to need to see the source code.

Yes Heathfield, very amusing, how we all admire your cleverness and wit.

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger. I call bullshit on that.

 

[Richard]

Yes Heathfield, very amusing, how we all admire your cleverness and
wit.

He really is an arrogant twit.

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
Exactly.

many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger. I call bullshit on that.

Me too. Now cue one of his sycophantic friends to quote Kernighan or
somesuch telling us how much more difficult it is to debug a system than to
program it correctly the first time. Sigh.

 

[Flash Gordon]

Richard wrote, On 30/07/08 19:18:

Me too. Now cue one of his sycophantic friends to quote Kernighan or
somesuch telling us how much more difficult it is to debug a system than to
program it correctly the first time. Sigh.

Obviously the person who managed to identify the bugs from just a couple
of snippets in this thread really managed to get hold of the entire
source without the rest of us seeing it.

 

[Richard]

Richard wrote, On 30/07/08 19:18:

Obviously the person who managed to identify the bugs from just a
couple of snippets in this thread really managed to get hold of the
entire source without the rest of us seeing it.

I'm not sure what your point is. This is usenet. The code needed was
small. It in no way invalidates the benefits a debugger brings. Or in
this case paying attention to compiler warnings. of course some people
pulled the "can't compile it so cant help" line. others read the
code. Which was not insurmountable since it was about 20 lines.

 

[Chris Dollin]

Yes Heathfield, very amusing, how we all admire your cleverness and wit.

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger.

Cite three instances that fit this claim.

 

[Keith Thompson]

Antoninus Twink wrote:

[more of the same]

Cite three instances that fit this claim.

Chris, why on Earth would you ask a troll to post *more* crap?

 

[Chris Dollin]

Antoninus Twink wrote:

[more of the same]

Cite three instances that fit this claim.

Chris, why on Earth would you ask a troll to post *more* crap?

Paranoid terror that some poor sod will believe their
hysterically extreme claims.

(Additional evidence suggests I'm on a downer at the moment.)

 

[CBFalconer]

Antoninus Twink wrote:
.... snip ...


Cite three instances that fit this claim.

Well, answering the twinkletroll is pointless. However, many have
performed this awesome feat of legerdomain and successfully patched
the object code. It does require understanding machine code. It
may also require understanding the structure of the loadable code
module.

Admittedly, it is somewhat harder than reading source.

 

[Ajay]

... snip ...



Well, answering the twinkletroll is pointless.  However, many have
performed this awesome feat of legerdomain and successfully patched
the object code.  It does require understanding machine code.  It
may also require understanding the structure of the loadable code
module.

Admittedly, it is somewhat harder than reading source.

Thanks for all your replays and time.
The Seg fault is now resolved. Just a summary.

I was making two big blunders.
1. I was passing pointer to a structure instead of pointer to pointer
of a structure.
2. I was allocating memory to a pointer to structure instead of
structure.

They just creeped in due to my 'lazy programming'.

I am posting gcc compiled code.
Since I was using strict compiler options (including -ansi -pedantic)
and throwing out all the warnings.
So I was ignoring the argument mis-match warnings along with other
warnings.

I haven't figured out what are best compiler options yet.
But I can make sure next time that I go thru the list warning msgs.

Thanks,
Ajay.