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
Just to be sure : Does this also happen in the Firefox safemode ?
The stack trace is code from the OS itself...
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...
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.
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
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.
*** Bug 428699 has been marked as a duplicate of this bug. ***
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.
Simon, which version of Wordpress are you using? I cannot find the "Add media" link. Was this included with Wordpress 2.5?
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?
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
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?)
I have contacted a couple of crash reporters too. Lets wait for their feedback.
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.
Still showing in 8.0.1 and 9.0 but very low volume - 2 in the past 4 weeks.
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.
*** typical 3.x stack
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