could you please explain what has happened here?
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804885d in add_token ()
> Current language: auto; currently asm
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).
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
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".
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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
This goes on for some time but I think "that '??' cant be good"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
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).
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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)
Here's the new_token() function where I have used malloc function.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; ... ...
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
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Good catch. The correct form would be:
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.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; ... ...
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
