gdb reports something I dont understand

could you please explain what has happened here?

> Program received signal SIGSEGV, Segmentation fault.
> 0x0804885d in add_token ()
> Current language: auto; currently asm

Your program accessed memory, while in the add_token function, it did not have the rights to access.

Type bt to get a backtrace of where the segmentation fault happened (i.e., which functions called add_token() before it segfaulted).

The next step is add a breakpoint at the start of add_token(), then single step your way through the code until you either
- segfault again
- realise at some point before it crashes "wait a minute, that can't be good".

This is what bt gives me...


> Program received signal SIGSEGV, Segmentation fault.
> 0x080487be in add_token ()
> Current language: auto; currently asm
> (gdb) bt
> #0 0x080487be in add_token ()
> #1 0x08048dad in analyze ()
> #2 0x08048696 in main ()

Following Salem's advice, I added a breakpoint and stepied....

This is what happens

Quote:

---

Breakpoint 1, 0x080487a8 in add_token ()
(gdb) stepi
0x080487ab in add_token ()
(gdb) stepi
0x080487b0 in add_token ()
(gdb) stepi
0x080487b3 in add_token ()
(gdb) stepi
0x080487b9 in add_token ()
(gdb) stepi
0x08048604 in new_token ()
(gdb) stepi
0x08048605 in new_token ()
(gdb) stepi
0x08048607 in new_token ()
(gdb) stepi
0x0804860a in new_token ()
(gdb) stepi
0x08048611 in new_token ()
(gdb) stepi
0x08048544 in malloc@plt ()
(gdb) stepi
0x0804854a in malloc@plt ()
(gdb) stepi
0x0804854f in malloc@plt ()
(gdb) stepi
0x08048474 in ?? ()
(gdb) stepi
0x0804847a in ?? ()
(gdb) stepi
0xb7fd6c40 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd6c41 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd6c42 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd6c43 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd6c47 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd6c4b in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd1350 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd1351 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd1353 in ?? () from /lib/ld-linux.so.2
(gdb) stepi
0xb7fd1354 in ?? () from /lib/ld-linux.so.2

---

This goes on for some time but I think "that '??' cant be good"
Am I right?

At the point the ??s start showing up you're in kernel code, so that's not really important.

My suggestion, adding to Salem's is to run the program itself within gdb. When it segfaults, check the values of the variables in add_token; it should provide a hint as to what's happening.

Perhaps if you post the code for add_token we could be of more assistance in getting to the root of the issue.

The fact that it calls malloc probably suggests that some earlier mis-use of malloc occurred. Here is just where you get to notice there's a problem.

Problems such as
- array overrun of allocated memory
- use after free
- double free
- freeing what wasn't allocated

If you use say valgrind or electric fence, then these usually pinpoint the code which is the cause, not the effect (which is what you see).

Here's a part of the add_token() function. (The part that I've truncated is a few if-else statements that recognize tokens and add them to a linked list)

Code:

---

void add_token() {

        struct lex *ptr;
        ptr=token;
        token=token->next_lex=new_token();
        if(ptr!=NULL) {
                token->prev_lex=ptr;
        }
        else {
                begin=token;
        }
        token->lines=lines;
...
...

---

Here's the new_token() function where I have used malloc function.

Code:

---

struct lex* new_token() {
        struct lex *a=malloc(sizeof(struct lex));
        return (a);
}

---

very strange code

if ptr is NULL then the previous token was NULL
so token->next_lex will crash because it is done before the check

Good catch. The correct form would be:

Code:

---

void add_token() {

        struct lex *ptr;
        ptr=token;
        token=new_token();
        if(ptr!=NULL) {
                token->prev_lex=ptr;
                ptr->next_lex=ptr;
        }
        else {
                begin=token;
        }
        token->lines=lines;
...
...

---

However, there's also the problem that the memory of the new token is uninitialized. The simplest way to solve this is to use calloc instead of malloc.