1689626 - Crash in [mozilla::plugins::PluginUtilsOSX::SetProcessName]

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[Sean Feng [:sefeng]]

Crash report: https://crash-stats.mozilla.org/report/index/5ba39fac-b4a1-4e70-8f50-358050210127

Reason: EXC_BREAKPOINT / EXC_I386_BPT

Top 10 frames of crashing thread:

0 libsystem_kernel.dylib mach_msg_trap 
1 SkyLight CGSScoreboard 
2 SkyLight initDisplayState 
3 SkyLight initDisplayMappings 
4 SkyLight __SLSInitialize_block_invoke 
5 libdispatch.dylib _dispatch_client_callout 
6 libdispatch.dylib _dispatch_once_callout 
7 SkyLight CGS_CHECK_INIT 
8 SkyLight SLSMainConnectionID 
9 CoreFoundation _CFAppSleepSetupCoreGraphics 

Looks like there are two new crash signatures for SetProcessName crashes. In the past, we had crashes in this function, although they were fixed already.

Comment 1

[Andrew McCreight [:mccr8]]

This code does live in the plugins component, but I think that's more of a historical artifact. It looks like this is just a content process trying to set the process name.

Comment 2

[Andrew McCreight [:mccr8]]

Looking for crashes where the proto signature contains SetProcessName, I found a few other signatures that look similar, with even lower volume. My guess would be that this is one of the earliest OS calls in a newly created process, and it is spinning some kind of internal event loop forever for some reason. I'm not sure what could be going wrong here.

bp-bc76e469-3a54-4b57-bcc8-247910210130
bp-6ad62beb-2dc9-4598-9383-aed170210128

Comment 3

[Andrew McCreight [:mccr8]]

Haik, do you have time to look into this? The crash volume is low, but it sounds like it might be another OSX sandboxing issue like the bug Sean put in the See Also field. Thanks.

Comment 4

[Haik Aftandilian [:haik]]

From a quick check of CGSScoreboard on 10.15, the code may be getting the port for the window server and trying to map in some memory via IPC. I don't have any ideas about why this would be failing, and in such small numbers, starting with 86. We do have an undocumented pref to block the windowserver in the content sandbox, but testing with that did not trigger this crash. The reports are all on 10.15.7 and 10.14.6 which are the most recent updates. Leaving the needinfo to come back to this.

Comment 5

[Chris Peterson [:cpeterson]]

P3 unless crash volume increases or we get STR.

Comment 6

[Haik Aftandilian [:haik]]

Will revisit if volume increases.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.