You're reading from Mastering Embedded Linux Programming Create fast and reliable embedded solutions with Linux 5.4 and the Yocto Project 3.1 (Dunfell)

Product type Paperback

Published in May 2021

Publisher Packt

ISBN-13 9781789530384

Length 758 pages

Edition 3rd Edition

Languages

C++

Tools

Linux

Concepts

Embedded Systems

Authors (2):

Frank Vasquez

Mr. Chris Simmonds

View More author details

Table of Contents (27) Chapters

Preface

1. Section 1: Elements of Embedded Linux

2. Chapter 1: Starting Out FREE CHAPTER

3. Chapter 2: Learning about Toolchains

4. Chapter 3: All about Bootloaders

5. Chapter 4: Configuring and Building the Kernel

6. Chapter 5: Building a Root Filesystem

7. Chapter 6: Selecting a Build System

8. Chapter 7: Developing with Yocto

9. Chapter 8: Yocto Under the Hood

10. Section 2: System Architecture and Design Decisions

11. Chapter 9: Creating a Storage Strategy

12. Chapter 10: Updating Software in the Field

13. Chapter 11: Interfacing with Device Drivers

14. Chapter 12: Prototyping with Breakout Boards

15. Chapter 13: Starting Up – The init Program

16. Chapter 14: Starting with BusyBox runit

17. Chapter 15: Managing Power

18. Section 3: Writing Embedded Applications

19. Chapter 16: Packaging Python

20. Chapter 17: Learning about Processes and Threads

21. Chapter 18: Managing Memory

22. Section 4: Debugging and Optimizing Performance

23. Chapter 19: Debugging with GDB

24. Chapter 20: Profiling and Tracing

25. Chapter 21: Real-Time Programming

26. Other Books You May Enjoy

Identifying memory leaks

A memory leak occurs when memory is allocated but not freed when it is no longer needed. Memory leakage is by no means unique to embedded systems, but it becomes an issue partly because targets don't have much memory in the first place and partly because they often run for long periods of time without rebooting, allowing the leaks to become
a large puddle.

You will realize that there is a leak when you run free or top and see that free memory is continually going down even if you drop caches, as shown in the preceding section. You will be able to identify the culprit (or culprits) by looking at the USS and RSS per process.

There are several tools to identify memory leaks in a program. I will look at two: mtrace and valgrind.

mtrace

mtrace is a component of glibc that traces calls to malloc, free, and related functions, and identifies areas of memory not freed when the program exits. You need to call the mtrace() function from within the program...