Cases of memory management where it is reasonable to separate program into several execs

Question

I have 5000+ strings pet-project for CLI and it can do some optional calculations and can output results to CLI or/and to file. Some new modules don't work.

Now I catch with GDB some strange segfaults and stack overflows, which I can't fix, though, I found all the places where the bugs are living. So, I see where and what's going wrong, but I have no idea how to fix it, because to fix it I have to spend a lot of time on learning some new tricky things in C - memory layouts and memory management.

I'm a novice to C and self-learning it as a hobby, so, to become familiar with memory management will take a long time, which I just don't have right now.

(I feel the need to learn some memory management golden rules, which can cover the whole program memory with nested calls, but I can't find points from which it's better to start)

Sorry, I can't fully describe in professional words what is going wrong in my program, but in general as I got it - it crushes because I don't know how to handle memory of structure copies properly, and how to manage memory safely in tricky(for me) hierarchy of function calls. I don't want to reduce amount of calls' levels cause of my intention to keep my code structure simple and readable.

I think that more experienced and well-educated in C people can fix my bugs just by editing my noobie designs in structure manipulations and memory management with advanced pointing technics, but.. I'm not that guy :(

So, my question is - What are the real cases, where it is impossible to fix the stack overflows and segmentation faults without changing the program design by separating its one exec to several smaller programs(execs) - control/interface module and functional modules?

In other words - What are the (memory management) cases, when you better to split your 1-process program to N-process program, than to redesign code structure to the loss of its readability?

I appreciate any practical or abstract examples, cause I try to figure out, if I'm in this kind of situation, or I'm not.

Now I have a choice - spend my time to understand really difficult to me part of CS - memory layouts and memory management, or spend my time on redesigning my code into multi-exec project.

I'm asking, cause I'm not sure, if the first direction will lead me to my actual goal.

I just want borders of using '1-exec-design' in C to be outlined a little.

Thanks for reading this.

Answer 1

You don't fix memory management issues by breaking your program up into multiple executables - you fix memory management issues by fixing your memory management code. I know that's not a satisfactory answer, but it is the answer.

C is not an easy language to learn, and I do not recommend it as a first language for anyone. It's an important language, yes, but it's not beginner-friendly at all. Even for people who are relatively experienced, it can be confusing and frustrating. Pointer syntax and behavior is not straightforward, memory management is very labor-intensive and easy to get wrong, and C gives you few tools to make it easy. Whole books have been written on how to manage data in C.

Without seeing your code it's impossible to give you any real guidance, but here are some suggestions:

1. If you're unclear on a specific concept about pointers or memory management, write small test programs to explore one thing at a time; don't dive into a massive project without taking time to understand the fundamentals. Programming is a skill, and like any other skill requires non-trivial amounts of practice.
2. Get a good C reference manual. The C Programming Language, while a bit long in the tooth, is still a good introductory text.
3. Look at code written by others in github or other repositories. There's some risk in that because there's a lot of really bad code out there, but you may see something that helps clear up some confusion.

If you have questions about a specific problem you're encountering, such as why you're getting a core dump when you execute some piece of code, then include that piece of code in your question, along with a description of what you expect to happen vs. what actually happens.

Answer 2

Frankly spoken, if you have trouble to fix bugs caused by faulty memory management for a single executable, splitting up the program into multiple executables won't change this - at least, not directly.

Of course, what you may be able to achieve by a multi-exec is to prevent your program system to crash completely. You wrote you have a design in mind with

• a controller module (I hope with a more-or-less simple memory management, so you can make this robust)

• functional modules (I assume some of them, probably those "new modules" you mentioned, have requirements for complex memory management)

The controller module can run the functional modules as separated processes, and if one of the functional modules stops working, the remaining processes are ideally not affected.

So if your goal is to produce a system where the new modules can crash without stopping the rest of the system, then splitting up the larger program into smaller ones which can as separate processes is the canonical approach.

However, this won't make your new modules magically work correctly. You need to learn proper memory management either to fix those modules.

To be fair, designing new modules in a way they can be run in isolation will make root cause analysis and debugging easier, especially when you can reproduce certain bugs without running the whole program. But that does not mean one has necessarily to design the whole system with separated executables (which will introduce the need for interprocess communication, which bears a certain risk of introducing new classes of bugs). Instead, it may be an option to design such modules as libraries which can be either linked against a small test driver, or linked into the main program.