3 ms·

It covers, but very slightly (see below, I skimmed it exactly to look for it). My observation is that this is really hard for many people. I helped couple of my

It covers, but very slightly (see below, I skimmed it exactly to look for it). My observation is that this is really hard for many people. I helped couple of my course mates with background mainly in Python and this was the only thing they struggled with, and they struggled hard. It forces you to be very observant and conscious about the situation. Until you get that far, you will continue to suffer. C is really unforgiving. Every once in a while, you'll see a C program crash, with a message like “segmentation fault” or "bus error.” It won't helpfully include any indication of what part of the program is at fault: all you get is those those two words. Such errors usually mean that the program attempted to access an invalid memory location. This may indicate an attempt to access an invalid array index, but typically the index needs to be pretty far out of bounds for this to occur. (It often instead indicates an attempt to reference an uninitialized pointer or a NULL pointer, which we'll discuss later.)"

protomikron 10y ago
As always, I recommend valgrind. $ gcc -Wall -g prog.c -o prog $ valgrind ./prog ... ==25494== Process terminating with default action of signal 11 (SIGSEGV) ==25494== Access not within mapped region at address 0x0 ==25494== at 0x400532: main (prog.c:5) ==25494== If you believe this happened [...] ... $ This helps a lot while debugging. Note that it is also helpful when debugging memory leaks and can give you the exact line in your code where you issued alloc() that you did not free later.
- eveningcoffee 10y ago
  Very cool, this would help a lot indeed. Are there other such tools a casual C programmer should be aware of?
  - protomikron 10y ago
    Yes, there are gazillions of useful tools, but another important point is that C is tightly coupled to *nix systems and the best platform to develop C is definitely a Linux-based system (ignoring embedded systems for the meantime, where C also shines), as otherwise most quality information that you find in the interwebs won't work for you.
  - Elv13 10y ago
    Turn on all compiler warnings (-Weverything for Clang and RTFM for GCC (no, -Wall doesn't turn all the warnings on)). Scanbuild (LLVM based, Linux and macOS) Perf (recent Linux) or DTrace (macOS, SmartOS, Solaris and FreeBSD) Valgrind (Linux, macOS) with the KCacheGrind/QCacheGrind (CPU usage), Valkyrie (leaks and undefined behavior) and Massif-visualizer (memory usage) GUIs The compiler sanitizers (GCC, LLVM, Linux and macOS) strace (Linux) HeapTrack (Linux, a true hidden gem, best memory profiler ever) Binutils (Linux, macOS) And really, get to know your debugger. Both GDB and the Visual studio debugger are extremely powerful. If you think a debugger does beakpoints and nothing else, you really, really need to get to know your debugger better. LLDB is getting there too, it will catch up soon (surprising given how long it took the other 2 to mature). For people from a Python background, know that both GDB and LLDB are available as a Python shell with full access to the C program internal. You can add triggers to execute Python callbacks, conditional breakpoints and even gather stat and have them display in MathPlotLib or iPython Notebook.
    - jononor 10y ago
      Any good references to gathering stats using debugger and visualizing with Python?
      - Elv13 10y ago
        Good luck finding anything. It is in many performance ninjas arsenal, but very little documented. Here is an untested mix of some other scripts that might less or more almost work. At least it can get you started: https://gist.github.com/Elv13/48b43ead347faba1b59378267d2364e7 https://gist.github.com/Elv13/48b43ead347faba1b59378267d2364...
Elv13 10y ago
This has changed since 2011. Both GCC and LLVM/Clang support export CFLAGS="-ggdb -fsanitize=address" And few other "sanitizers". They add a runtime to the binary so you get the backtrace, detect runtime "silent" errors (undefined behaviors) and overall help develop C/C++ programs.

protomikron 10y ago

As always, I recommend valgrind. $ gcc -Wall -g prog.c -o prog $ valgrind ./prog ... ==25494== Process terminating with default action of signal 11 (SIGSEGV) ==25494== Access not within mapped region at address 0x0 ==25494== at 0x400532: main (prog.c:5) ==25494== If you believe this happened [...] ... $ This helps a lot while debugging. Note that it is also helpful when debugging memory leaks and can give you the exact line in your code where you issued alloc() that you did not free later.

eveningcoffee 10y ago
Very cool, this would help a lot indeed. Are there other such tools a casual C programmer should be aware of?
- protomikron 10y ago
  Yes, there are gazillions of useful tools, but another important point is that C is tightly coupled to *nix systems and the best platform to develop C is definitely a Linux-based system (ignoring embedded systems for the meantime, where C also shines), as otherwise most quality information that you find in the interwebs won't work for you.
- Elv13 10y ago
  Turn on all compiler warnings (-Weverything for Clang and RTFM for GCC (no, -Wall doesn't turn all the warnings on)). Scanbuild (LLVM based, Linux and macOS) Perf (recent Linux) or DTrace (macOS, SmartOS, Solaris and FreeBSD) Valgrind (Linux, macOS) with the KCacheGrind/QCacheGrind (CPU usage), Valkyrie (leaks and undefined behavior) and Massif-visualizer (memory usage) GUIs The compiler sanitizers (GCC, LLVM, Linux and macOS) strace (Linux) HeapTrack (Linux, a true hidden gem, best memory profiler ever) Binutils (Linux, macOS) And really, get to know your debugger. Both GDB and the Visual studio debugger are extremely powerful. If you think a debugger does beakpoints and nothing else, you really, really need to get to know your debugger better. LLDB is getting there too, it will catch up soon (surprising given how long it took the other 2 to mature). For people from a Python background, know that both GDB and LLDB are available as a Python shell with full access to the C program internal. You can add triggers to execute Python callbacks, conditional breakpoints and even gather stat and have them display in MathPlotLib or iPython Notebook.
  - jononor 10y ago
    Any good references to gathering stats using debugger and visualizing with Python?
    - Elv13 10y ago
      Good luck finding anything. It is in many performance ninjas arsenal, but very little documented. Here is an untested mix of some other scripts that might less or more almost work. At least it can get you started: https://gist.github.com/Elv13/48b43ead347faba1b59378267d2364e7 https://gist.github.com/Elv13/48b43ead347faba1b59378267d2364...

Elv13 10y ago

This has changed since 2011. Both GCC and LLVM/Clang support export CFLAGS="-ggdb -fsanitize=address" And few other "sanitizers". They add a runtime to the binary so you get the backtrace, detect runtime "silent" errors (undefined behaviors) and overall help develop C/C++ programs.