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)

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)
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)
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
Too late to fix in 50.1.0 release
status-firefox50: affected → wontfix
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 → 8 months 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: