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.

  • 6
    Honestly, I have no idea why you think splitting up your code in the described way would reduce and of the current bugs. In fact, I would expect such a redesign require a lot of additional interprocess communication, which has potential for introducing new bugs.
    – Doc Brown
    Nov 12, 2020 at 23:11
  • 4
    to become familiar with memory management will take a long time, which I just don't have right now - that is most probably a fallacy, since if you don't take the time for learning proper memory management, you will have to invest even more time into testing and debugging.
    – Doc Brown
    Nov 12, 2020 at 23:16
  • 4
    Understanding memory management is non-optional for being able to wield the C language effectively since it's prerequisite knowledge for using a lot of essential C language features properly. If you'd prefer to avoid that, then consider using a different language altogether which takes care of memory for you (e.g. Python, C#, Java); indeed, unless you have a very specific reason for using C then it's generally not recommended as a beginner language (for this exact reason, as well as the general low-level nature of the C language making it far less beginner-friendly than Java/Python/etc). Nov 13, 2020 at 0:23
  • 1
    "Understanding memory mangement" There's not much to know: (1) don't use after free'ing (that includes double free'ing), and, (2) if you never free, you'll have a memory leak. So, free just at a good time, not too soon, and not never.
    – Erik Eidt
    Nov 13, 2020 at 4:01
  • 1
    There are no cases. You have to learn about memory management, and fix the problems.
    – user253751
    Nov 13, 2020 at 15:25

2 Answers 2


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.


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.

  • thank you very much, you made a great outline! I know that memory management is must have in C, and I want to learn it actually, but I want to set a checkpoint in my project and take a break due to critical affairs.. At least one of my bugs happens not in specific block of code, but because I handle function arguments badly - syntactically it's OK, but segfaults and stack-overflows continue to happen. I've tried for hours to fix it by black-box technic, but the memory 'magic' did not revealed for me.
    – Mk Kvease
    Nov 13, 2020 at 15:33
  • ..so I thought, that I can avoid this by splitting my entire program to independent processes, each of which will just put in and read data from temporarily files, instead of variables inside one joint memory of one active process, bypassing transfer of arguments.
    – Mk Kvease
    Nov 13, 2020 at 15:45
  • @MkKvease You can't not learn it. The most that you can do is to never free anything (a deliberate memory leak) but you still have to get everything else right.
    – user253751
    Nov 13, 2020 at 15:50
  • @MkKvease: did you write the whole program, or did someone else write the parts which cause the issues?
    – Doc Brown
    Nov 13, 2020 at 18:11
  • 2
    @MkKvease: I think the previous comment is spot-on. If you dug yourself into a hole and want to get out, first thing you need to do is stop digging. If you are uncertain about pointers, try to write code without them. If you don't know how, post questions about your code at Stackoverflow (but make sure you follow their rules on how to write good questions).
    – Doc Brown
    Nov 13, 2020 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.