Some possible sources of segfault/access violation in D programs:
- Run into an assert(false) in the source code in a release build.
- Dereference null.
- Integer division by zero.
- Stack overflow from recursion.
- Illegal memory access from raw pointers or with disabled array bounds checks. Not all bad accesses are caught by the operating system to segfault immediately. The program might continue happily and have corrupted memory.
All of these indicate a bug in in the software. These are never to blame on bad user input; it's a bug; by principle, programs should not segfault. E.g.,
assert(false) marks code that the author thought should be completely unreachable.
The usual method of investigation is to run a debug build with a debugger attached, provoke the segfault a second time, and look at the backtrace in the debugger. E.g., with the popular debugger gdb:
dub buildgdb -ex run bin/lixLix's window will appear, do things in Lix to repro a segfault.
btWhen you're done, exit gdb by entering
q or pressing Ctrl+D.
-- Simon