Community
cancel
Showing results for 
Search instead for 
Did you mean: 
KMill10
Valued Contributor II
1,743 Views

Memory Leak but only on edison!

Jump to solution

Hi everyone. Me again!

I'm getting on well with my new WiFi interface board based on Edison. But I have a small issue with a memory leak (or memory consumption).

I have some code which does an SSDP discovery for nearby MediaRenderer devices, and posts the occasional message to a remote MQTT server.

The code re-searches for devices every 30 seconds, and re-subscribes to any MediaRenderer's AVEvent URLs every 900 seconds.

It also passes any NOTIFY posts from the devices onto another process using a FIFO.

The issue I am seeing is that the %VSZ of the process grows steadily until eventually things start to go wrong. Over about 2 hours it will grow to 300% VSZ

So it looks like I have a memory leak (or memory consumption) somewhere.

I'm using paho-mqtt for the MQTT stuff and home made SSDP discovery code.

Its is all in C++.

I have checked and double checked every malloc/calloc that they are properly free'd and checked every "new" for matching deletes.

I have checked internal data stores to see what is growing, but cannot put my finger on it.

However, the exact same code running on Mac OS X, does not leak memory at all! It's exactly the same code. Using "instruments" on Mac OS X does not reveal any thing unusual in the memory allocations. (i.e. nothing that is not being released, no structures that are continually growing etc etc).

What are my options for examining memory usage on the Edison?

I am using "top" to watch the process grow over time. Is there any tool or gdb options that will allow me to look inside the running process and see what is using up the memory?

My linux build is based on the 2015 Edison BSP and uname -a says this:

Linux edison 3.10.17-yocto-standard # 2 SMP PREEMPT Fri Feb 24 10:16:33 GMT 2017 i686 GNU/Linux

0 Kudos
1 Solution
idata
Community Manager
66 Views

Hi SpiderKenny,

 

 

Thanks for your interest in the Intel Edison Platform.

 

 

We appreciate all the information provided. We were investigating and we'd like to suggest you to try using Valgrind- Massif: a heap profiler, it will help you to identify space leaks that aren't detected by traditional leak-checkers. You can find detailed information here: http://valgrind.org/docs/manual/ms-manual.html http://valgrind.org/docs/manual/ms-manual.html. Additionally, in this thread you can find how to install Valgrind: /message/420600# 420600 running valgrind.

 

 

Hope you find this information helpful.

 

 

Regards,

 

-Yermi A.

 

View solution in original post

3 Replies
idata
Community Manager
67 Views

Hi SpiderKenny,

 

 

Thanks for your interest in the Intel Edison Platform.

 

 

We appreciate all the information provided. We were investigating and we'd like to suggest you to try using Valgrind- Massif: a heap profiler, it will help you to identify space leaks that aren't detected by traditional leak-checkers. You can find detailed information here: http://valgrind.org/docs/manual/ms-manual.html http://valgrind.org/docs/manual/ms-manual.html. Additionally, in this thread you can find how to install Valgrind: /message/420600# 420600 running valgrind.

 

 

Hope you find this information helpful.

 

 

Regards,

 

-Yermi A.

 

View solution in original post

KMill10
Valued Contributor II
66 Views

Thank you!

I will try valgrind and let you know how I get on.

KMill10
Valued Contributor II
66 Views

Hi Yermi

Within minutes of installing and using valgrind I found the cause of the memory leak!

In my code to subscribe to MediaRenderer events I was creating a thread to send an HTTP SUBSCRIBE message, and receive the reply.

When sending new messages I was creating new threads - which is OK, the threads were being constructed and terminating properly, however I was re-using the same pthread_t member variable in my class each time I called pthread-Create(...).

Sometimes a new thread was being created before the old one exited, and therefore it was corrupting the previous pthread_t passed into pthread_create(...). This meant there were numerous orphaned threads that the kernel could not clean up because their pthread_t had been overwritten.

It was simple solution and my processes %VSZ has now dropped from 300% to just a steady 6% and is not growing!

Thanks again!

Reply