Question

First and foremost, apologies for any cross-posting. Hope I’m not repeating an issue here, but I was unable to find this elsewhere (via Google and Stack Overflow).

Here’s the gist of the error. If I call printf, sprintf or fprintf anywhere within my code, to display a float, I get a SIGSEGV (EXC_BAD_ACCESS) error. Let me give an example.

The following throws the error:

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

This code does not:

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

I realize there’s an implicit conversion there, but I’m not concerned with that. I just can’t fathom why printing a float vs. printing an integer would throw an error.

Note: Part of the code uses malloc to create some very large multidimensional arrays. However, these arrays are not being referenced in any way for these print statements. Here’s an example how I’m declaring these arrays.

#define X_LEN 20
#define XDOT_LEN 20
#define THETA_LEN 20
#define THETADOT_LEN 20
#define NUM_STATES (X_LEN+1) * (XDOT_LEN+1) * (THETA_LEN+1) * (THETADOT_LEN+1)
#define NUM_ACTS 100

float *states = (float *)malloc(NUM_STATES * sizeof(float));
// as opposed to float states[NUM_STATES] (more memory effecient)


float **q = (float**)malloc(NUM_STATES * sizeof(float*));

for(int i=0; i < NUM_STATES; i++) {
    float *a = (float*)malloc(NUM_ACTS * sizeof(float));
    for(int j=0; j < NUM_ACTS; j++) {
        a[j] = 0.0f;
    }
    q[i] = a;
}

And then the above printf statements occur later in the code.

The reason I included the malloc stuff is because from what I understand, SIGSEGV is related to poorly formed malloc calls. So, if the array initializations are what’s causing the problem, I would like to know:

• why?
• how can I change the malloc code to solve this problem?

I’ve included the crash log generated by OS X, just in case that helps anybody out.

Process:         pole [5453]
Path:            {REDACTED}
Identifier:      pole
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  bash [5441]

Date/Time:       2009-12-08 11:38:38.358 -0600
OS Version:      Mac OS X 10.6.2 (10C540)
Report Version:  6

Interval Since Last Report:          130074 sec
Crashes Since Last Report:           68
Per-App Crashes Since Last Report:   63
Anonymous UUID:                      CA20CF15-8C46-4C85-A793-6C69F9F40140

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000100074f3b
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib               0x00007fff828d489e __Balloc_D2A + 164
1   libSystem.B.dylib               0x00007fff828d49b8 __d2b_D2A + 45
2   libSystem.B.dylib               0x00007fff828e8c74 __dtoa + 320
3   libSystem.B.dylib               0x00007fff828aa960 __vfprintf + 4980
4   libSystem.B.dylib               0x00007fff828ec7db vfprintf_l + 111
5   libSystem.B.dylib               0x00007fff828ec75e fprintf + 196
6   pole                            0x00000001000028b5 Balance::sarsa() + 187
7   pole                            0x0000000100002e54 main + 49
8   pole                            0x00000001000010a8 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000001  rbx: 0x000000010042cca0  rcx: 0x000000010042cca8  rdx: 0x0000000100074f3b
  rdi: 0x000000000000000e  rsi: 0x00007fff5fbfecbc  rbp: 0x00007fff5fbfeba0  rsp: 0x00007fff5fbfeb90
   r8: 0x00007fff5fbff0b0   r9: 0x0000000000000000  r10: 0x00000000ffffffff  r11: 0x000000010083a40b
  r12: 0x0000000000000001  r13: 0x00007fff5fbfecb8  r14: 0x00007fff5fbfecbc  r15: 0x000000010000363e
  rip: 0x00007fff828d489e  rfl: 0x0000000000010202  cr2: 0x0000000100074f3b

Binary Images:
       0x100000000 -        0x100003fff +pole ??? (???)  {REDACTED}
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???)  /usr/lib/dyld
    0x7fff81697000 -     0x7fff8169bff7  libmathCommon.A.dylib ??? (???)  /usr/lib/system/libmathCommon.A.dylib
    0x7fff8289c000 -     0x7fff82a5aff7  libSystem.B.dylib ??? (???)  /usr/lib/libSystem.B.dylib
    0x7fff83c4c000 -     0x7fff83cc9fef  libstdc++.6.dylib ??? (???)  /usr/lib/libstdc++.6.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???)  /usr/lib/libSystem.B.dylib

Model: MacBookPro4,1, BootROM MBP41.00C1.B03, 2 processors, Intel Core 2 Duo, 2.4 GHz, 2 GB, SMC 1.27f2
Graphics: NVIDIA GeForce 8600M GT, GeForce 8600M GT, PCIe, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8C), Broadcom BCM43xx 1.0 (5.10.91.19)
Bluetooth: Version 2.2.4f3, 2 service, 1 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS542520K9SA00, 186.31 GB
Parallel ATA Device: MATSHITADVD-R   UJ-867
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8502, 0xfd400000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0230, 0x5d200000
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0x5d100000
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x1a100000
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x820f, 0x1a110000

Thanks.

Answer 1

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.