Cygwin renders GDB useless

Question

I'm currently running Cygwin on Windows in order to use GCC and avoid using Visual Studio and MinGW.

GCC works great, however GDB is not doing so well. GDB cannot detect a segmentation fault - you can see where this would be a huge problem. When running the default a.exe file produced by gcc with problematic code, the terminal outputs "Segmentation fault (core dumped)". That's fine, great. However when running this gcc -g (and possibly -O0) compiled program under gdb, this is my output.

Starting program: /home/Beo/a.exe 
[New Thread 25968.0x6500]
[New Thread 25968.0x64fc]
[Inferior 1 (process 25968) exited normally]

It should be detecting a segmentation fault here. When I run -backtrace the program (I can't backtrace afterward because there's no stack according to gdb), it does show a segmentation fault, but gives me no information as to where that occurs. The output is this:

Starting program: /home/Beo/a.exe -backtrace
[New Thread 25696.0x1208]
[New Thread 25696.0x6570]

Program received signal SIGSEGV, Segmentation fault.
0x5c636972 in ?? ()

I have no idea why it's doing this, any ideas? (I've tried increasing cygwin's memory limit. It doesn't fix anything.) (I should also point out that this isn't specific to this program, gdb detects the error just fine on my Linux box)

TEST CODE:

/*Heaps*/
#include <stdio.h>
#define LEFT(i) ((2*(i)) + 1)
#define RIGHT(i) ((2*(i)) + 2)
#define PARENT(i) ((i)/2)  

void buildheap(int heap[], int heapsize);
void max_heapify(int heap[], int heapsize, int index); 
void swap(int *, int *); 

int main(){
    int testheap[] = {0, 3, 8, 4, 2, 1, 99, 33, 3, 1, 2, 9}; 
    int size = sizeof(testheap) / sizeof(testheap[0]); 
    buildheap(testheap, size); 

    /*int i;
    for(i = 0; i < size; i++)
        printf("[%d]", testheap[i]); 
    putchar('\n'); */

    return 0; 
}

void swap(int *a, int *b){
    int temp = *a;
    *a = *b; 
    *b = temp; 
    return; 
}

void max_heapify(int heap[], int heapsize, int index){
    int l = LEFT(index); 
    int r = RIGHT(index);
    int largest = index; 

    if(/*l < heapsize &&*/ heap[l] > heap[largest])
        largest = l; 
    if(/*r < heapsize && */heap[r] > heap[largest])
        largest = r; 

    if(largest != index){
        swap(&heap[largest], &heap[index]); 
        max_heapify(heap, heapsize, largest); 
    }
    return; 
}

void buildheap(int heap[], int heapsize){
    int i = heapsize/2 - 1; 
    for(; i >= 0; i--)
        max_heapify(heap, heapsize, i); 

    return; 
}

Possible stack corruption (so gdb can't produce backtrace). Try adding breakpoints at some points... — dbrank0, Mar 07 '14 at 07:46
I tried adding breakpoints. At least those work in gdb, but gdb still doesn't detect segmentation faults. — user3391163, Mar 07 '14 at 08:24
Could you, please, add a simple C++ program to your question what causes a segmentation fault which gdb ignores or cannot detect? — , Mar 07 '14 at 09:18
http://stackoverflow.com/questions/19858344/analyze-crash-using-minidumps-and-gdb-for-mingw-compiled-executables/19863240#19863240 — , Mar 07 '14 at 09:21
I've added some code in the question. It's what was trying to debug when I ran into this problem. The problem occurs in the max_heapify method when it's called recursively a number of times. I've fixed the error, but I left it in for demonstration purposes. Also thank you for pointing out Dr. MinGW, I'll use it if we can't fix the problem with GDB. — user3391163, Mar 07 '14 at 17:29

score 0 · Answer 1 · answered Mar 07 '14 at 18:10

Have you tried with application verifier running? I get this same problem with mingw, but having application verifier fixes it. It's from Microsoft's webpage. It's real easy to use, just start it up, pick your .exe, and it runs in the background.

Cygwin renders GDB useless

1 Answers1