ansaurus

Question

Answer 1

+1 A:

it is possible that you have a pointer arithmetic error or a buffer overflow which has the side effect of breaking the printf.

Try commenting out the majority of the code (except the printf) and see if it crashes. If it doesn't, then little by little un-\comment parts until you get the crash back. The you'll know where the problem is.

Also, if you are using linux or any unix variant, look into using valgrind as well.

EDIT:

I see this in your error report:

0   libSystem.B.dylib               0x00007fff828d489e __Balloc_D2A + 164

That's where the actual crash is, which appears to be a low level allocation routine. I would guess that you have a buffer overflow which is corrupting the free list, making certain future allocations break (such as in this printf).

Evan Teran 2009-12-08 18:02:04

Answer 2

A:

Possibility number one is that you are just plain malloc()'ing enough memory for your arrays that the printf() attempts to malloc() a little more,and fails. I think this is highly unlikely.

Possibility number two is that your printf() is not as simple as you are showing, but rather is some rather complicated multilevel pointer expression, and that expression is going wild somewhere.

John R. Strohm 2009-12-08 18:03:19

Answer 3

+1 A:

SIGSEGV occurs either when you access a virtual address that is not mapped to anything or when you access an address in a way which is not allowed (e.g., trying to write to a read-only area). As you say, segmentation faults can be related to heap corruption. This is because internally, most malloc implementations interleave bookkeeping information with allocated data on the heap. If that bookkeeping information gets corrupted, malloc's behavior is undefined. You may not see any errors until much later in the program.

In this case, printf is probably allocating some memory internally, which is triggering the fault. Probably the best way to fix this is to run your program with valgrind, which will notify you of any heap corruption as soon as it happens.

Jay Conrod 2009-12-08 18:04:10

Answer 4

A:

Some implementations of printf do a mallocs when processing "%f"s. If it IS doing this then if you have overflowed memory at some point (ie written past the end of the allocation) the printf can then try and make an allocation and find the heap corrupted and throw an error ...

just a thought.

Edit: Its probably worth looking at how your state array is filled ... the other 2 appear fine but you could be writing past the end anywhere ...

Goz 2009-12-08 18:05:37

Answer 5

A:

printf("%f", parm) expects the parameter to be a double. Your f is a float which gets implicitly converted to a double.

Maybe the implicit conversion is messed up ???

Try an explicit conversion

float f = 0.5f;
printf("%f\n",(double)f);

or even

float f = 0.5f;
double ff = f;
printf("%f\n",ff);

pmg 2009-12-08 20:42:39

Answer 6

+3 A:

You have a bug elsewhere in your code not related to the printf statement. You're stomping on memory somewhere, but the problem doesn't manifest itself until printf tries to allocate some memory with __BAlloc_D2A, which crashes because the heap data structures it uses to keep track of free memory blocks have been corrupted.

To try to detect where you're stomping on memory, there are a number of tools available. If you were on Linux, I would suggest using valgrind, which essentially runs your code in a virtual machine and tells you whenever you do anything illegal like read/write memory out of bounds, read an uninitialized variable, etc. However, it's not available in Mac OS X (yet).

One option is to use libgmalloc:

% cat gmalloctest.c
#include <stdlib.h>
#include <stdio.h>

main()
{
  unsigned *buffer = (unsigned *)malloc(sizeof(unsigned) * 100);
  unsigned i;

  for (i = 0; i < 200; i++) {
    buffer[i] = i;
  }

  for (i = 0; i < 200; i++) {
     printf ("%d  ", buffer[i]);
  }
}

% cc -g -o gmalloctest gmalloctest.c
% gdb gmalloctest
Reading symbols for shared libraries .. done
(gdb) set env DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib
(gdb) r
Starting program: gmalloctest
Reading symbols for shared libraries .. done
GuardMalloc: Allocations will be placed on 16 byte boundaries.
GuardMalloc:  - Some buffer overruns may not be noticed.
GuardMalloc:  - Applications using vector instructions (e.g., SSE or Altivec) should work.
GuardMalloc: GuardMalloc version 19

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xb000d000
0x00001f65 in main () at gmalloctest.c:10
10          buffer[i] = i;
(gdb) print i
$1 = 100
(gdb) where
#0  0x00001f65 in main () at gmalloctest.c:10
(gdb)

See also Enabling the Malloc Debugging Features.

Adam Rosenfield 2009-12-08 21:19:30

Actually, as of Valgrind 3.5.0, Mac OS X (10.5.x) *is* supported. BTW, Valgrind *rocks*.

Dan Moulding 2009-12-09 02:19:00

Ah, good to know. Maybe I should finally upgrade away from 10.4. And yes, Valgrind does indeed rock hard.

Adam Rosenfield 2009-12-09 05:59:38

Answer 7

A:

Just a guess, but have you done #include <stdlib.h>? Without a prototype for malloc() in scope, the compiler assumes that malloc() returns int, which is obviously not true.

If I am right (even otherwise), it exposes a reason for not casting the return value of malloc() in C. Note that if you are writing code for both C and C++, you will need to, but for pure C, don't cast the return value of malloc(), and let the compiler do the right thing for you.

So, instead of:

T *data = (T *) malloc(sz * sizeof(T));

do this instead:

#include <stdlib.h>
...
T *data = malloc(sz * sizeof *data);

Here, T is any type. The advantages are:

The compiler will complain if you forgot to #include <stdlib.h>,
If you change the type of data, the malloc() call doesn't need to change, and
I think it's easier to read and less error-prone.

By casting the return value of malloc(), you don't give the compiler a chance to warn you about missing inclusion of stdlib.h.

Alok 2009-12-09 01:35:11

ansaurus

tags:

views:

answers:

SIGSEGV, (seemingly) caused by printf

related questions