The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla16

Status

()

Core
Hardware Abstraction Layer (HAL)
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jseward, Assigned: cyu)

Tracking

({mlk})

Trunk
mozilla16
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [MemShrink])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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)
(Reporter)

Comment 1

5 years ago
I should add, this is by far the largest "definitely lost" style leak
I see when running B2G on V.
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()?
Component: Networking → Hardware Abstraction Layer (HAL)
QA Contact: networking → hal
Blocks: 742226
Keywords: mlk
(Assignee)

Comment 3

5 years ago
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.
(Assignee)

Updated

5 years ago
Assignee: nobody → cyu
Whiteboard: [MemShrink]
(Assignee)

Comment 4

5 years ago
Created attachment 633452 [details] [diff] [review]
Fix memory leak in UeventPoller.cpp

Fix by not calling NetlinkEvent::decode() of the same instance repreatedly, which strdup() and only free() in dtor.
Attachment #633452 - Flags: review?(jones.chris.g)
(Assignee)

Comment 5

5 years ago
Created attachment 633453 [details] [diff] [review]
Test code to verify the memleak is fixed.
(Assignee)

Comment 6

5 years ago
Test on try: https://tbpl.mozilla.org/?tree=Try&rev=dc46ebb36392
Attachment #633452 - Flags: review?(jones.chris.g) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9542323655e
Target Milestone: --- → mozilla16

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/a9542323655e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
blocking-basecamp: --- → ?
blocking-basecamp: ? → -
blocking-basecamp: - → +
You need to log in before you can comment on or make changes to this bug.