Closed Bug 928168 Opened 11 years ago Closed 1 year ago

[10.9] Crashes @ libsystem_kernel.dylib@0x15866 | js::ctypes::FunctionType::Call

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox26 --- unaffected
firefox27 - wontfix
firefox28 --- wontfix
firefox29 --- ?
firefox30 --- affected
firefox48 --- wontfix
firefox49 --- wontfix
firefox-esr45 --- wontfix
firefox50 --- wontfix

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)

Pull request against jetpack-subprocess
53 bytes, text/x-github-pull-request
myk
: review+
jryans
: feedback+
ochameau
: checkin+
Details | Review
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.
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 ]
I expect this to be the #1 Mac topcrasher on the 27 branch soon (after Mavericks gets released).
tracking-firefox27: --- → ?
Keywords: topcrash
topcrash is being replaced by more precise keywords per https://bugzilla.mozilla.org/show_bug.cgi?id=927557#c3
Keywords: topcrash → topcrash-mac
Myk, I'm CCing you on this bug because you're the author of the Firefox OS Simulator.
(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.
I triggered this with simulator disabled but the ADB addon enabled.
> 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.)
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.
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
> I expect this to be the #1 Mac topcrasher on the 27 branch soon (after Mavericks gets released). This has now happened.
We *really* need STR for these crashes.
Keywords: steps-wanted
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.
Those best able to provide STR are regular users of the Simulator (and its extensions), and those who've already seen crashes themselves.
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. :-)
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.
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
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
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]
Keywords: steps-wanted
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.
> and I'm pretty sure the main process crashed I was wrong. Breakpad comes up, but the main FF process keeps running.
(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?
> 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.
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.
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 :-)
> 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 :-)
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.
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 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+
(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
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
(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.
Hi, The crash is still happening. Here is my crash data. https://gist.github.com/sudheesh001/c36b4735d8545c44341d
Status: RESOLVED → REOPENED
Flags: needinfo?
Resolution: FIXED → ---
(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?
(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
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)
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?
status-firefox28: --- → ?
status-firefox29: --- → ?
Flags: needinfo?(smichaud)
Keywords: topcrash-mac
> 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)
Lukas, how should we proceed with this bug given comment 39 and 40?
Flags: needinfo?(lsblakk)
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.
tracking-firefox27: + → -
Flags: needinfo?(lsblakk)
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.
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]
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
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)
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)
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)
> 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.
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.
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.
- 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.
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.
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 ...
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 ...
(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.
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
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
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
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).
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.
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.
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.
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
Next week I'll open a new bug on these new crashes.
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.
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
I tried to reproduce in a debug build, but ended up hitting the same assertion as in bug 966996. I filed bug 973308.
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.
(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!!
Whiteboard: [obsolete str in comment #16] → [obsolete str in comment #16] [STR for "new" crashes in comment #70]
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.
I'm hitting this crash every time I click on a message subject in the Zimbra web UI
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]
See Also: → 973971
I've opened bug 973971 to deal with tne "new" crashes -- which are actually unrelated to this bug as originally filed.
No longer blocks: 966996
No longer depends on: 973308
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]
(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?
(In reply to comment #78) Your stack is *not* the same -- not even close. Only the top couple of lines are.
Sorry! I will tag my comments as obsolete to hide them. I will fill a new bug.
(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?
> 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.
> 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.
I filed bug 974182 for my crash, but I think I am actually seeing bug 973971 (so I closed my bug as a dupe).
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?
*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.
(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.
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.
status-firefox27: affected → wontfix
status-firefox28: affected → wontfix
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."
(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.
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)
> 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)
#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]
Attachment #823316 - Flags: checkin+
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
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
Calixte, here is another where the oldness of the bug means we should raise the # of minimum crashes that the bot cares about.
status-firefox48: affected → wontfix
status-firefox49: affected → wontfix
status-firefox-esr45: affected → wontfix
Flags: needinfo?(cdenizet)
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
Flags: needinfo?(cdenizet)
QA Whiteboard: qa-not-actionable
Severity: critical → S2

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
Status: REOPENED → RESOLVED
Closed: 11 years ago → 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: