Closed Bug 894590 Opened 11 years ago Closed 10 years ago

Flash plugin crashes reproducibly on popularmechanics.com

Categories

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

x86
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: till, Unassigned)

References

()

Details

(Keywords: crash)

Attachments

(2 files)

Attached file Crash report
Doesn't seem to send a crash report to our servers, so I attached the system crash reporter's dump.

Versions:
- Nightly 2013-07-16
- Flash Player 11.8.800.94
So the Flash crashed UI shows up, but without the option to send the report?

The relevant stack is all in system libs:

0   libsystem_kernel.dylib        	0x00007fff977c2212 __pthread_kill + 10
1   libsystem_c.dylib             	0x00007fff8d863b54 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff8d8a7dce abort + 143
3   libc++abi.dylib               	0x00007fff906889eb abort_message + 257
4   libc++abi.dylib               	0x00007fff9068639a default_terminate() + 28
5   libobjc.A.dylib               	0x00007fff8d0e4873 _objc_terminate() + 91
6   libc++abi.dylib               	0x00007fff906863c9 safe_handler_caller(void (*)()) + 8
7   libc++abi.dylib               	0x00007fff90686424 std::terminate() + 16
8   libc++abi.dylib               	0x00007fff9068758b __cxa_throw + 111
9   libobjc.A.dylib               	0x00007fff8d0e450c objc_exception_throw + 327
10  com.apple.CoreFoundation      	0x00007fff9521140a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
11  com.apple.CoreFoundation      	0x00007fff9516902e ___forwarding___ + 414
12  com.apple.CoreFoundation      	0x00007fff95168e18 _CF_forwarding_prep_0 + 232
13  com.apple.AppKit              	0x00007fff90d93f84 -[NSApplication reportException:] + 70
14  com.apple.AppKit              	0x00007fff90e782e2 -[NSApplication run] + 836
15  XUL                           	0x000000010061e4c3 base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) + 259 (message_pump_mac.mm:680)
16  XUL                           	0x000000010061df9a base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 138 (message_pump_mac.mm:216)

Problems:
A. something threw an objc exception and nobody caught it. Probably not our bug
B. I'm not clear on whether the thrown exception was "doesNotRecognizeSelector" or whether that is a secondary exception on top of the first one. If that wasn't the original exception, that's another bug. Not sure whose.
C. std::terminate/_objc_terminate/abort don't trigger breakpad. That seems to be a Firefox bug.

I'm going to leave this bug about the Flash crash and file a separate bug about the abort not being caught by breakpad.

smichaud/benwa: is there a simple way in a debugger to break where the exception is thrown, so that we can verify that part A of this is in fact an Adobe bug before I hand it over to them?
Flags: needinfo?(smichaud)
Flags: needinfo?(bgirard)
This is a complete guess but what about breaking on 'objc_exception_throw'? It seems logical from this stack.
Flags: needinfo?(bgirard)
Severity: normal → critical
Keywords: crash
till, do you have the time to attach your debugger to plugin-container and try to break on objc_exception_throw per comment 2?
A "selector not recognized" exception is often an "access deleted object" bug in disguise.  Here's how it can happen:

1) Object A is deallocated.
2) Object B is allocated at the address formerly used for Object A.
3) Something sends a "message", intended for Object A, to Object B.

> I'm not clear on whether the thrown exception was "doesNotRecognizeSelector"
> or whether that is a secondary exception on top of the first one.

I'd guess there is only one exception.

> s there a simple way in a debugger to break where the exception is thrown

I think you're already seeing that in the tread 0 stack, which contains -[NSApplication reportException:].  You could try breaking on that, and see if it gets called twice.

For my next comment, I'll dig up some more undocumented methods that it might be worth breaking on (possibly specific to OS X 10.8), just in case.
Flags: needinfo?(smichaud)
There's an NSException class, which is actually documented.

I've broken on its following method in past cases:

+ (void)raise:(NSString *)name format:(NSString *)format arguments:(va_list)argList

I'm not sure it'd get called in this case, though.
_NSArrayM is an undocumented interface in the CoreFoundation framework that inherits from NSMutableArray.  I doubt Flash is using it directly (and I'm sure we don't do that), but it's conceivable Flash (or Firefox) is doing something to encourage misbehavior in system code that uses that class.

I think it's more likely, though, that this is an Apple bug.
Breaking in objc_exception_throw, I get the attached backtrace.

If you need further info, ping me on IRC if you want me to do further investigation.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> So the Flash crashed UI shows up, but without the option to send the report?

Oh, and yes, that's exactly what's happening. The UI says "No reports available.", and shows the loading-progress-circle-animation thing forever.

about:crashes also doesn't list these plugin crashes (though I don't even know if it ever contains plugin crashes.)
(In reply to Till Schneidereit [:till] from comment #8)
> Oh, and yes, that's exactly what's happening. The UI says "No reports
> available.", and shows the loading-progress-circle-animation thing forever.

I just saw that the animation is part of the site, overlayed on where the plugin would show.
Jeromie, can you file the first part in bugbase? Looks like a use-after-free or something like that.
Flags: needinfo?(jeclark)
The _NSArrayM business may be a red herring.

But there *is* one bug in bmo that (at least some of the time) involved access to a deleted _NSArrayM object -- bug 678607.  There this class seemed to be used while processing the autorelease pool.
If the _NSArrayM business *isn't* a red herring, I'd guess someone (probably Flash) is autoreleasing objects, and then releasing them (and making them invalid) before the OS removes them from the autorelease pool.
I filed a bug on this (3596184) back on the 16th, and got the following back from the engineer triaging the issue:

I can't reproduce the crash with player 11.8.800.94 on firefox nightly (7-16). Using my Mac 10.8.4. 

I refreshed the url http://www.popularmechanics.com/technology/digital/fact-vs-fiction/the-100-best-sci-fi-movies-of-all-time#slide-26 for about 20 times and found the HTML slider thing swapping out only once or twice. When the slider appeared, I clicked it and it disappeared. The video played smoothly from the beginning to the end. No crash. 

I was also unable to reproduce the issue on either of my machines as well, which was why I kicked it over for someone else to look at.  Any tips on how to reproduce this?
Flags: needinfo?(jeclark)
I can't reproduce this anymore, either: WORKSFORME.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Version and milestone values are being reset to defaults as part of product refactoring.
Version: 11.x → unspecified
Product: External Software Affecting Firefox → External Software Affecting Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: