Can a golang program bring down the whole system?

Hi all,

For a Java program, it’s basically compiled bytecode that gets executed on a JVM runtime. The JVM runtime is configured with a certain amount of memory. If the program takes up more than that amount of memory it throws a OutOfMEmoryException. So i believe there is no way a Java program can take up all the system’s memory and bring it down in the process.

For GoLang, i believe there is still a GoLang Runtime that gets compiled into binary with the user written program. The runtime does things like Garbage collection. Is it also given a certain fixed amount of memory to work with? If not, can a GoLang program use up of a system’s memory and bring it to its knees?

Are you currently experiencing a problem where your Go program is consuming too much memory?

The Go runtime doesn’t get configured with an initial, minimum, maximum, etc. amount of memory like the JVM; when I set up a Minecraft Bedrock server and needed to specify -Xms, and -Xmx arguments, I (as a meh C and Go programmer) was (and still am) confused about why these are specified in a program’s arguments.

Instead of relying on a runtime to crash your program with OutOfMemoryExceptions like the JVM, I highly recommend just not consuming memory you don’t need.

If you do need the memory, let the OS decide whatever happens when your program requests too much memory. Maybe your OS is OK with overcommitting memory; maybe it crashes your program, maybe it swaps other memory, etc.

If you have an actual memory consumption problem, I think we can give you some pointers (pun somewhat intended).

1 Like

This is more of a curiosity question rather than a practical problem. Let’s say some bug kicks in and an infinite loop sets in. Just thinking will it just consume memory and bring down the system. But you are right the os probably will do something about this rather than let a program run rogue

That really depends on the degree of threat introduced by the program, not limited to Go programming language. In other words, you’re asking an open-ended, human error, nip-picking, system-admin question targeted at operating system.

Say for any application messing with I/O control unit (e.g. /proc in GNU/Linux interface) and there are no defense programming practices at all, you have an hardware level security threat that may fry hardware depending on circuitry design.

Say for you intentionally wrote a kernel module that does memory leak, then the operating system is intended to crash and burn.

Say for an application is running on an non-hardened GNU/Linux operating system where resources are not bounded (see: user65369 replies in, then the entire system is vulnerable to resources fatigue threats.

This goes on as “he said, she said” Q&A as we assess each security threats.

Depending on operating system, say GNU/Linux (sorry if I’m biased mainly because I’m specialized in it), the OS and kernel itself has its mechanism to decide what program to kill and disallow any user space application (regardless what languages you’re using) to avoid crashing the entire OS, including memory leak.

However, there is an exception: if it is something critical like kernel module, other processes kicks in such as open review your kernel module’s source codes, defensive programming, strict coding habits, and etc to help defending the stability of the OS.

The reason JVM was designed was to ensure Java program is portable under a unified “ABI” as an alternative to compiled codes like C/C++. That was for historical reason where containerization and sand-boxing concepts weren’t even proven working and cross-compile was a nightmare.

Today, we got many containerization and sand-boxing technologies at our disposal that a single complied Go program would work great and resources are readily available for easy integration. If you’re serious about security especially memory bounding, you would want to set it at operating system level rather than a language-specific VM alone, or be religious about a language.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.