764773 - Gecko in B2G leaks around circa 500kB to 1MB/day with UI idling

Status: RESOLVED FIXED

(Core :: Hardware Abstraction Layer (HAL), defect)

Description

[Julian Seward [:jseward]]

Following some Valgrinding of B2G on GalaxyS2, I am seeing the following
leak that occurs when the UI is idling (at the home screen), and whose size
appears to depend on how long it has been idling for.  My guesstimate of
the leak rate is 500kB/day to 1000kB/day.

The strdup in question isn't in our code, so I am wondering if there is
some way to release the memory allocated by NetlinkEvent::decode(char*, int, int),
that we need to do.

The numbers in this leak pertain to around 90 minutes of idling.  Assuming
that the leak size really is proportional to the length of idling, that is
a rate of pretty much 1MB/day.

62,586 bytes in 2,140 blocks are definitely lost in loss record 10,722 of 10,790
   at 0x48067E0: malloc (vg_replace_malloc.c:267)
   by 0x483335B: strdup (strdup.c:45)
   by 0x675B9ED: NetlinkEvent::parseAsciiNetlinkMessage(char*, int) (NetlinkEvent.cpp:202)
   by 0x675BBCB: NetlinkEvent::decode(char*, int, int) (NetlinkEvent.cpp:214)
   by 0x59C8C4F: mozilla::hal_impl::NetlinkPoller::OnFileCanReadWithoutBlocking(int) (UeventPoller.cpp:158)
   by 0x5A51305: base::MessagePumpLibevent::OnLibeventNotification(int, short, void*) (message_pump_libevent.cc:213)
   by 0x5A2984B: event_base_loop (event.c:385)
   by 0x5A513D9: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) (message_pump_libevent.cc:331)
   by 0x5A368BB: MessageLoop::RunInternal() (message_loop.cc:208)
   by 0x5A368C5: MessageLoop::RunHandler() (message_loop.cc:201)
   by 0x5A36999: MessageLoop::Run() (message_loop.cc:175)
   by 0x5A42BCF: base::Thread::ThreadMain() (thread.cc:156)

Comment 1

[Julian Seward [:jseward]]

I should add, this is by far the largest "definitely lost" style leak
I see when running B2G on V.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The way NetlinkEvent works is that it sets some members (vis strdup) when decode() is called.  Those members are freed in its destructor.

The problem is that UeventPoller.cpp has a single NetlinkEvent object that it calls decode() on over and over and over.  So we get a leak, because only the strings from the last decode() call are freed when the poller goes away.

Cervantes, why do we need mNetlinkEvent at all?  Can we not just allocate a brand-new NetinkEvent on the stack every time before calling decode() and then Broadcast()?

Comment 3

[Cervantes Yu [:cyu] [:cervantes]]

Boris, I just wanted to reuse the instance, but this turns out to be a bad idea since it strdup() instead of using the passed buffer. Allocating on the stack fixes the problem. Thanks for pointing this out.

Comment 4

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Fix memory leak in UeventPoller.cpp

Fix by not calling NetlinkEvent::decode() of the same instance repreatedly, which strdup() and only free() in dtor.

Comment 5

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Test code to verify the memleak is fixed.

Comment 6

[Cervantes Yu [:cyu] [:cervantes]]

Test on try: https://tbpl.mozilla.org/?tree=Try&rev=dc46ebb36392

Comment 7

[Jacek Caban]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a9542323655e

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/a9542323655e