Home Blog Page 349

Stack vs Heap. What’s the Difference and Why Should I Care?

I’m four months into the curriculum at Holberton School and we’ve solved multiple problems using the malloc, realloc, calloc and free functions in the C programming language. What better way to build a solid foundation of how memory gets allocated then to write a technical post on the stack versus the heap?

This article explains in depth:

What are the five segments of memory?

What is the stack?

What is the heap?

How does understanding the two make you a better software engineer?

What are the five segments of memory?

When we write applications, files, or any logic that is typed in an editor and executed on the computer, the computer has to allocate memory for the program to run. The memory that is assigned to a program or application in a computer can be divided into five parts. The amount of memory that get’s assigned to an application depends on the computer’s architecture and will vary across most devices, but the variable that remains constant is the five parts of an application’s memory which are the heap, stack, initialized data segment, uninitialized data segment, and the text segment.

 
1*8b9-Z3FV6X9SP9We8gSC3Q.jpeg

The initialized data segmentconsists of all the global and static variables that are initialized when a file gets compiled. The uninitialized data segment consists of all global and static variables that are initialized to zero or do not have explicit initialization in source code.

At Holberton, most of the time we are not concerned about the uninitialized data segment because when we compile our programs with gcc, we use the flags, -Wall -Wextra -pedantic -Werror and we use an internal stylistic checker called betty which treats warning as errors when uninitialized variables are present. Having unused variables in our programs gets flagged and is not a best practice. The text segment, also known as the code segment, contains the machine instructions which make up your program. The text segment is often read-only and prevents a program from accidentally modifying its instructions.

What is the stack?

The stack is a segment of memory where data like your local variables and function calls get added and/or removed in a last-in-first-out (LIFO) manner. When you compile a program, the compiler enters through the main function and a stack frame is created on the stack. A frame, also known as an activation record is the collection of all data on the stack associated with one subprogram call. The main function and all the local variables are stored in an initial frame.

 
1*kaVuG-f-BalIfFuUNIKAPQ.jpeg

Program vs Stack usage

In the picture above, we have one stack frame on the stack that holds the main function, along with the local a, b and sum variables. After using the printf() function the frame we created along with the local variables are only accessible in memory for the duration of the frame are no longer accessible after returning the 0 value from the function.

What happens with the stack when we call multiple functions? To illustrate the stack in it’s LIFO manner, let’s solve a problem using recursion. When we call multiple functions in our application, we use multiple stack frames in a last-in-first-out approach meaning that the last stack frame we’ve created on the stack is the first stack that will be released after the function is done executing its logic. Let’s go over an example of printing out the name “Holberton” recursively and show how our code affects the stack memory segment.

 
1*fZ1fDQAm5vDjc5TOCHH2mg.jpeg

Yes, I have a whiteboard on the back of my door at my house.

When we compile our code using gcc _putchar.c 0-puts_recursion.c 0-main.c , the compiler enters our program through int main(void) and creates a frame with the function int main(void) and _puts_recursion("Holberton") living on that frame as illustrated on the image above. When the compiler runs into the _puts_recursion() function, it calls that function and creates another stack frame on top of the previous stack frame where int main(void) lives. We are now in our second stack frame in our program and have entered in the _puts_recursion(char *s)function where *s is equal to 'H' and is only accessible in that stack frame. Because 'H' does not equal '' , we will continue with our function calls and execute the _putchar('H') function and enter into the same function _puts_recursion(++s). The argument ++s moves the memory address of the *s one byte because the size of a char is 1 byte on our machine, and now _puts_recursion is calling the function as _puts_recrusion('o') . Each time the _puts_recursion function is called, a new stack frame is put on the stack until we hit the terminating condition which is if (*s == '').

Every time a new stack frame is created, the stack pointer moves with it until it reaches the terminating condition. A stack pointer is a small register that stores the address of the last program request in a frame. When we hit the terminating condition, we execute our logic, then start to unwind the stack or pop off stack frames in the last-in-first-out manner until we reach out return(0) logic in the int main(void) function in our first stack frame.

If you don’t have a terminating case for the recursive example above, the stack will continue to grow in size adding additional stack frames on-top of each other, moving the stack pointer upward on each call, against the heap, which will be explained in the next section. In a recursive function , if there is no valid terminating condition, the stack will grow until you’ve completed consumed all the memory that’s been allocated for your program by the operating system. When the stack pointer exceeds the stack bound, you have a condition called stack overflow. Bad things happen when you have a stack overflow.

Let’s first refer back to the other four segments of your application’s memory which were the uninitialized and initialized data segments, text segment and stack segment. These four segments have a constant memory size during compilation. The memory size for these four segments is predetermined by your operating system before compiling your programs. When software engineers write programs that consume large amounts of memory from a machine, they have to consider where and how much memory is being consumed in their application.

The max stack size is constant and predetermined before a program is compiled. At Holberton, we use a Linux Ubuntu/Trusty64 distributions. To find information about the stack size and other neat limits, type the command below into your terminal.

ulimit -a

Where ulimit is a function that gets and sets user limits and the -a flag lists all the current limits.

 
1*Pj0uHasm_IcsBiXIaw5qRQ.jpeg

Stack size is 8.192MB of memory.

If the stack is limited in size and a program needs more memory for it to execute, where can a software engineer pull memory from for his/her application? This is where the heap comes into play.

What is the heap?

The heap is the segment of memory that is not set to a constant size before compilation and can be controlled dynamically by the programmer. Think of the heap as a “free pool” of memory you can use when running your application. The size of the heap for an application is determined by the physical constraints of your RAM (Random access memory) and is generally much larger in size than the stack.

We use memory from the heap when we don’t know how much space a data structure will take up in our program, when we need to allocate more memory than what’s available on the stack, or when we need to create variables that last the duration of our application. We can do that in the C programming language by using mallocrealloccalloc and/or free. Check out the example below.

 
1*1aNsjN93vpK6Nk4qn2mZtw.jpeg

Allocating 4000 bytes of memory to our program, then releasing it.

We allocate memory from the heap using the malloc() function. The argument we want to include in malloc is the amount of memory we want to allocate to our application, in bytes. Malloc returns a void pointer that is type casted into an integer pointer that now points to the first address in memory for our 4000 byte long memory. We can now store information in those memory addresses and do as we please to that information for the duration of our program or for the duration of our function because we have a pointer that references the first memory address from the newly allocated heap memory.

If you aren’t intentionally creating variables that last the duration of your application from the heap, you always want to release the memory back to the machine using the free() function. If you don’t release the memory using the free() function, you have memory that will persist throughout your program. If we do not release the memory from our program before terminating the application, our application has memory leaks. If your application has enough memory leaks, it can consume more memory than is physically available and can cause programs to crash. This is why we use a program called valgrindValgrind is easy to use and checks for memory leaks.

 
1*zj8eF7EIaMZcThlk9TcPmA.jpeg

Valgrind being used. 4,000 bytes allocated. 0 bytes leaks

Another thing to consider while using the heap, the pointer variables created on the heap are accessible by any function, anywhere in your program, as long as the memory is still persistent and hasn’t been free.

How does understanding the stack and heap make you a better software engineer?

If you understand the advantages and disadvantages of using the stack vs the heap for your application, then it gives you a strategic advantage for creating scalable programs. You, the programmer, have to decide when to use memory from the stack vs heap based on each problem you are trying to solve.

If you have a variable like an array or struct that needs to be stored in a large block memory, needs to persist throughout the lifetime of your application and could change in size throughout the duration of your program, then you should allocate it from the heap.

If you need to create helper functions with variables that only persist within the lifetime of the function, then you should allocate memory from the stack. Memory from the stack is easier to keep track of because the memory is only locally available in the function call which does not persist after the function is completed and is managed by the CPU.

 
1*mVBw2A1Ybu1pedo_7IFs_w.jpeg

Photo credit: Gribble Lab

Questions, comments or concerns, feel free to comment below, follow me or find me on Twitter @ NTTL_LTTN.

References:

My Code School. (February 23rd, 2013). Pointers and dynamic memory — stack vs heap. . Retrieved from https://www.youtube.com/watch?v=_8-ht2AKyH4

Paul Gribble (2012). C Programming Boot Camp — 7. Memory: Stack vs Heap. [Blog post]. Retrieved from https://www.gribblelab.org/CBootCamp/7_Memory_Stack_vs_Heap.html#orgheadline1

GeeksforGeeks. Memory Layout of C Programs. [Blog post]. Retrieved from https://www.geeksforgeeks.org/memory-layout-of-c-program/

Sandra Henry-Stocker. (November 18th, 2012). NETWORK WORLD — Setting limits with ulimit. [Blog post]. Retrieved from https://www.networkworld.com/article/2693414/operating-systems/setting-limits-with-ulimit.html

Valgrind Developers (2000–2017). Valgrind. Retrieved from http://valgrind.org/

Die.net Linux Documentation. Retrieved from https://linux.die.net/

Supercomputers: All Linux, All the Time

The latest TOP500 Supercomputer list is out. What’s not surprising is that Linux runs on every last one of the world’s fastest supercomputers. What is surprising is that GPUs, not CPUs, now power most of supercomputers’ speed.

Once more, if you want to run the fastest possible computer, the June 2018 TOP500 supercomputing ranking shows that Linux is the best of all operating systems. Every last one is running Linux.

Linux has dominated supercomputing for years. But, Linux only took over supercomputing lock, stock, and barrel in November 2017. That was the first time all of the TOP500 machines were running Linux. Before that IBM AIX, a Unix variant, was hanging on for dear life low on the list.

Read more at ZDNet

Linux dpkg Command Tutorial for Beginners – 8 Examples

If you are on a Debian or Debian-based system (like Ubuntu), there are high chances you might have encountered .deb packages. These are Debian packages, and Linux command line offers built-in commands/tools to deal with this kind of packages. One such tool is dpkg, which we will discuss here in this tutorial.

But before we do that, it’s worth mentioning that all examples in this tutorial have been tested on an Ubuntu 16.04LTS machine.

Linux dpkg command

The dpkg tool is basically a package manager for Debian/Debian-based systems. Following is its syntax:

dpkg ACTIONS

Read more at HowToForge

Google Becomes a Platinum Member of The Linux Foundation

Demonstrating its commitment to open source software, we are thrilled to announce that Google is now a Platinum Member of The Linux Foundation. Google has been an active and committed contributor to the open source community for many years, releasing and contributing to more than 10,000 open source projects to date. Some of The Linux Foundation communities Google supports include Cloud Foundry, Node.js Foundation, Open API Initiative and Cloud Native Computing Foundation, which it helped found with its Kubernetes contribution.

“The Linux Foundation is a fixture in the open source community. By working closely with the organization, we can better engage with the community-at-large and continue to build a more inclusive ecosystem where everyone can benefit,” said Sarah Novotny, head of open source strategy, Google Cloud. 

Read more at The Linux Foundation

CIP: Keeping the Lights On with Linux

Modern civil infrastructure is all around us — in power plants, radar systems, traffic lights, dams, weather systems, and so on. Many of these infrastructure projects exist for decades, if not longer, so security and longevity are paramount.

And, many of these systems are powered by Linux, which offers technology providers more control over these issues. However, if every provider is building their own solution, this can lead to fragmentation and duplication of effort. Thus, the primary goal of Civil Infrastructure Platform (CIP) is to create an open source base layer for industrial use-cases in these systems, such as embedded controllers and gateway devices.

“We have a very conservative culture in this area because once we create a system, it has to be supported for more than ten years; in some cases for over 60 years. That’s why this project was created, because every player in this industry had the same issue of being able to use  Linux for a long time,” says Yoshitake Kobayashi is Technical Steering Committee Chair of CIP.

CIP’s concept is to create a very fundamental system to use open source software on controllers. This base layer comprises the Linux kernel and a small set of common open source software like libc, busybox, and so on.  Because longevity of software is a primary concern, CIP chose Linux kernel 4.4, which is the LTS release of the kernel maintained by Greg Kroah-Hartman.

Collaboration

Since CIP has an upstream first policy, the code that they want in the project must be in the upstream kernel. To create a proactive feedback loop with the kernel community, CIP hired Ben Hutchings as the official maintainer of CIP. Hutchings is known for the work he has done on Debian LTS release, which also led to an official collaboration between CIP and the Debian project.

Under the newly forged collaboration, CIP will use Debian LTS to build the platform. CIP will also help Debian Long Term Support (LTS) to extend the lifetime of all Debian stable releases. CIP will work closely with Freexian, a company that offers commercial services around Debian LTS. The two organizations will focus on interoperability, security, and support for open source software for embedded systems. CIP will also provide funding for some of the Debian LTS activities.

“We are excited about this collaboration as well as the CIP’s support of the Debian LTS project, which aims to extend the support lifetime to more than five years. Together, we are committed to long-term support for our users and laying the ‘foundation’ for the cities of the future.” said Chris Lamb, Debian Project Leader.

Security

Security is the biggest concern, said Kobayashi. Although most of the civil infrastructure is not connected to the Internet for obvious security reasons (you definitely don’t want a nuclear power plant to be connected to the Internet), there are many other risks.

Just because the system itself is not connected to the Internet, that doesn’t mean it’s immune to all threats. Other systems — like user’s laptops — may connect to the Internet and then be plugged into the local systems. If someone receives a malicious file as an attachment with email, it can “contaminate” the internal infrastructure.

Thus, it’s critical to keep all software running on such controllers up to date and fully patched. To ensure security, CIP has also backported many components of the Kernel Self Protection project. CIP also follows one of the strictest cybersecurity standards — IEC 62443 — which defines processes and tests to ensure the system is more secure.

Going forward

As CIP is maturing, it’s extending its collaboration with providers of Linux. In addition to collaboration with Debian and freexian, CIP recently added Cybertrust Japan Co, Ltd., a supplier of enterprise Linux operating system, as a new Silver member.

Cybertrust joins other industry leaders, such as Siemens, Toshiba, Codethink, Hitachi, Moxa, Plat’Home, and Renesas, in their work to create a reliable and secure Linux-based embedded software platform that is sustainable for decades to come.

The ongoing work of these companies under the umbrella of CIP will ensure the integrity of the civil infrastructure that runs our modern society.

Learn more at the Civil Infrastructure Platform website.

 

Open Source Jobs Report: 3 Hot Skill Areas Now

In the IT job market right now, it pays to have open source skills. That’s the main takeaway from the seventh annual Open Source Jobs Report, conducted by The Linux Foundationand careers site Dice. Demand for experience and skills with open source platforms isn’t some overnight sensation, but it continues to grow more robust: 83 percent of hiring managers surveyed for the report said hiring open source talent was a priority this year, up from 76 percent last year.

For job seekers with open source chops, that means you’re in a strong position. And, increasingly, you know it: 55 percent of open source pros said they wouldn’t have trouble finding another job, and 87 percent indicated that knowing open source has advanced their career in some way.

For IT leaders and hiring managers, it’s a temperature check on what you’re up against in the competition for talent. FYI, the thermometer reads “scorching hot:” 87 percent of hiring managers said they encounter difficulties recruiting open source talent. That challenge has proven consistent during the last few years. 

Read more at EnterprisersProject

8 Reasons to Use the Xfce Linux Desktop Environment

I realized in looking back over my series of articles on Linux desktops that I had neglected Xfce. This article is intended to rectify that oversight. I like Xfce a lot and am enjoying the speed and lightness of it more than I thought I would.

Eight reasons for recommending Xfce

1. Lightweight construction

Xfce has a very small memory footprint and CPU usage compared to some other desktops, such as KDE and GNOME. On my system, the programs that make up the Xfce desktop take a tiny amount of memory for such a powerful desktop. Very low CPU usage is also a hallmark of the Xfce desktop. With such a small memory footprint, I am not especially surprised that Xfce is also very sparing of CPU cycles.

2. Simplicity

The Xfce desktop is simple and uncluttered with fluff. The basic desktop has two panels and a vertical line of icons on the left side. 

Read more at OpenSource.com

Linux Professionals Hard to Find, Say Hiring Managers

It’s a very good time to be a Linux professional. Linux is back on top as the most in-demand open source skill and hiring these professionals has become a higher priority for 83% of hiring managers this year compared to 76% in 2017, according to the newly released 2018 Open Source Jobs Report.  

That’s not surprising when you consider how popular cloud and container technologies have become, as well as DevOp practices, all of which typically run on Linux. What’s also not surprising is that Linux professionals are in high demand:

  • 87% of hiring managers experience difficulties recruiting enough open source talent. This is similar to last year, when 89% said it was a challenge finding the right mix of experience and skills.

  • 44% of respondents rated it very difficult to recruit open source pros, a percentage that jumped from 34% in 2017.

At the same time, 52% of hiring managers say they are planning to hire more open source professionals in the next six months than they did in the previous six months. And, hiring of open source professionals will also increase more than hiring for other areas of the business for 60% of hiring managers, the report found. That’s down slightly from last year when 58% projected more hiring in six months and 67% predicted more open source hiring than other areas of the business.

This high demand has prompted many companies to pay premiums above base salary, especially for professionals with skills in cybersecurity, big data and process management.

And companies are finding that supporting open source projects can be a valuable recruiting and retention tool. This year, 57% of hiring managers reported that their organization contributes to open source projects, up from 50% in 2017. Nearly half (48%) of hiring managers report that their organization has decided to financially support or contribute code to an open source project specifically with the goal of recruiting developers who work on that project.

The role of the economy

The strong global economy is encouraging half of hiring managers to hire more staff this year, up from 43% in 2017. Only 6% said the economy is leading them to decrease their open source hiring.

The report found 55% of open sources pros say it would be easier to find a new open source job — a slight increase compared to 52% in 2017 and 50% in 2016. Only 19% reported not receiving a recruitment call in past six months. This is a significant decline from the 27% who said they didn’t receive a recruitment call in 2016 and 2017 job surveys.

The overall unemployment rate for tech professionals is on the decline – in April it dropped to 1.9%, compared to 3% one year ago.  

The 2018 Open Source Jobs Report is an annual partnership between The Linux Foundation and IT career site Dice. This year’s survey includes responses from more than 750 hiring managers at corporations, small and medium businesses (SMBs), government agencies and staffing firms worldwide, plus more than 6,500 open source professionals.

Download the complete Open Source Jobs Report now.

Last Chance to Speak at Open Source Summit and ELC + OpenIoT Summit Europe – Submit by July 1

Submit a proposal to speak at Open Source Summit Europe & ELC + OpenIoT Summit Europe, taking place October 22-24, 2018, in Edinburgh, UK, and share your knowledge and expertise with 2,000+ open source technologists and community leaders. Proposals are being accepted through 11:59pm PDT, Sunday, July 1.

This year’s tracks and content will cover the following areas at Open Source Summit Europe:

  • Cloud Native Apps/Serverless/Microservices
  • Infrastructure & Automation (Cloud/Cloud Native/DevOps)
  • Linux Systems
  • Artificial Intelligence & Data Analytics
  • Emerging Technologies & Wildcard (Networking, Edge, IoT, Hardware, Blockchain)
  • Community, Compliance, Governance, Culture, Open Source Program Management (Open Collaboration Conference track)
  • Diversity & Inclusion (Diversity Empowerment Summit)
  • Innovation at Apache/Apache Projects
  • TODO / Open Source Program Management

View the full list of suggested topics for Open Source Summit Europe.

Suggested Embedded Linux Conference (ELC) Topics:

Read more at The Linux Foundation

Linux Kernel Bug Hunting

The story starts with a message on our workplace chat:

Our k8s master servers are rebooting randomly every day!

This announcement had a good and a bad side. On the good side, our clusters handled this unfortunate event without problems, even when two out of five servers were rebooting at the same time. On the bad side, we didn’t receive an alert. …We had zero information about what could possible cause this. So, we thought to start the investigation by looking at system statistics. The interval of pulling those statistics was too high and as a result the statistics hid valuable information.

We didn’t know the cause of the restart but we found out the following two kernel settings.

  • kernel.hung_task_panic = 1
  • kernel.softlockup_panic = 1

Those settings instruct the kernel to panic when a task stops or when a softlockup occurs. Furthermore, we found out that kernel automatically reboots when a panic happens because we have kernel.panic = 70 in our sysctl settings. The combination of triggering a panic and auto reboot prevented us to capture a kernel crash dump.

Read more at Medium