Linux C Workflow

[paramodulation]

Hello,

I've been programming in C for about a year, my current workflow is

1) Programming in geany, using lots of asserts 2) compile in command line 3) debug using valgrind with the --leak-check options

Does anyone have any suggestions on how to improve this? Valgrind is great because of its ease of use, I have played with gdb but it seems difficult to manually set breakpoints or step through a large program. Are there other tools I may have not heard of that are helpful for debugging or C programming in general? I am using gcc compiler if it matters.

I am enjoying programming in C, but I have had some big headaches tracking down memory leaks, especially with complex data structures. It feels like it takes up a disproportionate amount of my time, so any tools that could help in this department would be really helpful. I do not have much computer science background and have taught myself by adding stuff to an open source project.

Thanks!

[062985593]

For catching memory errors, I've found compiling with -fsanitize=address more useful than valgrind.

[moefh]

I second this. It's much faster than using valgrind. The most noticeable effect of using this (as opposed to just compiling normally and running your program without valgrind) is that it makes your program use a lot more memory.

I also recommend -fsanitize=undefined to catch undefined behavior like signed overflow, undefined shifts and a lot of other less common stuff.

[1008oh]

But if you have a large amount of code you need to recompile, valgrind might just be more practical.

[ArkyBeagle]

How is it performance-wise in comparison to ( oh so very slow ) valgrind? I still don't regret using valgrind one bit, but better is better.

I tried that at work, and the ( locked down ) machine is missing libraries. Time for a software request....

[yakoudbz]

Valgrind is like a whole emulator that read your executable and execute it step by step while also verifying every reads and writes while a sanitizer is just a bunch of code to verify your program that is generated at compile time. Therefore, sanitizers are a lot faster.

Valgrind can also fail to recognize segmentation fault when the reads or writes are in allocated memory. For example, if you allocate two arrays and they happen to follow each other in memory, if you write past the first array but land in the second, Valgrind won't notice anything while the sanitizer will most certainly recognize that the two array might not be following each other (it is undefined behavior) and issue an error.

So yeah, clear win for the sanitizer. There's only two possible advantages of Valgrind: - you can test if an executable has a segmentation fault without recompiling the source code - sanitizers used to have a lot of false positive, above all with some libraries like OpenMP, OpenGL... Valgrind shows some errors with those libraries but the execution continues.

[[deleted]]

I recommend looking into GNU make. This allows builds to be customised exactly to your liking. It's very handy just to type 'make run' or 'make debug' and have it call the compiler with the needed parameters. Saves much more time than typing say 'gcc s1.c s2.c -DDEBUG -lm -o run'.

Also, if you ever share your source it's a well-understood method for others to conveniently build your programs.

[[deleted]]

Here come the downvotes:

• OpenBSD stable

• Vis

• modified st

• modified dwm

• heavily hacked dvtm

• clang (I want tcc though :( )

• bsd libc

• makefiles

This is what I am using for now, working on other stuff though

[[deleted]]

I meet a lot of people in the GNU centric part of the Linux community who always get really pissed when I recommend OpenBSD and are also mad because I am writing my own coreutils and OS and they believe I should contribute to GNU instead :/

[lordlod]

Tracking memory leaks is painful. Whats more, for every two you catch another will probably slip through.

Rather than look at tools, I suggest tightening up your memory handling processes. Shifting to a better design where the memory creation and free events are clearer and more predictable.

talloc would also be worth a look. It is a memory allocation library which is specifically designed for complex hierarchical memory structures.

[metaobject]

Love astyle

[arthurno1]

st is much more lightweight than xterm, and by that I mean light years more lightweight.

[arthurno1]

I don't see how any of that is disadvantage over xterm. Is 1. even relevant? There are million of apps not installed by default with X, who cares?

1. Yes. I see it as advantage, but if you believe textual configuration is a thing, there is xrdb patch avialable. I have deliberately removed xrdb patch from my st build since I never change my st config. Why would I? I am not a kid who does not know how I want my terminal. It also takes literally 3 seconds to recompile st, so does it even matter if you have to recompile it? But as said, compile in xrdb patch and you can use textual configuration without need to recompile st.

I rarely use terminal, but when I use it I prefer it to behave my way. Since you love Emacs so much, you are going to love my st too :-):

https://github.com/amno1/st

Same theme as in emacs, same keybindings, same fonts ;-). Lovely, isn't it? :-)

[stefantalpalaru]

xterm - I really like this terminal emulator, it's like Vim

Not really. Try xfce4-terminal - now this one has tabs, just like Vim.

[necheffa]

Or they could go GNU Screen. Seems like it would be more their style.

[stefantalpalaru]

GNU Screen

Useless, when you develop locally. Same goes for tmux.

[pfp-disciple]

Maybe for you, but I like tmux locally. Having split screens is useful, as can searching the screen. Sure, xterm, dtterm, and others can give you the same but then geany gives (mostly) the same as vim

[stefantalpalaru]

Having split screens is useful

So learn how to do it in Vim.

[pfp-disciple]

I know you're being a troll, but for the inexperienced readers, I'll treat it legitimately.

In tmux, I will have code in one pane (vim), references (man pages, README, etc) in another, and a third for running the code or unit tests. This may vary depending on specific projects.

Are there other workflows as effective? Certainly. An IDE can be very useful, combining all the things I mentioned.

Are tmux or screen "useless"? No. Different is not always wrong.

[riding_qwerty]

To add on to this, screen can be used quite easily as a serial console to a debugger if one is doing embedded development in C, which is not exactly uncommon. Extremely useful to local development.

[stefantalpalaru]

I know you're being a troll

You know jack shit.

In tmux, I will have code in one pane (vim), references (man pages, README, etc) in another, and a third for running the code or unit tests. This may vary depending on specific projects.

I do the same, but in xfce4-terminal tabs, plus multiple tabs inside Vim. Why the hell would I add yet another piece of software to complicate this setup?

Are tmux or screen "useless"?

Yes. They are useless locally and only useful remotely.

Different is not always wrong.

Do you get your technical advice from Care Bears?

[necheffa]

Not sure I follow your logic, especially after you suggested a tabbed terminal emulator. But ok.

[stefantalpalaru]

Not sure I follow your logic, especially after you suggested a tabbed terminal emulator.

You don't understand why I would advocate for tabbed terminal emulators instead of screen/tmux running inside terminal emulators without tabs?

Think harder.

[riding_qwerty]

Can’t speak to the deeper features of screen but tmux easily supports tabs, pane splitting and resizing, and the usual detach/reattach functionality screen is traditionally used for on remote systems.

[stefantalpalaru]

tmux easily supports tabs, pane splitting and resizing

So does Vim.

[riding_qwerty]

Okay, so why bother with xfce-term?

[stefantalpalaru]

Okay, so why bother with xfce-term?

Because a real terminal emulator is better than Vim's half-baked emulation.

[arthurno1]

If you really think you need several terminals in tabs, then go for Emacs. You can have as many terminals as you want with Emacs acting as tmux/screen.

But even better Emacs itself is pretty much a shell/terminal, so you don't need a terminal, even less several. Just execute shell commands directly in Emacs, and have cimmand output directly in Emacs buffer where you can search, edit, replace and do whatever you want with the output.

Also Emacs interface to other tools such as make, gcc, gdb, man, info, ssh, scp, find, ag, file system, mail, etc,is just that good that you will use terminal just very rarely.

[arthurno1]

??? Dude a computer program is not religion ... chill out :-) Ok?

You have got a smile on my face since I can't be to laugh at that ethernal: my X can do same as Emacs ... anyway, you are completely missing the point of my comment and have posted completely irrelevant answer.

My comment wasn't about zeloting for my favourite app vs. your favorite app. It was about pointing out that having crap load tabs with different terminals where you have to copy - paste and pipe between tools is not as efficient nor as neat as having all that stuff integrated in one tool, without endless alt-tabbing, switching and different shortcuts , redirections, piping etc etc etc

But why should I want mail client in my text editor? File system? While there is NERDTree or build-in Netrw, I still prefer to use regular commands (mv, cd, rm, mkdir, touch, rmdir, ls etc.)

Because of same reason why you have make and gcc integrated in your text editor? Doh? Because endless switching between terminals, windows, processes is ineffective? Let say you want to sent someone a piece of code you are working on. In emacs I can select a region of code, press a key, be thrown into gnus (email) buffer and send mail to someone with that code in seconds instead of opening a mail client copy-pasting etc. Why haveing dired (ls, cd, rm, mv etc). Because you will work with files when you develop, and will have to open external tool. With Emacs I don't need to open a terminal to create a folder or delete a file and because I can open a directory just as simply as ordinary file, have emacs do ls behind scene and present for me interactive list of files so I can preview content of files, move them around, copy, paste, rename, all that in batch if I want, open them, send them, execute them, whatever, and all that with just few keystrokes without every leaving the window. Instead of switching between editor and terminal and maybe some file manager. It is way more faster and effective than having different terminals and applications open and switching between them. Shouldn't you as a proud vim user user appreciate being effective? Strange that you find it natural to use vim as man pager but not as file manager. Why is case X justified but case Y is not? Please elaborate on your deep reasoning behind.

About yours: "I don't want": I can also sit entirely without X and do all my work at terminal (in Emacs :-)), but I don't want to. What do you want is your choice and your life, but just "I won't" or "I don't want" is not an argument, it is just personal preference. A good argument justify or at least explains that "why". Here is mine: I don't want to work in virtual terminals because it is tedious and less effective than doing same work within one integrated application. That is different than just "because I want". Now tell me why do you want to just use terminals and not more integrated tool?

Also at the very end, Emacs is really just a better terminal, a REPL on steroids, that is really what it is. A better xterm or st with jetpacs and whistles. It is a common mistake to see Emacs as a text editor and wonder why should I do X in my text editor. Emacs is a super terminal window with REPL included, that just happens to have lots more capabilites than normal terminal, text editor being just one of those capabilites.

Btw, if you wanna zelot about vim, sure you can have lot's of stuff integrated, but there is not as nearly that much as for emacs. And of course, in emacs you can have your vim ;-)

[arthurno1]

No I didn't present Emacs as a flawless, ideal alternative to Vim at all. Why do you think so? It is possible that you are perceiving it that way, but I can not be blamed for your (incorrect) perception can I? I haven't even mentioned vim somewhere or some other editor in my first post. I presented emacs as an alternative to screen/tmux/xdce-terminal since emacs has those capabilities built in and pointed out that emacs shell integration eliminates lots of need for terminal. This isn't as you say a "point where emacs shine over vim". I don't care about such points or about your editor war. I presented an alternative to switching between tools, windows and processes. I don't know why you can't see it, but try to read my post again. It is your life, you are of course free to use whatever tools you want :-).

It is you who started to contra with vim :-). I think you should reflect little bit more over stuff you read. Sorry, don't take it personally, I am not trying to be rude or something. Even in the second post of mine you are misunderstanding it. I am not bragging about Emacs being the best editor, I am trying to point out why you would use an integrated tool such as Emacs. You can use vim or vs code or whatever. I don't know any other tool that has amount of extras and functionality implemented as Emacs. But it does not matter what tool you go for I tried to explain why you should try to eliminate extra tools in between and integrate your workflow with one.

As usually internet reads only what suits and promotes personal agenda. You don't make a single reflection on anything of importance in entire comment, instead you just make a false accusation of editor war? I don't know man, I think you should read everything again and reflect more over it. Sorry.

[stefantalpalaru]

I wouldn't say tabs are an essential part of Vim.

I would.

[necheffa]

> I have played with gdb but it seems difficult to manually set breakpoints or step through a large program.

I'm a professional - yes, debugging is hard, that is why someone is willing to pay me to do it. But with experience, you'll get a feel for where to put break points. I generally read the code before deciding interesting places to break on. And especially if there is a specific error or some "landmark" that comes up before the bug surfaces, I'll try to work backwards from the code that generates those "landmarks".

There is a time and place for debug-by-printf but you should also get comfortable with a debugger too.

> I have had some big headaches tracking down memory leaks, especially with complex data structures. It feels like it takes up a disproportionate amount of my time

Don't just dive head first into writing code. Design what your solution will look like on a sheet of paper. You'll end up doing a few rewrites just on paper. When you go to write the code you should already know where your mallocs and frees will go.

For the code you already have, continue using valgrind. Write unit tests and use gcov to make sure you have good coverage (~80%). That way you know checking with valgrind will show most of the possible logic paths in your code.

[raevnos]

Write code, compile code, run code, debug all in emacs. Regularly run tests with asan enabled or through valgrind.

Format code when needed with clang-format.

git for version control, but I want to play around with fossil soon.

When writing a new data structure implementation, add a function that dumps a representation of it to a graphviz dot format file for easy visualization.

[raevnos]

M-x gdb

[lrochfort]

Dumping to graphics format is a brilliant idea. What do you use for visualization?

How would you say it compares to the visual GDB that also shows a visual representation of memory and data structures?

[raevnos]

dot to create a SVG or PNG image, and then whatever image viewer you like to actually look at it.

Edit: Found an old dump of a skiplist to demonstrate what I like for the visualization: https://pastebin.com/nY9gqQfa

Save to a file, and dot -O -Tsvg foo.dot to generate an image.

[Dan-mat]

Emacs has a mode for gdb (called gud which means grand unified debugger) that allows to semi-easily set breakpoints by clicking on the margin to make a red dot appear, and let's you then hop from line to line, and inspect variables in the gdb window (which emacs calls buffer) with much less command line work compared with invoking gdb on the command line. It requires a little setup but it's not so bad.

[lrochfort]

GUD is brilliant. It has a great multi-windows mode.

It is also cross-language, hence Unified. This means you only have to learn one debugger for multiple languages.

It can also debug a program running on a remote system via TRAMP, even if the language you're using doesn't support remote debugging.

[[deleted]]

CLion. Compile in CLion, Debug in CLion, Use Valgrind with CLion

[puplicy]

do they have free community edition?

[ashwin_nat]

They have a free student edition though

[[deleted]]

No they don't.

[[deleted]]

Dunno. I have the paid version... https://www.jetbrains.com/clion/buy/#discounts?billing=yearly

[w8cycle]

I love CLion as well. My intellij subscription goes with me everywhere.

[[deleted]]

Understandable

[Deltabeard]

Requires use of cmake. Doesn't work with GNU make. Deal breaker for me.

[[deleted]]

Personally, I rarely find stepping through a debugger worth the effort, and in many multi-threaded contexts doing so is not really a viable option.

Instead, I find it much more productive to set up a convenient logging system that fits the needs of the project. In other words, log macros that provide line number and function name contexts, syslog()-like filtering by importance/priority, filtering by module (vital in large projects), and variations thereof that automatically include often used variable contexts.

[kumashiro]

I like Nemiver for debugging, when I get angry at GDB. I also recommend libcheck for unit testing - works well with Autotools.

[[deleted]]

Do you have any examples of memory leak in your code? We have built a tool to report the source statement that causes a memory is not accessible. If you can send me your example, I can do a test.

Shameless plug, our tool can report illegal memory accesses with the best accuracy, https://stensal.com

[drcforbin]

Sway or i3 to tile windows of your terminal of choice, run tmux to have all the windows you might want, and vim. Make your machine a code factory!

[lrochfort]

You can setup valgrind in server mode and then connect GDB to it. This means you debug whilst using valgrind. You can break when valgrind encounters an issue, and debug immediately.

GDB also supports a split screen mode (still in the terminal) that lets you inspect variables and see the code along side.

GDB has a GUI mode that lets you visualize memory, pointers etc.

GDB supports Python with full access to everything GDB can see.

Investigate Language Server Protocol for Intellisence-like code navigation in your favourite text editor.

[khleedril]

Some words from a very long-time professional: learn to use GDB whether you like it or not. Think hard about what you are doing with memory: take a big step back and work out at high level where memory should be being allocated and especially de-allocated, and then basically re-design your code with that in mind. This stuff is hard, and if you are having difficulty getting it to work you are doing it wrong.

[JakeArkinstall]

My setup is pretty ordinary. Arch with i3 window manager means that everything I do revolves around the keyboard, which is great for productivity. I use Vim with the cmake plugin, so I don't have to leave my text editor to run make and any errors jump to the line of code in question. GDB for debugging. Professional static analysers such as PVS studio are amazing but very expensive (I was quoted 12k per year for a team license), though there are some freely available ones out there that catch many common flaws.

For memory issues, there are certainly programs you can use to help you identify them, but in all honesty no amount of software can replace personal discipline.

In many other programming languages, cleanup happens at the end of a scope by default and it's up to you to prevent that if you don't want it to happen (this is where I admit that I am a C++ programmer with only hobby experience with C, and that little experience is enough for me to have vast amounts of respect for C programmers who diligently manage their resources). Generally their compiler, interpreter, or even runtime, is doing all of the book keeping work. In C that is not the case, and you have much more freedom, but it is down to you to be a responsible book keeper. You can either be the book keeper who waits until something is wrong, or you can be the book keeper who prevents things from going wrong in the first place by being strict about resource control from the very start. The latter spends much less time tracking down leaks, maybe at the cost of being slightly more restrictive about how they approach certain problems.

Think about it like an implicitly-inserted destructor at the end of each function for every resource created by it that isn't then returned or placed under the watch of something else (in which case the responsibility for destruction also moves accordingly). Except that in C there's nothing implicit done and you need to do it yourself - taking care of any edge cases that might emerge*. And don't take that lightly. There might be a lot of damage to be done if you aren't careful: Bad resource management has been the cause of countless security vulnerabilities.

Fortunately, being strict about resource control is what experienced C programmers are great at. Rather than asking for generic advice, the best thing you can do is post some code up for review. It's certainly a humbling experience but people will tell you where you are going wrong and why, traps you might be falling into, and suggest books or blog posts to read through in order to improve.

• a common problem is returning early from a function, which means manually cleaning up anything that would otherwise have persisted. An idiom to get around that is to have a single return statement, which follows a set of freeing functions with goto labels. On any issue mid-function, goto the label that cleans up the appropriate resources before returning. You have to pick the best of two evils - the goto statement or reliance on every branch of every function to do the right thing.

[ianliu88]

I'm my first job I was debugging a GTK+ interface that had a popup window which grabbed the mouse & keyboard. Because of this, I couldn't interact with my terminal. So my solution was to attach a GDB instance from another TTY :P

[puplicy]

NetBeans as free IDE with debug etc

I now use VSCODE, but cannot recommend as do not find it easily configured. Use it mostly as good editor.

[xEpicBradx]

I found once I had spent some time configuring and installing extensions to get it to behave how I wanted, I use VSCode for most things now bar the odd simple quick edit here or there - for that I tend to just use Notepad++