mozilla :: #e10s

17 Mar 2017
07:33wcpanmconley: when the e10s-spinner appears, is it possible to know where is the blocking code?
13:16mconleywcpan: yes, although the technique varies from platform to platform. On OS X, for example, it's possible to use Activity Monitor to collect a "Process Sample" which sometimes tells you why the content process is locked up.
13:17mconleyOn Windows, it's a bit more complicated - on Windows, you must attach a debugger like WinDbg or Visual Studio. Alternatively, you can intentionally crash Firefox, which should (in theory) produce a crash report that contains information on where Firefox was stuck.
13:17mconleyOn Linux, usually the best option (imo) is to attach gdb to get a stack dump.
13:44The_8472would be great if there were a simple stack dump tool
13:44The_8472especially on windows. the windbg procedure takes ages
14:53mconleyThe_8472: yeah, the debug story isn't amazing for sure. :/
14:53mconleyespecially because of the symbol fetching part.
14:55mconleyThe_8472: the Gecko Profiler does the job for general short-hangs. But if the content process is completely hung, the profiler can't help you (at least, on Windows)
14:56The_8472or even worse, the parent process
14:56* mconley nods
14:56mconleyon OS X, there _is_ a way to force the Gecko Profiler to dump a profile even if the main thread is hung
14:56mconleyI've never actually tried it on Windows
14:57mconley^-- I wonder if the technique described in here would work for VS / Windbg
14:57mconleysince you'd get to skip the symbolication part
14:58The_8472i think one could skip the symbol part too now since the new thing fetches them on demand, right?
14:59mconleyyeah, that's the idea anyhow
14:59mconleymaybe you could attach WinDbg, call that function to write out a profile
14:59mconleyand then load it in Cleopatra, which will do the work of symbolicating
14:59mconleyworth a shot, anyhow
14:59* mconley tries it
15:00The_8472ah, but the profiler doesn't dump all stacks
15:01mconleynot for every thread, no
15:01mconleybut the main threads, yes.
15:03mconleyhrm, didn't seem to happen.
15:03mconleybut I could call the function
15:03mconleyI wonder if that's a thing we could fix.
15:53blasseyjimm: ping?
16:12mconley4 content processes coming down the pipe shortly. Hold on to your butts.
16:26canuckistanielan: St. Patrick's is pretty epic in Canada too
16:27mconleygreen beer happens, at least.
16:27canuckistaniand an excuse to have a guiness at 9am
16:34The_8472huh, that's quite a steep decline for XP
16:35canuckistaniThe_8472: sorry, some context. That graph is just release channel, and as of 52 WinXP is no longer on release channel.
16:35canuckistaniso they didn't disappear into a portable hole, they're just on ESR instead
16:36The_8472ah, too bad
16:59canuckistaniThe_8472: dunno I think it's kind of awesome. Now we can just focus on Win7/10 and (more) modern hardware, and yet we haven't quite thrown all those years under the bus, either ( even though everyone else has )
17:00The_8472too bad in the sense that there is no sudden mass-migration away from XP
17:04mconleythe OS that won't die
17:48smaugwho is driving all the WebExtension work?
17:49aswansmaug: webextensions in general? or something more specific?
17:49aswankev is the product manager, shell is the project manager, andym is the engineering manager
17:49smaugin general, like what APIs get exposed there
17:50smaugthinking about mozbrowser this time
17:50aswansmaug: ultimately kev, though the larger community also does a lot
17:50smaugaswan: is there some spec for WebExtensions?
17:50smauglike, do all the browsers try to support same APIs?
17:50aswansmaug: not a spec per se
17:50smaugmozbrowser is very Gecko specific
17:50aswanthere's a w3c community group
17:51aswanbut it hasn't produced a lot
17:52aswanyeah, mozbrowser would pretty clearly be a firefox specific thing (which i think most people would get from the name)
17:53smaugaswan: well, this particular patch would affect to all the iframes
17:53smaugsince the prototype object of iframes changes
17:55aswansmaug: sorry i'm not familiar with the details, how would non-mozbrowser iframes be affected?
17:55smaugaswan: who would be the right person to ask feedback?
17:56smaugaswan: the methods which mozbrowser iframes have, would be exposed to all the iframes in addon JS contexts
17:56smaugwe already seem to expose those extra methods in chrome JS, which is fine, since chrome JS clearly is Gecko only stuff
17:56aswansmaug: there's no single person, the dev-addons mail list would have all the right people though
17:56smaugaswan: who would be the right person to ask feedback?
17:57aswanin practice, kris is probably most familiar with both webextensions and all the gecko/platform details
18:10kevI know Andy was looking at the mozbrowser bits last week. smaug: one of the things were were wondering about was use-cases for mozbrowser in a firefox context on desktop. is it more targeted at mobile and/or PWA-like applications?
18:12smaugkev: I don't know. I was just reviewing bug 1318532, but the patches need feedback from people familiar with WebExtensions
18:12firebot NEW, Support <iframe mozbrowser> in WebExtensions
18:13smaugmaybe kris will comment there
18:13bkellymrbkap: gabor: ping
18:15kevsmaug: kk. definitely ping/ni him. I&#39;ll reach out to cvan as well
18:18kevohhh... cvan is on VR, things are making some more sense now
18:34bkellydo we have a good API to open a URL in a new window such that it will follow our e10s process allocation strategy?
18:34bkellyI need to do this from c++
18:34bkellyand ideally find out some information about the window after it has loaded
18:43smaugbkelly: this is for service workers?
18:43smaugperhaps catalinb can help here?
18:43bkellysmaug: clients.openWindow():
18:44bkellysmaug: I can build a bunch of infrastructure to do this... but I&#39;m kind of hoping it already exists
18:44smaugbkelly: don&#39;t we have support for openWindow already?
18:44smaugor was that some other openWindow
18:44bkellysmaug: we do, but it just opens it in the current window
18:44bkellycurrent process
18:44smaugbkelly: hmm
18:45smaugcatalinb sure was looking into supporting it when the only open window is in pb mode or so
18:45smaugto open a new window
18:45bkellywe want to compeletely disconnect service workers from any dependency on being in a content process
18:48mrbkapbkelly: it&#39;s awkward. I&#39;m on my phone right now but I can find it once I&#39;m back on a real computer.
18:49mrbkapbkelly: I think there&#39;s an interface on nsIXULWindow or something like that.
19:07wcpanmconley: do you have any idea to extract XUL symbols from Process Sample?
19:10wcpanbecause now the e10s-spinner is happening on Fx52, which I don&#39;t have any debug symbol for it
19:28wcpanuhh, gecko profiler does not work in this state
20:06mconleywcpan: hm... this is a process sample from OS X?
20:44wcpanmconley: yes
20:44mconleywcpan: would you be willing to let me see it?
20:48mconleywcpan: is this a special build of Nightly?
20:48mconleyoh, it&#39;s not Nightly
20:49mconleyit&#39;s Firefox
20:49mconleywcpan: if you&#39;re willing to try attaching lldb, you could try that command I pasted earlier today that will attempt to dump a profile to disk
20:49mconleythat&#39;ll be something our symbolication server could symbolicate
20:49mconleyand then we get JS stacks too
20:51wcpanyes I can use lldb on this machine, where can I find the command?
20:51mconleywcpan: lemme find it
20:51mconleyI hope it&#39;ll work
20:51mconleyit didn&#39;t work on Windows
20:51mconleywcpan: ^-- check out the &quot;Getting a profile form a hung process&quot; section.
20:52mconleywcpan: you might not need to do the symbolication step, btw
20:52mconleybecause I believe the new profile viewer will do that step for you
20:55wcpanit seems neither mozilla_sampler_save_profile_to_file nor profiler_save_profile_to_file exists in the symbol table
20:56wcpandoes mac/lldb has detached debug symbols which are similar to gdb or *.pdb for Windows?
20:57froydnjbut the debugger ought to be smart enough to find them for you
20:58wcpanI think we also suffering from this for icecc build
21:26wcpanok I think it is not hanging ... I mean it&#39;s executing some JS code and keep sending IPC message
21:34wcpanmconley: I think the root cause is that an add-on is flooding sync IPC messages in the content
21:35mconleywcpan: lovely. :/
21:36mconleywcpan: do you have an add-on list?
21:38wcpanI *think* it might be greasemonkey, it uses something like sendSyncMessage to get configuration from parent
21:40wcpanI hope I can get the JS stack, but guessing stacks from disassembly is the most I can do
21:42mconleywcpan: if it ends up being Greasemonkey, a thing you could do is replace it with the Tampermonkey WebExtension:
21:42mconleywcpan: and load your userscripts in there.
21:42mconleyand see if that helps.
21:44wcpanI&#39;ll give it a try, I didn&#39;t use it because we had incomplete support for WebExt
21:44wcpanand also switch to a version that has a debug symbol :(
21:45* mconley nods
21:51wcpanand maybe we can warn users an add-on is abusing(?) sendSyncMessage in about:performance?
21:52wcpansomehow about:performance said everything is fine while it didn&#39;t
18 Mar 2017
No messages
Last message: 6 days and 4 hours ago