1415917 - Possibly excessive application of google_breakpad to process objects caused by the BHR

Status: NEW

(Core :: XPCOM, enhancement, P2)

Description

[Julian Seward [:jseward]]

Valgrind warns the user about any changes to memory state for runs of 256MB
or over, when running a program.  In the past, this triggered only very
rarely when running Firefox (typically zero or one time per run).  But in
the past few (2, maybe) weeks, such messages are emitted hundreds of times
in a run of a few minutes.

They have this form, always in pairs:

Warning: set address range perms: large range [0x59e81000, 0xb8341000) (noaccess)
Warning: set address range perms: large range [0x59e81000, 0xb8341000) (noaccess)

They result from google_breakpad mmap-ing libxul.so to read (presumably)
some debug info from it, and then munmap-ing it afterwards.

This isn't a bug per se, but it might have a performance cost, or it might
signify some change in use-patterns of debug info.  The attachment shows
stacks for both messages, which indicate that this is somehow related to the
background hang reporter.

In addition the messages are a bit annoying in that they tend to obscure
other Valgrind output.

Comment 1

[Julian Seward [:jseward]]

Attachment: Messages with stacks

Comment 2

[Nathan Froyd [:froydnj]]

Doug, do you know who could take a look at this?

Comment 3

[Nika Layzell [:nika] (ni? for response)]

This is caused by BHR wanting to collect module information for the native backtraces it collects. This is done off main thread right now in ProcessHangStackRunnable::Run() (http://searchfox.org/mozilla-central/rev/c99d035f00dd894feff38e4ad28a73fb679c63a6/toolkit/components/backgroundhangmonitor/HangDetails.cpp#284-286).

Theoretically we could probably cache some of the module information which we collect between calls into this code, expiring it only every few minutes, as modules don't come & go that quickly. We'd probably want to cache the result of SharedLibraryInfo::GetInfoForSelf() (http://searchfox.org/mozilla-central/rev/c99d035f00dd894feff38e4ad28a73fb679c63a6/toolkit/components/backgroundhangmonitor/HangStack.cpp#116)

Comment 4

[Nika Layzell [:nika] (ni? for response)]

(In reply to Nathan Froyd [:froydnj] from comment #2)
> Doug, do you know who could take a look at this?

(I wrote the code which triggers this - so I'm probably the person to deal with this. jseward was talking with me over IRC about this)

Comment 5

[Alex Thayer [:alexical] (she/her)]

(In reply to Nika Layzell [:mystor] from comment #4)
> (In reply to Nathan Froyd [:froydnj] from comment #2)
> > Doug, do you know who could take a look at this?
> 
> (I wrote the code which triggers this - so I'm probably the person to deal
> with this. jseward was talking with me over IRC about this)

Clearing the NI, since I agree.