Debugging Segmentation Fault for D program using LLDB

Question

I'm currently trying to debug a Segmentation Fault: 11 on Mac in an executable produced by the DMD compiler, using LLDB.

The thing is I'm quite lost since I'm not too familiar with debugging tools.

All I do is start lldb with my binary and then execute the command run with the appropriate arguments. When the application crashes, I'm doing a thread backtrace and this is the output I'm getting:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef3fffd0)
    frame #0: 0x00000001003f59e0 arturo`_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl + 8
arturo`_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl:
->  0x1003f59e0 <+8>:  movq   %rbx, -0x50(%rbp)
    0x1003f59e4 <+12>: movq   %r12, -0x48(%rbp)
    0x1003f59e8 <+16>: movq   %r13, -0x40(%rbp)
    0x1003f59ec <+20>: movq   %r14, -0x38(%rbp)
Target 0: (arturo) stopped.
(lldb) thread traceback
invalid command 'thread traceback'.
(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef3fffd0)
  * frame #0: 0x00000001003f59e0 arturo`_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl + 8
    frame #1: 0x00000001003ed77e arturo`_D2gc4impl12conservativeQw14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ + 122
    frame #2: 0x00000001003f87a7 arturo`gc_qalloc + 59
    frame #3: 0x00000001003e389f arturo`_D4core6memory2GC6qallocFNaNbmkxC8TypeInfoZSQBqQBo8BlkInfo_ + 43
    frame #4: 0x00000001000037f3 arturo`_D3std5array__T8AppenderTAyaZQo13ensureAddableMFmZ9__lambda3MFNaNbNeZS4core6memory8BlkInfo_ + 43
    frame #5: 0x000000010000372d arturo`_D3std5array__T8AppenderTAyaZQo13ensureAddableMFNaNbNfmZv + 269
    frame #6: 0x00000001001d6a18 arturo`_D3std5array__T8AppenderTAyaZQo__T3putTAxaZQjMFQiZ10bigDataFunMFNaNbNfmZAa + 24
    frame #7: 0x00000001001d69b1 arturo`_D3std5array__T8AppenderTAyaZQo__T3putTAxaZQjMFNaNbNfQoZv + 33
    frame #8: 0x00000001000057b1 arturo`_D3std6format__T10FormatSpecTaZQp__T17writeUpToNextSpecTSQCd5array__T8AppenderTAyaZQoZQByMFNaNlNfKQBqZb + 121
    frame #9: 0x0000000100023ab7 arturo`_D3std6format__T14formattedWriteTSQBg5array__T8AppenderTAyaZQoTaTQjZQCaFNaNfKQBsMxAaQBcZk + 103
    frame #10: 0x0000000100023990 arturo`_D3std6format__TQkTaTAyaZQtFNaNfxAaQoZQr + 88
    frame #11: 0x00000001001a1b6f arturo`_D5panic14getErrorStringFAyaQdAQgQdZQl + 1199
    frame #12: 0x00000001001a2073 arturo`_D5panic31WARN_AssignmentInsideExpression6__ctorMFAyaZCQCbQBy + 227
    frame #13: 0x00000001001a8847 arturo`_D6parser9statement9Statement7executeMFPC5value5ValuebZQp + 87

Any idea where to look? Seems like it has something to do with the Garbage Collector, but still not sure. Could it be an out-of-memory error?

Any pointers would be more than welcome!