1

I have a piece of C code as below which crashes at the calloc() call below:

... some code
free (ipl->fldptr);
ipl->fldptr = calloc (flds*4, sizeof(struct fldptr_type));
...some more code

I tried to gdb it and I get the below backtrace at crash:

Program received signal SIGSEGV, Segmentation fault.
0x0000003ade478f94 in _int_malloc () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6.x86_64 libgcc-4.4.4-13.el6.x86_64 libstdc++-4.4.4-13.el6.x86_64
(gdb) bt
#0  0x0000003ade478f94 in _int_malloc () from /lib/libc.so.6
#1  0x0000003ade4796d8 in calloc () from /lib/libc.so.6
#2  0x0000000000daf00d in myfunction (ipl=0x106f75f0, flds=11)
    at myfile.c:1286

As part of debugging I do following on gdb prompt:

frame 2 to go to that user code stack frame and print values of variables(flds, pointers(ipl) and they seem ok. No NULL dereferencing apparently.

But still calloc() fails and it crashes there. This piece of code is executed multiple times successfully previously , but it crashes later when the application has run for some time. (Mem leak ?? tryint to get valgrind run on it, but it so happens that when running under valgrind memcheck tool, behaviour of my code crash is not repeatable)

I am looking for some pointers to help me debug and fix this.

Some info relevant - gcc: 4.4.4 . Red Hat Enterprise Linux server 6.0 64 bit Linux

goldenmean
  • 18,376
  • 54
  • 154
  • 211
  • 1
    Most likely you've corrupted the heap and destroyed *alloc() internal data structures. An easier way to find such an error would be to run your program through `valgrind`. – FatalError May 01 '12 at 14:57

1 Answers1

4

You probably have a corrupted heap, e.g. some memory which has been free-d too early (and still reused), or some buffer overflow (or invalid accesses like ptr[-3])

You should use valgrind to debug such issues.

You might also use Boehm's conservative garbage collector.

And you could also hunt such bugs manually, with gdb. Using the watch gdb command and disabling address space layout randomization should help.

I also suggest to always clear a pointer which you have free-d, so replace everywhere free(x) with free(x), x=NULL in your code (so if x gets incorrectly dereferenced, you'll get a SIGSEGV immediately).

You might also use a more recent version of GCC (current version is 4.7) with its stack protector feature. See this question.

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • 1
    I would not recommend Boehm gc anywhere, much less to a beginner at C. It's the quintessential example of "worse is better" and sure to lead to horrible code full of memory leaks and UB. – R.. GitHub STOP HELPING ICE May 01 '12 at 15:23
  • And it's still going to be incorrect and subject to memory leaks and memory exhaustion, often under the control of an attacker. This is what *conservative* GC means. See http://stackoverflow.com/questions/4039274/was-there-a-specific-reason-garbage-collection-was-not-designed-for-c/4039474#4039474 – R.. GitHub STOP HELPING ICE May 01 '12 at 15:33
  • I don't understand why using a conservative GC is incorrect. For instance, both `scm` and `guile` Scheme implementations use such a GC. Why should GC usage be incorrect? My belief is that most memory management schemes (such as inside GTK, or inside Qt or Apache or LibreOffice or inside the kernel, or inside the GCC compiler) can be called "garbage collector"... Boehm's GC has advantages and disadvantages. I am aware of them. – Basile Starynkevitch May 01 '12 at 16:45
  • As far as I know, GTK/glib use a system of reference counting, which is about as far from GC as you can get. I would suspect Qt does the same, being C++ (most good C++ code uses RAII which is abstractly equivalent to reference counting). As for scheme, there's a big difference in garbage collecting the embedded language's objects (which can easily be done correctly) and garbage collecting the host language's objects (which is impossible for C, by design). – R.. GitHub STOP HELPING ICE May 01 '12 at 17:20
  • Ref counting is a form of GC. (One of the weakest, since not handling curcular references). GC in C is not possible in general, but is possible with suitable conventions (like inside the kernel, or inside GCC or MELT, or with the Qish GC) or with libraries providing an approximation (like conservative GC do). And yes, I agree that C is a poor language to manage memory. – Basile Starynkevitch May 01 '12 at 17:44
  • Ref counting is not a form of GC. It's a precise, elegant form of memory management that works well in many cases but not circular references (unless you special-case types of references) and which had performance issues with parallelism (although those can be mitigated by being smarter about how you count references). GC is "worse is better". I disagree with you putting words in my mouth about C. I would say C is one of the **only** languages where's it's even possible to manage memory, albeit difficult. In other languages you just have to pray you don't run out... – R.. GitHub STOP HELPING ICE May 01 '12 at 21:10