[OS X] Crash [@ dataRead] uploading a file at wordpress.com / YouTube / Vimeo




11 years ago
5 years ago


(Reporter: simon.bugzilla, Unassigned)



Mac OS X
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [#96 Firefox 3.5.5 topcrash], crash signature)


(1 attachment)



11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040404 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040404 Minefield/3.0pre

Try to upload a file, whether audio, video or image results in browser quitting.

One of my crashes - http://crash-stats.mozilla.com/report/index/712ca2cc-029e-11dd-bceb-001cc4e2bf68

Of note, these have the same errors: http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&signature=%400xffff08a0&query=%400xffff08a0&range_value=1

Reproducible: Always


11 years ago
Summary: Uploading a file on wordpress.com crashes browser → Uploading a file at wordpress.com (new version 2.5) crashes browser
Just to be sure : Does this also happen in the Firefox safemode ?
The stack trace is code from the OS itself...

Keywords: crash

Comment 2

11 years ago
Can you give an example of where to upload if I want to reproduce this crash? Preferably somewhere I don't have to register for a new account...

Comment 3

11 years ago
There sure seems to be a lot of crashes related to this, as noted in comment 0.

We need a reliable and simple way for developers to test this. Does anyone have a good testcase, or reliable steps?

So, what I think is happening is that somewhere OS X is throwing an exception that we're not handling. My first suspicion was nsFilePicker.mm -- that somehow when a user has chosen a file, OS X throws, but it looks like we've guarded against exceptions there. 

A theory: maybe breakpad is not handling objc exceptions yet, which is why we see all these bad stacks. Ted?

Confirming, to make sure it shows up in people's queries.
Ever confirmed: true
Summary: Uploading a file at wordpress.com (new version 2.5) crashes browser → [OS X] Crash [@0xffff08a0] uploading a file at wordpress.com
Yesterday's builds didn't have symbols uploaded, fallout from another bug. I backed that out, so today's builds should be fine. We are handling ObjC exceptions (in a way), they'll show up under one signature (but I can't recall what it is).
Simon:  Do try to find a way to reliably reproduce your crash using a
publicly available URL (or testcase).

All:  Often it's better not to search on whatever's at the top of the
crash stack ... especially if that's a numerical address.  Otherwise
you'll (often) just get a bunch of unrelated crashes.

Here are searches on the second and third items in the stack that
Simon reported in comment #0.  In both cases I searched for "One of
the Top 10 Stack Frames" "is exactly" (in my experience using
"contains" here usually returns no results, possibly due to a bug in
the search engine).

i think must of us know that the end of a stack doesn't mean that the cause is there and the end of the stack may be different. 
Using the range query from comments 0 is already enough to get many reports with "uploading at wordpress" and that's enough to triage and see that it's a common problem

Comment 7

11 years ago
Just for clarity.  To upload files a popup Javascript appears.  You browse for the file, when it start to upload if you click anywhere in the browser it crashes.  If you do not click, the browser does not quit.

Comment 8

11 years ago
I have just tested wordpress ( http://wordpress.org/ ) on my local machine.  /wp-admin/post-new.php  is where the uploader can be found.  Next to "Add media" click on one of the image to load the upload frame.  Find a file, begin to upload and click away from the uploading window.  If someone with some knowledge could make a testcase.  
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Duplicate of this bug: 428699
Flags: blocking1.9?
I don't think we can block on this until there's better STR. This is WFM at this moment, but feel free to renom if we can lock this down a bit better.
Flags: blocking1.9? → blocking1.9-
Keywords: qawanted
Simon, which version of Wordpress are you using? I cannot find the "Add media" link. Was this included with Wordpress 2.5?
Version: unspecified → Trunk

Comment 12

11 years ago
Version 2.5.

Comment 13

11 years ago
Created attachment 316065 [details]
Apple Crash Report

I hope this is more clear.
Simon, I just upgraded to 2.5.1 and I'm not able to reproduce this issue with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052104 Minefield/3.0pre ID:2008052104. Could you please retest if it is still crashing for you?


9 years ago
Keywords: qawanted
Summary: [OS X] Crash [@0xffff08a0] uploading a file at wordpress.com → [OS X] Crash [@ dataRead] uploading a file at wordpress.com

Comment 15

9 years ago
dataRead crashes are frequent enough to make the mac-specific topcrash list, but not the cross-platform list.

mac topcrash #18 for firefox 3.0.13
mac topcrash #22 for firefox 3.5.2

Comment 16

9 years ago
Simon's stack trace includes a function from com.marcmoini.smartscrollx_sxobjc (/Users/Simon/Library/Application Enhancers/Smart Scroll.ape/Contents/Resources/sxobjc.bundle/Contents/MacOS/sxobjc).  I wonder if it's responsible for the crash, at least for the one on his machine.  I know it has been blamed for Safari crashes.
Given the rest of the stack (e.g., CFNetwork, which Gecko doesn't call/use for networking, but which Flash does) and the fact that the default WordPress uploader is a Flash applet, I'd put my money on this being a Flash-related crash.  (Also, neither of the Camino reports for dataRead have SmartScroll installed.)

In Camino's URL report, this crash shows up under 

Hi - we saw this quite a bit on audioboo.fm which uses swfupload - FF3.5.5 would quite regularly crash if you closed the popup window in the middle of an upload.

However, I can't seem to reproduce it on 3.5.6 or 3.6 - was it fixed?
Jonathan: it's quite possible this was a crash in the Flash plugin which has since been fixed. (Have you updated your Flash?)
Keywords: topcrash
Hardware: PowerPC → x86
Whiteboard: [#96 Firefox 3.5.5 topcrash]
I have contacted a couple of crash reporters too. Lets wait for their feedback.
Summary: [OS X] Crash [@ dataRead] uploading a file at wordpress.com → [OS X] Crash [@ dataRead] uploading a file at wordpress.com / YouTube / Vimeo
One crash reporter told me that she has no Flash installed on her system.
Got other feedback. None of the crash reporters from whom I got a reply have Flash installed on their system. Seems like Flash is not related to this particular crash. One other reporter states that Firefox crashes when she is uploading .mov files to Youtube from the desktop.


8 years ago
Crash Signature: [@ dataRead]

Comment 23

7 years ago
Still showing in 8.0.1 and 9.0 but very low volume - 2 in the past 4 weeks.
Keywords: topcrash

Comment 24

5 years ago
Current crash rate is near zero** and nothing like what was originally reported (and still happening) for 3.x versions***. I doubt it's worth keeping this bug open, but please reopen if you feel otherwise.

** 5 crashes in the past 10 months for version 14 or newer.
bp-6937be40-7661-4c73-9e98-3fb932130118 14
bp-7485a125-4e01-4101-9481-03d0d2120924 15
bp-be0a688d-a072-4b09-addd-c37542121002 15.0.1
bp-2d2b348f-4240-4cea-b04e-8641e2121023 16.0.1
bp-926a9182-1d64-4b82-b3bf-dcca82120928 14.0.1

*** typical 3.x stack
0 		@0xffff08a0 	
1 	CoreFoundation 	dataRead 	
2 	CoreFoundation 	CFReadStreamRead 	
3 	CFNetwork 	transmitRequest1 	
4 	CFNetwork 	httpRequestStreamCallBack 	
5 	CFNetwork 	connectionRequestCallBack 	
6 	CoreFoundation 	_CFStreamSignalEventSynch 	
7 	CoreFoundation 	CFWriteStreamSignalEvent 	
8 	CFNetwork 	httpWrFilterStreamCallBack 	
9 	CoreFoundation 	_CFStreamSignalEventSynch 	
10 	CoreFoundation 	CFWriteStreamSignalEvent 	
11 	CFNetwork 	_SocketCallBack
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.