CODEWITHSUNDEEP
crashgdbsegmentation-fault
Sterling
Sterling

Reputation: 4213

Crashes normally, but not with GDB

My program crashes with a segmentation fault when ran normally. So I run it with GDB, but it won't crash when I do that. Why might this occur?

I know that Valgrind's FAQ mentions this (not crashing under Valgrind), but I couldn't really find anything about this related to GDB in Google.

Upvotes: 27

Views: 16215

Answers (11)

Dmitry S.
Dmitry S.

Reputation: 8513

Calling set disable-randomization off in gdb fixed this issue for me.

Upvotes: 0

Jack
Jack

Reputation: 11

I just had a similar problem. In my case, it was connected to pointers in my linked list data structure. When I dynamically created a new list without initializing all the pointers inside the structure my program crashes outside GDB.

Here are my original data structures:

typedef struct linked_list {
    node *head;
    node *tail;
} list;

typedef struct list_node {
    char *string;
    struct list_node *next;
} node;

When I created a new "instance" of a list specifying its head and tail, the program crashed outside GDB:

list *createList(void) {
    list *newList = (list *) malloc(sizeof(list));
    if (newList == NULL) return;

    return newList;
}

Everything started to work normally after I changed my createList function to this:

list *createList(void) {
    list *newList = (list *) malloc(sizeof(list));
    if (newList == NULL) return;

    newList->head = (node *) 0;
    newList->tail = (node *) 0;

    return newList;
}

I hope it might help to someone in case of something similar to my example with non-initialized pointers.

Upvotes: 0

Gangadhar
Gangadhar

Reputation: 45

I faced a similar issue, where a thread was killed randomly, and a core dump was not created. When I attached GDB, the issue wouldn't reproduce.

To answer your question of why this is happening, I think this is timing issue. Since GDB will collect some data related to thread execution, it might slow down the process execution speed. If thread execution is slow issue, it isn't reproducing.

Upvotes: 0

TheSHEEEP
TheSHEEEP

Reputation: 3132

I also had this happen to me sometimes.

My solution: clean & rebuild everything.

I am not saying that this always solves all problems (and in the OP's case, the problem was something really wrong), but you can save yourself some trouble and time if you do this first when encountering such really weird "meta" bugs.

At least in my experience, such things more often than not come from old object files that should have been rebuilt, but were not. In both MinGW and regular GCC.

Upvotes: 0

ks1322
ks1322

Reputation: 35825

Check for the return value of the pthread_detach call. According to your answer, you are probably passing an invalid thread handle to pthread_detach.

Upvotes: 1

Pete Wilson
Pete Wilson

Reputation: 8704

When you run your code with GDB, it gets moved around. Now the illegal address you tried to reference before—the one that caused the segfault—is legal all of a sudden. It's a pain, for sure.

But the best way I know of to track down this kind of error is to start putting in printf()s all over the place, gradually narrowing it down.

Upvotes: -3

fvu
fvu

Reputation: 32973

It sounds like a Heisenbug you have there :-)

If the platform you're working with is able to produce core files, it should be possible to use the core file and GDB to pinpoint the location where the program crashes. A short explanation can be found here.

Let it crash a couple of times though. When the crash is caused by stack smashing or variable overwriting, the bug may seem to "walk around".

Upvotes: 9

kestrel
kestrel

Reputation: 1344

I've had this happen to me before (you're not alone), but I can't remember what I did to fix things (I think it was a double free).

My suggestion would be to set up your environment to create core dumps, and then use GDB to investigate the core dump after the program crashes. In Bash, this is done with ulimit -c size, where size can be anything; I personally use 50000 for 25 MB max size; the unit is in 512-byte increments.

You can use GDB to investigate a core dump by using gdb program core.

Upvotes: 17

the.malkolm
the.malkolm

Reputation: 2421

If a bug depends on timing, GDB could prevent it from repeating.

Upvotes: 1

Daniel Trebbien
Daniel Trebbien

Reputation: 39218

Try attaching to the running process within gdb, continuing, and then reproducing the crash. In other words, don't start the program within gdb; instead, start the program normally and then attach <pid>.

Sometimes when stepping through lines individually, a race condition that causes the program to crash will not manifest, as the race hazard has been eliminated or made exceedingly improbable by the "lengthy" pauses between steps.

Upvotes: 5

Sterling
Sterling

Reputation: 4213

Well I tracked it down to a pthread_detach call. I was doing pthread_detach(&thethread). I just took away the reference and changed it to pthread_detach(thethread) and it worked fine. I'm not positive, but maybe it was a double free by detaching the reference then destroying it again when it went out of scope?

Upvotes: 3

Related Questions