4 ms·
As always, I recommend valgrind. $ gcc -Wall -g prog.c -o prog $ valgrind ./prog ... ==25494== Process terminating with default action of signal 11 (SI
by 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 agoVery cool, this would help a lot indeed. Are there other such tools a casual C programmer should be aware of?
- protomikron 10y agoYes, 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 agoTurn 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 agoAny good references to gathering stats using debugger and visualizing with Python?
- Elv13 10y agoGood 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...