1094603 - crash in hang | libsystem_kernel.dylib@0x1152e

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Robert Helmer [:rhelmer]]

This bug was filed from the Socorro interface and is  report bp-283128a2-24bd-4137-9996-20a782141106. =============================================================  

I've seen this ~15 times so far, on different sites, since upgrading to Yosemite. Upgraded flash, rebooted, still seems really crashy.

Comment 1

[Benjamin Smedberg]

Please don't file bugs in the Plugins product: always in Core: Plug-Ins. smichaud, I seem to recall seeing a similar bug go by, do you know if this is a duplicate?

Comment 2

[Steven Michaud [:smichaud] (Retired)]

The "signature" (libsystem_kernel.dylib@0x1152e) is extremely generic -- mach_msg_trap.  And of course there's no crash at that address -- it just seems that, for a hang, Socorro reports the top entry for the main thread as the crash address.

I also looked through all the threads for the crash report from comment #0, and I don't see anything wrong in any of the threads.

So there's really nothing to work with here, but I don't think this particular problem has been reported before.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

https://crash-stats.mozilla.com/report/list?signature=hang+%7C+libsystem_kernel.dylib%400x1152e&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&platform=mac&hang_type=any&date=2014-11-06+17%3A00%3A00&range_value=1#reports

There are a fair number of these -- 68 on all branches.  Though it's nowhere near a topcrasher.

All the reports for this address are on Yosemite.  But that's just an accident.  On different versions of OS X, the place where mach_msg_trap waits for messages will be at a different address in libsystem_kernel.dylib.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Robert, we need more information to pin this down better.  Best of all would be to have effective STR.

Otherwise, as I said above, there's nothing we can do here.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Robert, if nothing else please provide as complete a list as possible of all your crash/hang reports.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Maybe it's just a coincidence, but all the reports from comment #3 are for Firefox release versions.

Robert, could you try today's mozilla-central nightly for a few days, and see if it makes a difference?  First you should probably ensure that "Enable E10S (multi-process)" (in Preferences : General) is unchecked.

Comment 7

[Benjamin Smedberg]

Why aren't we uploading better mac symbols so that it's not an offset but a real function name? I know that we don't have a good automatic process to extract mac symbols, but since we have local people with these symbols we should be able to extract and upload those. Ted, do you have a link to the instructions/scripts for mac symbol upload?

Yes, the signature plugin hangs is the top of the main thread of the plugin process. Not shown in the UI but available from the API is the data for the Firefox process also:

https://crash-stats.mozilla.com/api/ProcessedCrash/?crash_id=283128a2-24bd-4137-9996-20a782141106

If you look at the main thread (thread 0) of the Firefox process (look at upload_file_minidump_browser.json_dump.threads[0].frames) the stack is, in summary:

-[ToolbarWindow sendEvent:]
-[BaseWindow sendEvent:]
...
-[ChildView windowBecameMain:]
-[ChildView updatePluginTopLevelWindowStatus:]
nsChildView::DispatchWindowEvent(mozilla::WidgetGUIEvent&)
...
nsObjectFrame::HandleEvent(nsPresContext*, mozilla::WidgetGUIEvent*, nsEventStatus*)
...
mozilla::plugins::PluginModuleParent::NPP_HandleEvent(_NPP*, void*)
then blocking on the plugin process

It's interesting that Flash is in CoreText/libFontRegistry... I wonder if there's a font issue in Yosemite related to this.
rhelmer, when this happens is plugin-container using 100% CPU or none?

Comment 8

[(not currently active) Ted Mielczarek]

I had some code to do this but it relies on a server that's no longer present:
http://hg.mozilla.org/users/tmielczarek_mozilla.com/mac-breakpad-symbol-gather/

We could probably rewrite this to work with Socorro's symbol upload API nowadays (but users would need to get a token to upload with).

Comment 9

[(not currently active) Ted Mielczarek]

Automated OS X symbol gathering has been filed forever: bug 422527 covered the scripts listed above (but those don't work anymore).

bug 951229 comment 5 has a prototype of a setup to scrape symbols out of OS X system updates which would be awesome to finish off and put into production, but I've never found time for.

Comment 10

[Robert Helmer [:rhelmer]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #7)
> Why aren't we uploading better mac symbols so that it's not an offset but a
> real function name? I know that we don't have a good automatic process to
> extract mac symbols, but since we have local people with these symbols we
> should be able to extract and upload those. Ted, do you have a link to the
> instructions/scripts for mac symbol upload?
> 
> Yes, the signature plugin hangs is the top of the main thread of the plugin
> process. Not shown in the UI but available from the API is the data for the
> Firefox process also:
> 
> https://crash-stats.mozilla.com/api/ProcessedCrash/?crash_id=283128a2-24bd-
> 4137-9996-20a782141106
> 
> If you look at the main thread (thread 0) of the Firefox process (look at
> upload_file_minidump_browser.json_dump.threads[0].frames) the stack is, in
> summary:
> 
> -[ToolbarWindow sendEvent:]
> -[BaseWindow sendEvent:]
> ...
> -[ChildView windowBecameMain:]
> -[ChildView updatePluginTopLevelWindowStatus:]
> nsChildView::DispatchWindowEvent(mozilla::WidgetGUIEvent&)
> ...
> nsObjectFrame::HandleEvent(nsPresContext*, mozilla::WidgetGUIEvent*,
> nsEventStatus*)
> ...
> mozilla::plugins::PluginModuleParent::NPP_HandleEvent(_NPP*, void*)
> then blocking on the plugin process
> 
> It's interesting that Flash is in CoreText/libFontRegistry... I wonder if
> there's a font issue in Yosemite related to this.
> rhelmer, when this happens is plugin-container using 100% CPU or none?

Leaving the needinfo set, will check next time it happens.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Robert:  The single most useful thing you can do here (besides providing good STR) is to paste in report ids (in bp-... format) for all of your crashes that seem related.  We shouldn't draw too many conclusions from a single report.

Comment 12

[Robert Helmer [:rhelmer]]

(In reply to Steven Michaud from comment #11)
> Robert:  The single most useful thing you can do here (besides providing
> good STR) is to paste in report ids (in bp-... format) for all of your
> crashes that seem related.  We shouldn't draw too many conclusions from a
> single report.

Sure thing, will do when I get home.

Comment 13

[Robert Helmer [:rhelmer]]

I took a closer look at this laptop over the weekend - turns out it has a failing disk so it's randomly stalling when reading, which I suspect is actually the underlying cause here.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Makes sense.