Segmentation fault when running, but success when debugging

Question

I have encountered a wired segmentation fault. I am developing a software in C using Eclipse CDT. When running my program on the terminal (Ubuntu 10, 64bits), it simply reports "Segmentation fault". However, when I debug using gdb in Eclipse, it goes to the end and the result is correct.

I understand that there could be many reasons for segmentation faults. And I am sorry that I am not able to show my code since I do not know where the problem could be...

But could anyone please help me, is there any situation that could happen as my case: segmentation fault on terminals, while fine in debugging? Thanks so much.

Thanks, all. I would spent some time learning valgrind. I just fixed the bug by replacing a malloc() by realloc(). The calling is followed by two memcpy. Is that the reason? Here is the snippet code:

bwa_seq_t *merge_seq (bwa_seq_t *s1, bwa_seq_t *s2) {
  ubyte_t *seq1, *seq2, *tmp;
  if (!s1 || !s2)
    return 0;
  seq1 = s1->seq;
  seq2 = s2->seq;
  tmp = (ubyte_t*) calloc (sizeof(ubyte_t), (s2->len + s1->len + 1));
  memcpy(tmp, seq1, sizeof(ubyte_t) * s1->len);
  memcpy(&tmp[s1->len], seq2, sizeof(ubyte_t) * s2->len);
  s1->len += s2->len;
  tmp[s1->len] = '\0';
  s1->seq = tmp;
  return s1;
}

Could anybody help explain why?

Stack and/or heap corruption is likely. Make sure you enable full warnings on your compiler and deal with all of them. Mismatched arguments to `printf` and things like that are things to look out for. — Mat, Oct 04 '11 at 11:41
Run your program under [valgrind](http://valgrind.org/), the issue will probably become apparent. — Hasturkun, Oct 04 '11 at 11:46
I see no use of malloc or realloc in the code snip so it would be impossible to know why your change eliminated the segfault. Obviously malloc and realloc do very different things. The function has essentially no validation of the inputs so who knows if you are even starting out with valid pointers to memory. — shawn1874, Aug 16 '23 at 17:28

score 13 · Accepted Answer · answered Oct 04 '11 at 11:48

13

Try the following steps:

type ulimit -c unlimited in an xterm (this allows the creation of core/postmorterm files)
launch your program (and let it crash): a core file should now be present in the directory.
launch the debugger with gdb <yourprogram> <corefile>
type bt at gdb prompt to see on what line it did crash.
(optional) correct the error.

answered Oct 04 '11 at 11:48

Laurent'

2,611
1
14
22

This basically is the answer of lsalamon. 1 minute later ^^ – Laurent' Oct 04 '11 at 11:48
3

Er, yeah. But this answer seems more comprehensive for me. – Joy Oct 04 '11 at 13:29

score 7 · Answer 2 · edited May 23 '17 at 12:18

If you know how to crash it from the terminal, you can make it create a corefile and inspect the point where it crashed like this:

$ ulimit -c unlimited   # to create a corefile
$ yourprogram
...
crash                   # this will create file "core" in the current directory
$ gdb yourprogram core  # shows the state at the moment of the crash

Question on that topic:

score 0 · Answer 3 · answered Oct 04 '11 at 11:42

0

This is probably the result of an uninitialised variable. (in line 14 of your program)

answered Oct 04 '11 at 11:42

wildplasser

43,142
8
66
109

score 0 · Answer 4 · answered Oct 04 '11 at 11:46

0

Compile with debug information and use gdb to identify where the error occurs using the dump.

answered Oct 04 '11 at 11:46

lsalamon

7,998
6
50
63

score 0 · Answer 5 · answered Oct 04 '11 at 12:07

It is very likely you are hitting some sort of Undefined Behavior. As others already said, use Valgrind to debug this issue. First of all look for INVALID READ, INVALID WRITE errors in Valgrind output. It will also output additional call stacks when bad things happen in your code. This should help to understand the reason of bug.

score 0 · Answer 6 · answered Oct 04 '11 at 13:09

I also faced this issue before. Not in Linux with GCC compiler but in Visual studio 2005. It was like, my code was successfully running in debug mode while in release( Direct running) mode it was getting crash. The fact is that when you are debugging your code the debugger takes care of exceptions like Access violation, array out of bound etc. and doesn't let the code gets crash. In direct running mode there is no one to take care of exceptions and hence code gets crash.

I would suggest you to use printf to display the intermediate operation result as its is best way to troubleshot your code.

Hope this would help you..:-)

score 0 · Answer 7 · answered Oct 06 '11 at 15:46

BTW: you are leaking memory here. s1->seq is basically being reallocced, but you forget to free the old memory. Change:

s1->len += s2->len;
tmp[s1->len] = '\0';
s1->seq = tmp;
return s1;

into:

void *del; // <<--
s1->len += s2->len;
tmp[s1->len] = '\0';
del = s1->seq; // <<--
s1->seq = tmp;
free (del); // <--
return s1;

, And at least you'll stop leaking.

Segmentation fault when running, but success when debugging

7 Answers7