Closed
Bug 928168
Opened 11 years ago
Closed 8 months ago
[10.9] Crashes @ libsystem_kernel.dylib@0x15866 | js::ctypes::FunctionType::Call
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
People
(Reporter: smichaud, Unassigned)
References
Details
(Keywords: crash, regression, Whiteboard: [obsolete str in comment #16] [STR for "new" crashes in comment #70][tbird crash][regression:TB31])
Crash Data
Attachments
(1 file)
https://crash-stats.mozilla.com/report/list?signature=libsystem_kernel.dylib%400x15866&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&platform=mac&hang_type=any&date=2013-10-17+22%3A00%3A00&range_value=4#reports These crashes all happen on OS X 10.9 (Mavericks), either DP8 (build 13A584) or the GM (build 13A598). The earliest builds on which I can find these are 2013-09-19-04-02-02-ux and 2013-09-20-04-02-01-ux: bp-3d585603-96a0-4a8b-add5-f25882130921 bp-ec0fd07d-4d22-48dc-b957-69de52130921 This (oddly) suggests the trigger was a patch that landed on the ux branch before it landed on the trunk. But that may be a red herring, because all of these crashes happen in configurations that include the Firefox OS Simulator extension -- usually r2d2b2g@mozilla.org, but sometimes fxos_1_2_simulator@mozilla.org. These are the #7 Mac topcrasher on the 27 branch, even though OS X 10.9 (Mavericks) hasn't been released yet. I expect the number to increase dramatically when 10.9 is released (likely later this month). It's possible that the Firefox OS Simulator is entirely incompatible with OS X Mavericks.
Reporter | ||
Comment 1•11 years ago
|
||
It's likely this is a bug in the FFOS Simulator. But I don't know where to put such bugs, and in any case the crashes are all in JavaScript engine code. Please recategorize this bug if that's appropriate.
Severity: normal → critical
Crash Signature: [@ libsystem_kernel.dylib@0x15866 ]
Reporter | ||
Updated•11 years ago
|
Blocks: mavericks-compat
Reporter | ||
Comment 2•11 years ago
|
||
I expect this to be the #1 Mac topcrasher on the 27 branch soon (after Mavericks gets released).
tracking-firefox27:
--- → ?
Keywords: topcrash
Comment 3•11 years ago
|
||
topcrash is being replaced by more precise keywords per https://bugzilla.mozilla.org/show_bug.cgi?id=927557#c3
Keywords: topcrash → topcrash-mac
Reporter | ||
Comment 4•11 years ago
|
||
Myk, I'm CCing you on this bug because you're the author of the Firefox OS Simulator.
Comment 5•11 years ago
|
||
(In reply to Steven Michaud from comment #0) > These are the #7 Mac topcrasher on the 27 branch, even though OS X 10.9 > (Mavericks) hasn't been released yet. I expect the number to increase > dramatically when 10.9 is released (likely later this month). > > It's possible that the Firefox OS Simulator is entirely incompatible with OS > X Mavericks. Thanks for the heads-up! (In reply to Steven Michaud from comment #4) > Myk, I'm CCing you on this bug because you're the author of the Firefox OS > Simulator. cc:ing a few other folks who also work on the Simulator.
Updated•11 years ago
|
Reporter | ||
Comment 7•11 years ago
|
||
> I triggered this with simulator disabled but the ADB addon enabled.
Do you have STR? (I assume you were testing on OS X 10.9 Mavericks.)
Reporter | ||
Comment 8•11 years ago
|
||
And by the way (for those who don't yet know) Mavericks was released yesterday, as a free update for OS X 10.6.8 and up, and as an "automatic" update (using Software Update) for OS X 10.8.5 and up. So we're going to get *lots* of new Mavericks users, very quickly.
Comment 9•11 years ago
|
||
All these addons: r2d2b2, fxos_simulator and adb helper all uses subprocess[1], based on enigma jsctype IPC library. It may be crashing because of this library. I'll try to upgrade my mac. [1] https://github.com/ochameau/jetpack-subprocess
Reporter | ||
Comment 10•11 years ago
|
||
> I expect this to be the #1 Mac topcrasher on the 27 branch soon (after Mavericks gets released).
This has now happened.
Comment 12•11 years ago
|
||
I tried installing the simulator on a recent nightly and wasn't able to crash. Will take a look at the URLs today and see if I can trigger a crash.
Reporter | ||
Comment 13•11 years ago
|
||
Those best able to provide STR are regular users of the Simulator (and its extensions), and those who've already seen crashes themselves.
Comment 14•11 years ago
|
||
So I can't help here. I'm on 10.6.8 and really don't want to attempt to upgrade this machine to Mav's. However, I am overdue for a hardware refresh. Send me a beefy MacPro with 10.9 o' mighty Mozilla Service Desk. :-)
Reporter | ||
Comment 15•11 years ago
|
||
You don't have to upgrade your working partition to 10.9 -- I wouldn't do that either :-) You *can* install 10.9 on a spare partition (or in a VM) and test there. Please do! By "you" I particularly mean users of the Simulator.
Comment hidden (obsolete) |
Comment 17•11 years ago
|
||
Also, I'm seing following error message that may help figuring out what's wrong. But I have no idea how to break in this method.. in the child. I tried process attach --waitfor, but it looks like it breaks only when the child already crashed :( 10/24/13 5:30:00.322 PM firefox[45788]: firefox(45788,0x7fff77ae6310) malloc: *** error for object 0x11f032e28: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug
Comment 18•11 years ago
|
||
Also, I'm seing following error message that may help figuring out what's wrong. But I have no idea how to break in this method.. in the child. I tried process attach --waitfor, but it looks like it breaks only when the child already crashed :( 10/24/13 5:30:00.322 PM firefox[45788]: firefox(45788,0x7fff77ae6310) malloc: *** error for object 0x11f032e28: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug And the fork call happens here: https://github.com/mykmelez/jetpack-subprocess/blob/master/lib/subprocess.js#L1264
Reporter | ||
Comment 19•11 years ago
|
||
The STR from comment #16 work for me! I tested with today's m-c nightly on a plain-vanilla fresh install (not an upgrade) of the OS X 10.9 "release" (build13A603). bp-50191a44-4574-4703-aa76-854aa2131024 But I don't see any errors in the Console, and I'm pretty sure the main process crashed. I'll do a custom non-opt non-debug build, and see if I can get a gdb stack trace.
Keywords: reproducible
Whiteboard: [str in comment #16]
Reporter | ||
Updated•11 years ago
|
Keywords: steps-wanted
Reporter | ||
Comment 20•11 years ago
|
||
Actually I should be able to get a gdb stack trace using a mozilla-central nightly, since they don't have their symbols stripped. But Apple's commandline tools for Mavericks don't contain gdb! And when instead I ran today's m-c nightly in lldb the crash didn't happen, and the Simulator ran just fine. I'll keep digging.
Reporter | ||
Comment 21•11 years ago
|
||
> and I'm pretty sure the main process crashed
I was wrong. Breakpad comes up, but the main FF process keeps running.
Comment 22•11 years ago
|
||
(In reply to Steven Michaud from comment #20) > Actually I should be able to get a gdb stack trace using a mozilla-central > nightly, since they don't have their symbols stripped. But Apple's > commandline tools for Mavericks don't contain gdb! I don't have Mavericks yet (downloading it now), but is it possible that you need to install the Command Line Tools package from Xcode > Preferences > Downloads > Components?
Reporter | ||
Comment 23•11 years ago
|
||
> is it possible that you need to install the Command Line Tools
Nope. I've already installed them. They just don't contain gdb :-(
Others must surely have noticed this. I'm going to look around on the web to see what advice I can find.
Comment 24•11 years ago
|
||
Do not waste too much time getting a stack trace, I have already narrowed it down to this fork() call. On maverick, you should use lldb instead of gdb. Using vfork or posix_spawn avoid this crash. I'm all but an expert on this but I will try to craft a patch against subprocess. Using fork in js is really scary as I have no idea how JS and especially the GC handle such scenario. I tend to think posix_spawn would prevent cross process/threads JS.
Reporter | ||
Comment 25•11 years ago
|
||
http://stackoverflow.com/questions/19554439/gdb-missing-in-os-x-mavericks Apparently if you want gdb you have to build it yourself, from scratch :-( But one of the commenters claims to have done this successfully. I'll try it myself, and post here any gotchas I find. (lldb seems rather less powerful than gdb.) > Do not waste too much time getting a stack trace ... Using vfork or posix_spawn avoid this crash Thanks, and I won't :-)
Reporter | ||
Comment 26•11 years ago
|
||
> I will try to craft a patch against subprocess.
Please do this, Alexandre, and post it here.
Is "subprocess" part of the Mozilla tree, by the way, or does it live in some github repository out beyond the edge of the world :-)
Comment 27•11 years ago
|
||
Subprocess is being used by the simulator addon to launch b2g process. It lives outside of m-c. The very original code comes from http://hg.mozilla.org/ipccode but we end up using a wrapper on top of it hosted here: https://github.com/mykmelez/jetpack-subprocess The simulator is hosted here, and pull jetpack-suprocess from there: https://github.com/mozilla/r2d2b2g/tree/master/addon/packages I was off today, but fixing this is on top of my queue.
Comment 28•11 years ago
|
||
We need to fix subprocess to address this crash. Unfortunately it involves some low level work on launching process from JS, via jsctypes... Myk, I flagged you as reviewer, but feel free to redirect this review to whoever makes sense. We don't have much people involved in these topics! While looking at this, I have seen many ways to simplify subprocess. For example, it would be really interesting to use OS.File internals to call libc read/write/... functions. The upstream mercurial repository got some new revisions and we should merge. But here I would like to fix this crash ASAP so I've only fixed the crash with a minimal change.
Assignee: nobody → poirot.alex
Attachment #823316 -
Flags: review?(myk)
Attachment #823316 -
Flags: feedback?(jryans)
Attachment #823316 -
Flags: feedback?(jryans) → feedback+
Comment 30•11 years ago
|
||
Comment on attachment 823316 [details] [review] Pull request against jetpack-subprocess I'm not a huge fan of the hack this employs to size the opaque struct posix_spawn_file_actions_t, but I don't see how to do it properly. Perhaps a js-ctypes expert would know, and we should consult with them, but in the meantime, r=myk to fix this topcrasher, since a potential crash down the road is still better than a known crash today.
Attachment #823316 -
Flags: review?(myk) → review+
Comment 31•11 years ago
|
||
(In reply to Myk Melez [:myk] [@mykmelez] from comment #30) > Comment on attachment 823316 [details] [review] > Pull request against jetpack-subprocess > > I'm not a huge fan of the hack this employs to size the opaque struct > posix_spawn_file_actions_t, but I don't see how to do it properly. Perhaps > a js-ctypes expert would know, and we should consult with them, but in the > meantime, r=myk to fix this topcrasher, since a potential crash down the > road is still better than a known crash today. I asked Yorik, but getting the size at runtime without any compiled code seems unlikely. What we could do is do what Yorik did for OS.File and add an item for this struct size over here: http://mxr.mozilla.org/mozilla-central/source/dom/system/OSFileConstants.cpp#496
Comment 32•11 years ago
|
||
This crash should be fixed now. Please reopen if you still see it. But ensure running the very last version of the simulator available here: https://ftp.mozilla.org/pub/mozilla.org/labs/fxos-simulator/
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 33•11 years ago
|
||
(In reply to Alexandre Poirot (:ochameau) from comment #31) > I asked Yorik, but getting the size at runtime without any compiled code > seems unlikely. > What we could do is do what Yorik did for OS.File and add an item for this > struct size over here: > > http://mxr.mozilla.org/mozilla-central/source/dom/system/OSFileConstants. > cpp#496 That's a good idea, and we shouldn't lose it, so I filed bug 936297 on doing it.
Comment 34•11 years ago
|
||
Hi, The crash is still happening. Here is my crash data. https://gist.github.com/sudheesh001/c36b4735d8545c44341d
Status: RESOLVED → REOPENED
Flags: needinfo?
Resolution: FIXED → ---
Comment 35•11 years ago
|
||
(In reply to Sudheesh Singanamalla (:ShellHacker) from comment #34) > Hi, The crash is still happening. Here is my crash data. > > https://gist.github.com/sudheesh001/c36b4735d8545c44341d Which version of simulator do you have installed?
Flags: needinfo?
Comment 36•11 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #35) > (In reply to Sudheesh Singanamalla (:ShellHacker) from comment #34) > > Hi, The crash is still happening. Here is my crash data. > > > > https://gist.github.com/sudheesh001/c36b4735d8545c44341d > > Which version of simulator do you have installed? I am running the latest version. I re-downloaded and re-installed the simulator addon to make sure I was on the latest version. It crashes on the Nightly UX (28.0a1 (2013-11-15)) build, the addon seems stable on the release version of Firefox. (v24,25) on Mac OS X 10.9
Comment 37•11 years ago
|
||
Could you give me the link to the crash report that should have been created in about:crashes? Also, can you open about:addons and report back which simulator addons your have installed and their version number? Thanks!
Flags: needinfo?(sudheesh1995)
Comment 38•11 years ago
|
||
Here are the crash reports : [1] https://crash-stats.mozilla.com/report/index/0fc2e792-1f48-43bf-a77c-44bd22131119 [2] https://crash-stats.mozilla.com/report/index/b7d31314-87d6-466d-9756-a89b92131113 In about:addons, I have Firefox OS Simulator 4.0
Flags: needinfo?(sudheesh1995)
Comment 39•11 years ago
|
||
This signature is not showing up at all for Firefox 26, 27, and 28 in the top-300 crashes for the last 28 days. It does show up for Firefox 29 but only at #50 accounting for 0.22% of the crashes. Comparatively this has dropped to #57 in the last 7 days at 0.21%. Steven, are you still able to reproduce this across all branches?
Reporter | ||
Comment 40•11 years ago
|
||
> Steven, are you still able to reproduce this across all branches? I know very little about the simulator, and have only ever been able to reproduce these crashes using the STR from comment #16. So my being unable to reproduce them doesn't mean a whole lot. But in any case, I just tried comment #16's STR in today's mozilla-central and aurora nightlies, each time starting with a clean profile. I didn't see any crash (or any other problem). I tested on OS X 10.9.1. (There doesn't seem to be any point for me to test on the other branches.)
Flags: needinfo?(smichaud)
Comment 41•11 years ago
|
||
Lukas, how should we proceed with this bug given comment 39 and 40?
Flags: needinfo?(lsblakk)
Comment 42•11 years ago
|
||
Reading through this and seeing that it's primarily when using the Simulator or other Firefox OS development tools makes this a non-critical issue for general release tracking as we probably don't have a lot of users on those tools (internally, of course we do). If/when a low risk fix surfaces we can consider it for uplift but given the numbers in comment 39 there's nothing to track here atm.
Flags: needinfo?(lsblakk)
Comment 43•11 years ago
|
||
I tried to reproduce this issue on the latest Firefox 27 and 28 with the steps in comment 16, but there were no crashes with any of the simulators. Given this and comment 40, I think the "reproducible" keyword should be removed from here.
Reporter | ||
Comment 44•11 years ago
|
||
It *was* reproducible, up until attachment 823316 [details] [review] landed. But I agree that it no longer is.
Keywords: reproducible
Whiteboard: [str in comment #16] → [obsolete str in comment #16]
Reporter | ||
Comment 45•11 years ago
|
||
Fewer than half of these crashes in the last week are associated with the FFOS Simulator extension (r2d2b2g@mozilla.org v4.0, which I assume is the current version). So if these become numerous enough that we feel obliged to deal with them, it'd be very convenient to have an old version of the FFOS Simulator extension to test with (one with which we can easily reproduce these crashes). Ochameau, is this something you could provide (if the need arises)?
Flags: needinfo?(poirot.alex)
Summary: [10.9] Crashes @ libsystem_kernel.dylib@0x15866 | js::ctypes::FunctionType::Call with FFOS Simulator extension → [10.9] Crashes @ libsystem_kernel.dylib@0x15866 | js::ctypes::FunctionType::Call
Comment 46•11 years ago
|
||
Ok, here is a quick summary of simulator addon versions: 4.0, also called Firefox OS Simulator classic 1.1, hoster on AMO: https://addons.mozilla.org/fr/firefox/addon/firefox-os-simulator/ Should be more and more deprecated as it only works up to FF25. But it hasn't been updated to address maverick crash, so, may be we should spawn new xpis, to address crashes of people not updating their firefox or not switching to new simulator addons. 6.0 also called Firefox OS Simulator 1.2, hosted on ftp: https://ftp.mozilla.org/pub/mozilla.org/labs/fxos-simulator/1.2/ Should be crash free, so far, compatible with all current firefox version. (we experience an exception on FF26 by mistake, should be fixed very soon) 7.0 also called Firefox OS Simulator 1.3, hosted on ftp: https://ftp.mozilla.org/pub/mozilla.org/labs/fxos-simulator/1.3/ Same story than 6.0 Note that each simulator version has different addon id, so that you can install all of them and run simulator for each b2g version.
Flags: needinfo?(poirot.alex)
Reporter | ||
Comment 47•11 years ago
|
||
Ochameau, thanks for the information (which is very useful), but you misunderstood my question. Since your fix to the FFOS Simulator didn't make this bug go away (and since most of the crashes now happen without it), the cause of the bug lies elsewhere -- in Firefox, or possibly in Apple code. Right now there may be too few of these crashes for us to bother with. But if we decide otherwise, we'll need a way to reproduce them. Right now the only sure way is to use older versions of the FFOS Simulator. But even if those older versions are still available somewhere (which I don't know), we'd need different STR than in comment #16 to use them to reproduce this bug's crashes. What I'm asking is, is this something you can provide, if the need arises?
Flags: needinfo?(poirot.alex)
Comment 48•11 years ago
|
||
Isn't it crashing because of r2d2b2g@mozilla.org v4.0? That simulator got a lot of traction and I imagine many people are still using it. And because addon ids are different they won't be updated to 6.0/7.0 that are crash free.
Flags: needinfo?(poirot.alex)
Reporter | ||
Comment 49•11 years ago
|
||
> Isn't it crashing because of r2d2b2g@mozilla.org v4.0? Among current crash stacks (from the last week) there are a few where this version of this extension is present. But most of them don't have it (or any other version of the FFOS Simulator). In any case, though, the STR from comment #16 no longer work, using any version of the FFOS Simulator that's available using those STR.
Comment 50•11 years ago
|
||
A lower level STR is simple, use subprocess library, without the maverick changeset: https://github.com/ochameau/jetpack-subprocess/commit/0cac10cb72ee0fab3eb34dc2aea40753b1dec4c8 An even lower level STR is to try to run libc fork() function with jsctypes, that was the crash root issue. Note that this crash isn't simulator specific, it may happen to any addon using subprocess library. There is at least another addon using it, the adb helper.
Reporter | ||
Comment 51•11 years ago
|
||
I know almost nothing about the Firefox Simulator or the subprocess library. Neither will (probably) whoever works on this bug. If you can, please provide explicit steps to reproduce these crashes, which anyone can follow.
Comment 52•11 years ago
|
||
- Install FFOS simulator 4.0 from https://addons.mozilla.org/fr/firefox/addon/firefox-os-simulator/ - open web developer menu and then Firefox os simulator - click on the simulator toggle which in "STOPPED" state - here it should crash, without crashing firefox itself. The simulator won't start, the simulator itself crashes.
Reporter | ||
Comment 53•11 years ago
|
||
These STR don't work for me (no crashes). I tested in FF 25.0.1, FF 26 and today's mozilla-central on OS X 10.9.1. Here's what I did exactly: 1) If not already installed, install FFOS Simulator 4.0 from https://addons.mozilla.org/fr/firefox/addon/firefox-os-simulator/. 2) Select Tools : Web Developer : Firefox OS Simulator 3) Click on the Simulator toggle button that initially reads Stopped. No crashes. Even when I click fairly rapidly on the toggle button, changing its state from Stopped to Running and back again.
Reporter | ||
Comment 54•11 years ago
|
||
I double-checked, and found that we have stacks for this bug's crash on OS X 10.9.1. I also noticed that some of the crashes with this signature are unrelated. And some of those that *are* this bug's crash don't have the XUL symbols translated. The top few lines of those are as follows: 0 libsystem_kernel.dylib libsystem_kernel.dylib@0x15866 1 libsystem_pthread.dylib libsystem_pthread.dylib@0x235c 2 libsystem_c.dylib libsystem_c.dylib@0x5cbba 3 libsystem_malloc.dylib libsystem_malloc.dylib@0x11093 4 XUL XUL@0x238b025 5 firefox firefox@0x1 6 XUL XUL@0xdf3300 ...
Comment 55•11 years ago
|
||
It's happing here too. Process: firefox [17565] Path: /Applications/Firefox.app/Contents/MacOS/firefox Identifier: firefox Version: 26.0 (2613.12.5) Code Type: X86-64 (Native) Parent Process: firefox [17560] Responsible: firefox [17560] User ID: 501 Date/Time: 2014-01-19 20:22:25.215 -0200 OS Version: Mac OS X 10.9.1 (13B42) Report Version: 11 Anonymous UUID: 8ABD63C5-5D45-7193-AAFE-4C3342711672 Sleep/Wake UUID: DD2967A9-0966-408F-A6ED-DB7B71C9C3BE Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Application Specific Information: *** multi-threaded process forked *** crashed on child side of fork pre-exec *** error for object 0x11cb41f98: pointer being freed was not allocated Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8d2eb866 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff90d6f35c pthread_kill + 92 2 libsystem_c.dylib 0x00007fff8786dbba abort + 125 3 libsystem_malloc.dylib 0x00007fff90879093 free + 411 4 XUL 0x00000001038aa35a 0x101a9c000 + 31515482 5 XUL 0x0000000103592f62 0x101a9c000 + 28274530 6 XUL 0x000000010359339a 0x101a9c000 + 28275610 7 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 8 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 9 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 10 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 11 XUL 0x0000000103592f62 0x101a9c000 + 28274530 12 XUL 0x000000010359030b 0x101a9c000 + 28263179 13 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 14 XUL 0x0000000103593063 0x101a9c000 + 28274787 15 XUL 0x000000010359339a 0x101a9c000 + 28275610 16 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 17 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 18 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 19 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 20 XUL 0x0000000103592f62 0x101a9c000 + 28274530 21 XUL 0x000000010359030b 0x101a9c000 + 28263179 22 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 23 XUL 0x0000000103593063 0x101a9c000 + 28274787 24 XUL 0x000000010359339a 0x101a9c000 + 28275610 25 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 26 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 27 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 28 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 29 XUL 0x0000000103592f62 0x101a9c000 + 28274530 30 XUL 0x000000010359030b 0x101a9c000 + 28263179 31 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 32 XUL 0x0000000103593063 0x101a9c000 + 28274787 33 XUL 0x000000010359339a 0x101a9c000 + 28275610 34 XUL 0x000000010359373c 0x101a9c000 + 28276540 35 XUL 0x00000001036c9f72 0x101a9c000 + 29548402 36 XUL 0x00000001036c346e 0x101a9c000 + 29521006 37 XUL 0x00000001036c69ab 0x101a9c000 + 29534635 38 XUL 0x00000001036dd7ef js::DirectProxyHandler::set(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<long>, bool, JS::MutableHandle<JS::Value>) + 127 39 XUL 0x0000000103716718 js::CrossCompartmentWrapper::set(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<long>, bool, JS::MutableHandle<JS::Value>) + 280 40 XUL 0x00000001036e3435 0x101a9c000 + 29652021 41 XUL 0x00000001036e47d6 0x101a9c000 + 29657046 42 XUL 0x00000001036bd9c4 0x101a9c000 + 29497796 43 XUL 0x0000000103598426 0x101a9c000 + 28296230 44 XUL 0x000000010358c9ee 0x101a9c000 + 28248558 45 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 46 XUL 0x0000000103593063 0x101a9c000 + 28274787 47 XUL 0x000000010368828a 0x101a9c000 + 29278858 48 XUL 0x0000000103592f62 0x101a9c000 + 28274530 49 XUL 0x000000010359339a 0x101a9c000 + 28275610 50 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 51 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 52 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 53 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 54 XUL 0x0000000103592f62 0x101a9c000 + 28274530 55 XUL 0x000000010359030b 0x101a9c000 + 28263179 56 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 57 XUL 0x0000000103593063 0x101a9c000 + 28274787 58 XUL 0x000000010368828a 0x101a9c000 + 29278858 59 XUL 0x0000000103592f62 0x101a9c000 + 28274530 60 XUL 0x000000010359030b 0x101a9c000 + 28263179 61 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 62 XUL 0x0000000103593063 0x101a9c000 + 28274787 63 XUL 0x000000010359339a 0x101a9c000 + 28275610 64 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 65 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 66 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 67 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 68 XUL 0x0000000103592f62 0x101a9c000 + 28274530 69 XUL 0x000000010359030b 0x101a9c000 + 28263179 70 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 71 XUL 0x0000000103593063 0x101a9c000 + 28274787 72 XUL 0x0000000103688b19 0x101a9c000 + 29281049 73 XUL 0x0000000103592f62 0x101a9c000 + 28274530 74 XUL 0x000000010359030b 0x101a9c000 + 28263179 75 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 76 XUL 0x0000000103593063 0x101a9c000 + 28274787 77 XUL 0x000000010359339a 0x101a9c000 + 28275610 78 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 79 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 80 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 81 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 82 XUL 0x0000000103592f62 0x101a9c000 + 28274530 83 XUL 0x000000010359030b 0x101a9c000 + 28263179 84 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 85 XUL 0x0000000103593063 0x101a9c000 + 28274787 86 XUL 0x000000010359339a 0x101a9c000 + 28275610 87 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 88 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 89 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 90 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 91 XUL 0x0000000103592f62 0x101a9c000 + 28274530 92 XUL 0x000000010359030b 0x101a9c000 + 28263179 93 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 94 XUL 0x0000000103593063 0x101a9c000 + 28274787 95 XUL 0x0000000103688b19 0x101a9c000 + 29281049 96 XUL 0x0000000103592f62 0x101a9c000 + 28274530 97 XUL 0x0000000103687bb4 0x101a9c000 + 29277108 98 XUL 0x0000000103592f62 0x101a9c000 + 28274530 99 XUL 0x000000010359339a 0x101a9c000 + 28275610 100 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 101 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 102 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 103 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 104 XUL 0x0000000103592f62 0x101a9c000 + 28274530 105 XUL 0x000000010359030b 0x101a9c000 + 28263179 106 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 107 XUL 0x0000000103593063 0x101a9c000 + 28274787 108 XUL 0x000000010359339a 0x101a9c000 + 28275610 109 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 110 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 111 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 112 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 113 XUL 0x0000000103592f62 0x101a9c000 + 28274530 114 XUL 0x000000010359030b 0x101a9c000 + 28263179 115 XUL 0x0000000103589e0b 0x101a9c000 + 28237323 116 XUL 0x0000000103593063 0x101a9c000 + 28274787 117 XUL 0x000000010359339a 0x101a9c000 + 28275610 118 XUL 0x00000001036dd370 js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 64 119 XUL 0x0000000103716d7f js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 287 120 XUL 0x00000001036e3a10 0x101a9c000 + 29653520 121 XUL 0x00000001036e4b00 0x101a9c000 + 29657856 122 XUL 0x0000000103592f62 0x101a9c000 + 28274530 123 XUL 0x000000010359339a 0x101a9c000 + 28275610 124 XUL 0x000000010364df5d JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::Value*) + 93 125 XUL 0x0000000102612803 0x101a9c000 + 12019715 126 XUL 0x000000010260efe8 0x101a9c000 + 12005352 127 XUL 0x0000000102ec8392 0x101a9c000 + 21152658 128 XUL 0x0000000102ec720b 0x101a9c000 + 21148171 129 XUL 0x0000000102e84904 0x101a9c000 + 20875524 130 XUL 0x0000000102e85905 0x101a9c000 + 20879621 131 XUL 0x0000000101fc98ea 0x101a9c000 + 5429482 132 XUL 0x00000001021850fa 0x101a9c000 + 7246074 133 XUL 0x0000000101fd5574 0x101a9c000 + 5477748 134 XUL 0x0000000101ffe605 0x101a9c000 + 5645829 135 XUL 0x0000000102190b59 0x101a9c000 + 7293785 136 XUL 0x000000010243dbc0 0x101a9c000 + 10099648 137 XUL 0x0000000102440952 0x101a9c000 + 10111314 138 XUL 0x000000010243d5be 0x101a9c000 + 10098110 139 XUL 0x0000000102419f1d 0x101a9c000 + 9953053 140 XUL 0x0000000102eb4170 0x101a9c000 + 21070192 141 XUL 0x0000000102e73970 0x101a9c000 + 20806000 142 XUL 0x00000001028b76b3 0x101a9c000 + 14792371 143 XUL 0x000000010285b909 0x101a9c000 + 14416137 144 com.apple.CoreFoundation 0x00007fff88eca8f1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 145 com.apple.CoreFoundation 0x00007fff88ebc062 __CFRunLoopDoSources0 + 242 146 com.apple.CoreFoundation 0x00007fff88ebb7ef __CFRunLoopRun + 831 147 com.apple.CoreFoundation 0x00007fff88ebb275 CFRunLoopRunSpecific + 309 148 com.apple.HIToolbox 0x00007fff85366f0d RunCurrentEventLoopInMode + 226 149 com.apple.HIToolbox 0x00007fff85366b85 ReceiveNextEventCommon + 173 150 com.apple.HIToolbox 0x00007fff85366abc _BlockUntilNextEventMatchingListInModeWithFilter + 65 151 com.apple.AppKit 0x00007fff8b25228e _DPSNextEvent + 1434 152 com.apple.AppKit 0x00007fff8b2518db -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 153 XUL 0x000000010285af82 0x101a9c000 + 14413698 154 XUL 0x000000010285bf50 0x101a9c000 + 14417744 155 XUL 0x00000001028b7940 0x101a9c000 + 14793024 156 XUL 0x000000010285c3fc 0x101a9c000 + 14418940 157 XUL 0x0000000102eb3fdf 0x101a9c000 + 21069791 158 XUL 0x0000000102e73970 0x101a9c000 + 20806000 159 XUL 0x00000001028b76b3 0x101a9c000 + 14792371 160 XUL 0x000000010285b909 0x101a9c000 + 14416137 161 com.apple.CoreFoundation 0x00007fff88eca8f1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 ...
Reporter | ||
Comment 56•11 years ago
|
||
(In reply to comment #55) You're not adding any new information -- this is just a me too comment. Please don't do this. Also, if (in the future) you need to add a stack trace to some Bugzilla bug which does provide new information, please use "add an attachment" above -- don't just paste in a long stack trace.
Comment 57•11 years ago
|
||
I fixed the crashes related to simulator addon. We still have the old simulator addon 4.0 that crashes on maverick. It will be fixed in a few days with a new xpi released on AMO. I'm unassigning as I don't plan to look at crashes happening outside of simulator scope.
Assignee: poirot.alex → nobody
Comment 58•11 years ago
|
||
I hit this three times using Friday's Nightly, all while scrolling down on Twitter. (Once on a "list of followers" page, twice on the non-linear profile view that Twitter is A/B testing.) bp-b3060a40-b2f7-4dd0-bb6b-0191e2140215 bp-d54c58b8-581e-4b24-af3b-115dd2140215 bp-63f32e91-d72a-4452-a5ea-0a8462140215
Comment 59•11 years ago
|
||
I hit this today while search for Addons on Firefox Nightly 30.0a1 (2014-02-15) Using Mavericks 10.9.1 build 13B42 Firefox 30.0a1 Crash Report [@ libsystem_kernel.dylib@0x15866 ] https://crash-stats.mozilla.com/report/index/1ef098e8-8c55-489e-985b-a3c5e2140216
Reporter | ||
Comment 60•11 years ago
|
||
There's been a huge jump in crashes with this signature starting with the 20140214030202 mozilla-central nightly (30 branch). A lot of the crash stacks seem horribly corrupt -- they contain a lot of nonsense. So it's hard to tell whether this latest development is even the same bug. But whether or not it's the same bug, the circumstances have changed dramatically. Implied regression range for latest crashes: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a62bde1d6efe&tochange=d275eebfae04 Note that, as mentioned above, some crashes with this signature are unrelated, and have been around for a while (for example those containing calls to -[ChildView updateGLContext] and GeForceGLDriver@0xnnnnnn). The "new" crashes contain lots of calls to libc++abi.dylib@0xnnnnnn (which are almost certainly spurious).
Reporter | ||
Comment 61•11 years ago
|
||
Since these "new" crashes are much more frequent, it may be possible to find steps to reproduce. Whoever sees these crashes, *please* try to do so.
Reporter | ||
Comment 62•11 years ago
|
||
I found some crashes with the libc++abi.dylib@0xnnnnnn crap in them that predate the 20140214030202 mozilla-central build: bp-08a10462-1668-4a4c-87a9-58c412140207 (20140206030201) bp-15718e9f-df19-4524-8770-074212140214 (20140210030201) bp-bdf5e52b-f8c9-4e3b-a9d8-fbcdf2140214 (20140211030201) bp-062ed29c-5152-42f9-93eb-664e92140214 (20140211030201) bp-11594320-ff1f-49ea-a63f-9cac52140212 (20140211030201) So my regression range from comment #60 is probably wrong. And it's possible that the libc++abi.dylib@0xnnnnnn corruption is actually a Socorro or Breakpad bug. Nonetheless, the really huge numbers of these crashes (huge for the trunk) start with the 20140214030202 m-c build.
Reporter | ||
Comment 63•11 years ago
|
||
There are also a lot of crashes with the following signatures, starting with the 20140214030202 build: libsystem_kernel.dylib@0x12212 (OS X 10.8.5) libsystem_kernel.dylib@0x16ce2 (OS X 10.7.5) Some (but not all) of them also have libc++abi.dylib@0xnnnnnn corruption. They also tend to have more real information ... but they're distressingly different from each other.
Reporter | ||
Comment 64•11 years ago
|
||
There are also a bunch of crashes on OS X 10.6.8 starting with the 20140214030202 m-c nightly with the following signature: __kill These are much less corrupt, and much more informative: https://crash-stats.mozilla.com/report/list?signature=__kill&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&platform=mac&version=Firefox%3A30.0a1&hang_type=any&date=2014-02-16+06%3A00%3A00&range_value=1#reports
Reporter | ||
Comment 66•11 years ago
|
||
The OS X 10.7.5 crash stacks are also quite good, and look a lot like those on 10.6.8: https://crash-stats.mozilla.com/report/list?signature=libsystem_kernel.dylib%400x16ce2&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&platform=mac&version=Firefox%3A30.0a1&hang_type=any&date=2014-02-16+06%3A00%3A00&range_value=1#reports
Reporter | ||
Comment 67•11 years ago
|
||
It looks like we're throwing a C++ exception. But as far as I know we have no support for that, at least on the Mac. I'll bet the trigger for these "new" crashes is new code that throws a C++ exception.
Reporter | ||
Comment 68•11 years ago
|
||
Markus, one of your patches for bug 966996 seems to have triggered these "new" crashes. Code called from this line (added by your patch) seems to trigger a C++ exception: https://hg.mozilla.org/mozilla-central/annotate/252a41942fc7/gfx/2d/DrawTargetCG.cpp#l850
Blocks: 966996
Comment 69•11 years ago
|
||
I tried to reproduce in a debug build, but ended up hitting the same assertion as in bug 966996. I filed bug 973308.
![]() |
||
Comment 70•11 years ago
|
||
STR |
I could reproduce a similar crash when going to Calendar in Zimbra webmail - it either crashes instantly or after I click on "Week". bp-d6f516c4-6800-4a3c-9bce-947b32140216 bp-0644be5f-b283-4c18-b6c8-76a9d2140216 bp-c4f3d3fb-5567-4bc7-9644-ac6282140216 IOW, we are unable to use Calendar in Zimbra webmail - had to revert to Aurora.
Reporter | ||
Comment 71•11 years ago
|
||
(In reply to comment #70) Me too, testing with today's mozilla-central nightly on OS X 10.8.5 and 10.7.5 Though I had to click around on the Day, Week and Month buttons before I crashed. bp-99bdb274-c078-4b68-8446-3b8022140217 bp-09851989-fd27-4f05-8c49-4aa052140217 Thanks, Gary!!
Reporter | ||
Updated•11 years ago
|
Whiteboard: [obsolete str in comment #16] → [obsolete str in comment #16] [STR for "new" crashes in comment #70]
Reporter | ||
Comment 72•11 years ago
|
||
Here's the regression range for the STR from comment #70 and comment #71: firefox-2014-02-13-03-02-01-mozilla-central firefox-2014-02-14-03-02-02-mozilla-central http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a62bde1d6efe&tochange=d275eebfae04 Next week I'll test if the patches for bug 966996 are the trigger. Though even now we have strong evidence that they are.
Updated•11 years ago
|
status-firefox30:
--- → affected
Keywords: crash,
regression
Comment 73•11 years ago
|
||
I'm hitting this crash every time I click on a message subject in the Zimbra web UI
Comment 74•11 years ago
|
||
I've put up a patch in bug 973308 that should fix this. Sorry about the crashes.
Depends on: 973308
Whiteboard: [obsolete str in comment #16] [STR for "new" crashes in comment #70] → [obsolete str in comment #16] [STR for "new" crashes in comment #70][patch in bug 973308]
Reporter | ||
Comment 75•11 years ago
|
||
I've opened bug 973971 to deal with tne "new" crashes -- which are actually unrelated to this bug as originally filed.
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [obsolete str in comment #16] [STR for "new" crashes in comment #70][patch in bug 973308] → [obsolete str in comment #16] [STR for "new" crashes in comment #70]
Comment hidden (obsolete) |
Comment 77•11 years ago
|
||
(In reply to Chris Peterson (:cpeterson) from comment #76) > Alternate STR 100%: > 1. Load https://twitter.com/mozilla/followers > 2. Hold down the space bar or Page Down key to rapidly scroll down the page. > 3. After a few seconds of scrolling, CRASH! I'm a bit confused. Are these STR for this bug or the recent spike? I'm assuming the recent spike is to be addressed in bug 973971 and/or via bug 973308?
Comment hidden (obsolete) |
Reporter | ||
Comment 79•11 years ago
|
||
(In reply to comment #78) Your stack is *not* the same -- not even close. Only the top couple of lines are.
Comment 80•11 years ago
|
||
Sorry! I will tag my comments as obsolete to hide them. I will fill a new bug.
Comment 81•11 years ago
|
||
(In reply to Chris Peterson (:cpeterson) from comment #80) > Sorry! I will tag my comments as obsolete to hide them. I will fill a new > bug. Before you do that, Stephen is Chris' stack relevant to bug 973971?
Reporter | ||
Comment 82•11 years ago
|
||
> Before you do that, Stephen is Chris' stack relevant to bug 973971? Yes, in a general way. But it's one of those that in bug 973971 I call "corrupt and unreadable", because it was taken on OS X 10.9.X. The only really useful stacks are those from OS X 10.7 or 10.6.
Reporter | ||
Comment 83•11 years ago
|
||
> The only really useful stacks are those from OS X 10.7 or 10.6.
And yes, that's likely to be a bug in Socorro and/or Breakpad. I'll open a bug once I've had a chance to examine the "corrupt" stacks more closely.
Comment 84•11 years ago
|
||
I filed bug 974182 for my crash, but I think I am actually seeing bug 973971 (so I closed my bug as a dupe).
Comment 85•11 years ago
|
||
Steven, I believe this has been fixed in bug 973308. There aren't any reports of this crash on builds after the fix was checked in there. Does that seam reasonable to you?
Reporter | ||
Comment 86•11 years ago
|
||
*This* bug (as originally reported) is actually completely unrelated to bug 973971 or the "new crashes". It was the horribly low quality of the Socorro crash stacks for the "new crashes" on OS X 10.9 and 10.8 that misled us for a while into thinking that the two might be related. Please leave this bug open. It hasn't yet been fixed.
Comment 87•11 years ago
|
||
This shows up at #7 on the Mac crashes for Firefox 28: https://crash-stats.mozilla.com/topcrasher/products/Firefox/versions/28.0b/date_range_type/report/crash_type/browser/os_name/Mac%20OS%20X/result_count/50?days=7
Comment 88•11 years ago
|
||
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #87) > This shows up at #7 on the Mac crashes for Firefox 28: > https://crash-stats.mozilla.com/topcrasher/products/Firefox/versions/28.0b/ > date_range_type/report/crash_type/browser/os_name/Mac%20OS%20X/result_count/ > 50?days=7 Correction, number 6.
I couldn't reproduce the issue under Mac OS X 10.9 using Firefox 28 beta 6 and Nightly 30.0a1 builds. I investigated (among exploratory) with 1.2 Simulator opened from App Manager and also with add-on simulators from comment 46.
Comment 90•11 years ago
|
||
I'm calling this WONTFIX for Firefox 27 and 28 given we are releasing Firefox 28 tomorrow and that this bug is unactionable from a QA standpoint currently.
Comment 91•10 years ago
|
||
A user on the forum just reported this crash: https://support.mozilla.org/en-US/questions/1003882 They're running OS X 10.9 with the crash signature at libsystem_kernel.dylib@0x15866 The user gets crashes when printing. User quote: "As long as I have the default home page in place, I can print."
Comment 92•10 years ago
|
||
(In reply to Moses from comment #91) > A user on the forum just reported this crash: > https://support.mozilla.org/en-US/questions/1003882 Thanks Moses. Could you get more information from this user? In particular it would be good to know what page they're setting as their homepage to reproduce this and what printer they have.
Comment 93•10 years ago
|
||
are TB31 startup crashes bp-cac701f2-a9d4-46c1-bd63-2c3c02140904 and bp-5e98ec16-0f1e-4d93-80f2-ed5bd2140902 this bug? (#2 crash for TB31 mac users) bp-36cc015a-23bc-4af2-be46-640712140903 is same signature but different stack
Flags: needinfo?(smichaud)
Reporter | ||
Comment 94•10 years ago
|
||
> are TB31 startup crashes bp-cac701f2-a9d4-46c1-bd63-2c3c02140904 and
> bp-5e98ec16-0f1e-4d93-80f2-ed5bd2140902 this bug? (#2 crash for
> TB31 mac users)
They match this bug's "description" field, so I'd say "yes" :-)
Flags: needinfo?(smichaud)
Comment 95•10 years ago
|
||
#2 crash for TB31 Mac users. (thanks Steven)
Whiteboard: [obsolete str in comment #16] [STR for "new" crashes in comment #70] → [obsolete str in comment #16] [STR for "new" crashes in comment #70][tbird crash][regression:TB31]
Updated•10 years ago
|
Attachment #823316 -
Flags: checkin+
Comment 96•8 years ago
|
||
Crash volume for signature 'libsystem_kernel.dylib@0x15866': - nightly (version 51): 0 crashes from 2016-08-01. - aurora (version 50): 0 crashes from 2016-08-01. - beta (version 49): 0 crashes from 2016-08-02. - release (version 48): 298 crashes from 2016-07-25. - esr (version 45): 267 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 0 0 0 - aurora 0 0 0 - beta 0 0 0 - release 85 83 41 - esr 12 22 17 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly - aurora - beta - release #189 - esr #464
status-firefox48:
--- → affected
status-firefox-esr45:
--- → affected
Comment 97•8 years ago
|
||
Crash volume for signature 'libsystem_kernel.dylib@0x15866': - nightly (version 51): 0 crashes from 2016-08-01. - aurora (version 50): 0 crashes from 2016-08-01. - beta (version 49): 1 crash from 2016-08-02. - release (version 48): 323 crashes from 2016-07-25. - esr (version 45): 269 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 0 0 0 - aurora 0 0 0 - beta 0 0 0 - release 85 83 41 - esr 12 22 17 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly - aurora - beta #12141 - release #186 - esr #417
status-firefox49:
--- → affected
Comment 98•8 years ago
|
||
Calixte, here is another where the oldness of the bug means we should raise the # of minimum crashes that the bot cares about.
Flags: needinfo?(cdenizet)
Comment 99•8 years ago
|
||
Crash volume for signature 'libsystem_kernel.dylib@0x15866': - nightly (version 52): 0 crashes from 2016-09-19. - aurora (version 51): 0 crashes from 2016-09-19. - beta (version 50): 4 crashes from 2016-09-20. - release (version 49): 29 crashes from 2016-09-05. - esr (version 45): 313 crashes from 2016-06-01. Crash volume on the last weeks (Week N is from 10-03 to 10-09): W. N-1 W. N-2 - nightly 0 0 - aurora 0 0 - beta 4 0 - release 26 3 - esr 23 23 Affected platform: Mac OS X Crash rank on the last 7 days: Browser Content Plugin - nightly - aurora - beta #2847 - release #1503 - esr #401
status-firefox50:
--- → affected
Updated•6 years ago
|
Flags: needinfo?(cdenizet)
Updated•2 years ago
|
Severity: critical → S2
Comment 101•2 years ago
|
||
Since the crash volume is low (less than 15 per week), the severity is downgraded to S3
. Feel free to change it back if you think the bug is still critical.
For more information, please visit auto_nag documentation.
Severity: S2 → S3
Updated•8 months ago
|
Status: REOPENED → RESOLVED
Closed: 11 years ago → 8 months ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•