User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 I have an HP 5150 printer that was previously connected via another computer on the network. When I attempt to print to that printer when it is unreachable Firefox crashes. Reproducible: Always Steps to Reproduce: 1. Select print 2. Select an unavailable printer 3. Click print Actual Results: Firefox crashes completely and must be restarted I have found this to be a problem in the last several versions of Firefox. Sorry I don't remember the exact versions.

please install talkback note that usually this is a bug in the printer driver (you can search bugzilla for similar reports)

this WFM on latest trunk, Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; es-ES; rv:1.9a9pre) Gecko/2007110104 Minefield/3.0a9pre. Reporter, can you try running this on the latest nightly trunk build? If it still repros, please add more steps, and paste your crash report here.

I see lots of simliar looking bugs (448056, 353494, 218870, 432083, 302473) but they're all "UNCONFIRMED" or "NEW", how comes? I've hitting the very same issue with Shredder (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081124 Shredder/3.0b1pre) and Firefox (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5). The steps to reproduce are quite simple, at least here: 1. Select print 2. Select an unavailable printer 3. Click print Actual Results: Firefox or Thunderbird crashes completely and must be restarted The "unavailable printer" is a unreachable network printer, not responding to ping or any other network activity (friggin' HP laserjet died...). FF/TB do not crash instantly, but it takes a few seconds until they do.

I can confirm that this is happening on my HP M2727nf. Again a network printer that's not accessible, not the same printer, but probably similar HP driver software. Exact same ability to repeat and crash type. Firefox 3.07 and OS X 10.5.7 This has happened with previous version of Firefox 3. Anything someone needs more from me to track it down?

Does this happen every single time you try printing to the unreachable printer, or only some of the times?

Version from 1.8 branch --> 1.9.0 branch, per comment 3 & 4.

It happens every single time.

http://crash-stats.mozilla.com/report/index/9bfd76c9-1302-4498-9561-99f1e2090528 and http://crash-stats.mozilla.com/report/index/a9513983-8f1e-4a55-bae2-c15022090528

Signature objc_msgSend UUID a9513983-8f1e-4a55-bae2-c15022090528 Time 2009-05-28 10:27:05.375868 Uptime 12140 Last Crash 3010329 seconds before submission Product Firefox Version 3.0.7 Build ID 2009021906 Branch 1.9 OS Mac OS X OS Version 10.5.7 9J61 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 10 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x935ba699 User Comments Processor Notes Crashing Thread Frame Module Signature [Expand] Source 0 libobjc.A.dylib objc_msgSend 1 HPSmartPrint HPSmartPrint@0xe4cc 2 HPSmartPrint HPSmartPrint@0xd436 3 HPPrintSettings HPPrintSettings@0x1395 4 HPPrintSettings HPPrintSettings@0x102b 5 HPPrintSettings HPPrintSettings@0x25bfd 6 HPPrintSettings HPPrintSettings@0x25c92 7 HPPrintSettings HPPrintSettings@0x22a06 8 CFNetwork _LongTimerCallBack 9 CoreFoundation CFRunLoopRunSpecific 10 CoreFoundation CFRunLoopRunInMode 11 HIToolbox RunCurrentEventLoopInMode 12 HIToolbox ReceiveNextEventCommon 13 HIToolbox BlockUntilNextEventMatchingListInMode 14 AppKit _DPSNextEvent 15 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 16 AppKit -[NSApplication run] 17 XUL nsAppShell::Run mozilla/widget/src/cocoa/nsAppShell.mm:598 18 XUL nsAppStartup::Run mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181 19 XUL XRE_main mozilla/toolkit/xre/nsAppRunner.cpp:3193 20 firefox-bin main mozilla/browser/app/nsBrowserApp.cpp:158 21 firefox-bin start crt.c:272 22 firefox-bin start 23 @0x1 HPSmartPrint D1D526DDCC3D7BDCDF808158A74D8A730 HPSmartPrint hpPostScriptPDE A59F65C82A8F121D86041977E22699CB0 hpPostScriptPDE HPPrintSettings C599ADDCF67D05B85BEAD1B9F130F66F0 HPPrintSettings Derek: this is a bug in your HP Printer Driver. Please contact HP directly and provide this bug url with an explanation (along with the versions of your hp printer drivers). I can't really figure out their web site, but it's probably this: http://welcome.hp.com/country/us/en/support.html Reporter: please see comment 8, I'd like to confirm that you indeed are experiencing the same crash (i'm fairly confident you are).

Although I have no doubt that HP has some problems with their driver, and I confess to knowing little of the firefox codebase, or programming on OS X. I still wonder if there isn't something you could do to fix it. I tried using some of the native apple applications when I had this trouble in firefox. And they did not crash, but simply sent let the driver handle the failed print job. I'm not saying I need this fixed, it's just that it looks bad to the user when firefox is unstable and the native Mac apps are not. This might be one of the areas where firefox gets that bad rep as being crash prone. I will submit the bug to HP, but I can almost guarantee that they will point the finger back and say it's a firefox problem and once again the user will be left in the middle.

Oh, it's all software. We could create another process dedicated for printing. Someday we probably will. I expect we'll add support for out of process plugins long before we do out of process printing. However, it's nontrivial. One thing that you could do is open Console.app and check the logs, there might be something more useful (specifically LOG FILES: system.log). If there is stuff that talks about Firefox printing, please copy it to a text file and use "add an attachment" to attach it to this bug report. Also, if HP gives you a URL or some other ID for your report, please mention it here as a comment. As long as HP manages to find an engineer who knows about their software, I'm confident that we will not simply play a blame game. We could actually work with them to find a fix. Given the current stack trace, I'm relatively confident that it's their fault. However, if they explain to us what we've done wrong, we'll gladly change how we talk to them.

Even if it is HP's fault: it's our Firefox crashing, so we better learn to deal with **** printer drivers, even if it involves going through a few more hoops. Kernel developers come to my mind: they have to invent workaround and blacklists for all the weird hardware out there because crashing is just not acceptable; even if it's not their fault. Yes, it's an unfair business :-\

So... this bug morphed. The original report was probably about a buggy *windows* printer driver. The new bug is about a buggy *OS X* printer driver. On windows you can print to one of the Microsoft Imaging printer drivers (there are 5 or so by now, pick the newest one). On OS X you can print to PDF. Once you've printed to a portable format (the microsoft one, or pdf), open the printed document and print it to your printer. So, now you have a workaround. I'm sorry. Working with printers is *hard*. If you want to help work on them, let me know, i'll gladly help you get started. I personally do not have the time, nor is my employer paying me to work on printers (our devices don't support printing at all). Note: bugzilla is a community. It isn't an entitlement. You aren't entitled to make demands of random people. <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> Now. If you like, I can probably arrange for code to blacklist your printer so we refuse to talk to it. I'm half willing to do this, as at this time we have crashes for Canon, HP and iirc Epson. Such code would result in a message indicating that your printer vendor has shipped software which causes your browser to crash, and provide you with a feedback link so that you could complain to your printer vendor (I'll probably include phone numbers too).

Oops, I picked the wrong bug report when I updated, There was another OS X one, but I obviously mis-clicked. Well I don't think that invalidates it though. And I don't need a work around, once I realized the printer was un-reachable I fixed the printer. The problem was Firefox crashed instead of just letting the printer driver gracefully fail. Now as far as etiquette is concerned, I have not made any demands, (In fact I said "I don't need this fixed" I'm simply trying to get this bug the attention I believe it deserves. I think this is a fairly common crash and "if" it could be solved easily I think it could mitigate a lot of the (un-fair) negative attention firefox sometimes receives. As I said before I am not an active developer in the Mozilla community so I don't understand the implications of the problem or possible fixes. Although I am a programmer with thousands of clients so I understand the frustrations from both the Developers and Users views.

Here is the System.log for the time of the crash... May 28 11:25:59 Macintosh HP_LaserJet_M2727nf_MFP__75FBE8_[672]: CMSCreateDataProviderOrGetInfo : Malformed colorspace May 28 11:26:55 Macintosh com.apple.launchd[112] ([0x0-0x1d01d].org.mozilla.firefox[235]): Stray process with PGID equal to this dead job: PID 683 PPID 1 crashreporter May 28 11:26:55 Macintosh com.apple.launchd[112] ([0x0-0x1d01d].org.mozilla.firefox[235]): Exited with exit code: 1 May 28 11:27:04 Macintosh /usr/sbin/ocspd[684]: starting May 28 11:28:04 Macintosh kernel[0]: System Preferenc[689] Unable to clear quarantine `HP LaserJet M2727nf MFP (30029E).app': 93 May 28 11:31:56 Macintosh HP_LaserJet_M2727nf_MFP__30029E_[706]: CMSCreateDataProviderOrGetInfo : Malformed colorspace May 28 11:32:38 Macintosh HP_LaserJet_M2727nf_MFP__30029E_[717]: CMSCreateDataProviderOrGetInfo : Malformed colorspace May 28 11:32:49 Macintosh com.apple.launchd[112] ([0x0-0x3d03d].org.mozilla.firefox[685]): Stray process with PGID equal to this dead job: PID 725 PPID 1 crashreporter May 28 11:32:49 Macintosh com.apple.launchd[112] ([0x0-0x3d03d].org.mozilla.firefox[685]): Exited with exit code: 1 May 28 11:35:15 Macintosh /usr/sbin/ocspd[729]: starting May 28 11:35:22 Macintosh Unknown[23]: Client application bug: DNSServiceResolve(HP\032LaserJet\032M2727nf\032MFP\032(30029E)._pdl-datastream._tcp.local.) active for over two minutes. This places considerable burden on the network. I see a malformed Colorspace message seems to be the trigger (I think).

OK, I spoke with a person from hp's technical support department, +18004746836 I gave them Derek's Printer Model and Serial Number. They've given me a ticket number: 8025724938. Hopefully someone from HP will comment in this bug. They should be able to ask here for additional information from Derek. Thanks in advance to HP and Derek, hopefully something good can come from this. To HP: the most important comments to read are comment 4 which contains the setup procedure (unavailable network printer) and comment 10 which contains the stack trace. You can create an account and add a comment to ask for additional information, note that in general all conversations are public.

So for what it's worth, I see this easily on Mac; I wasn't even trying to print to the HP printer in question, just doing a "Save as PDF" with that printer selected... Simon, Markus, anything we can do here?

Boris, please post a Breakpad id for your crash.

It's the same stack as comment 10, but here you go: http://crash-stats.mozilla.com/report/index/bp-76fd4b67-6ae3-4309-9511-2122d2091213 http://crash-stats.mozilla.com/report/index/bp-51eeb8d9-4e67-4af6-aaeb-3b1682091213 http://crash-stats.mozilla.com/report/index/bp-9b4f15b3-9afb-4e61-b417-778eb2091213 http://crash-stats.mozilla.com/report/index/bp-9807d634-96cd-4e92-ae52-40a992091213 http://crash-stats.mozilla.com/report/index/bp-26974e2a-00db-4007-bf2c-9944d2091211 http://crash-stats.mozilla.com/report/index/bp-1e25b0b6-8407-449d-88ab-9e4512091211 And a slightly different but really the same stack: http://crash-stats.mozilla.com/report/index/bp-aee00636-8f8c-46e4-9b73-aa3752091211 If you want not just my reports but all 1000+ of them from the last week or so (all on mac), see http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=startswith&query=objc_msgSend%20|%20HPSmartPrint%400xe1ef&date=&range_value=1&range_unit=weeks&do_query=1&signature=objc_msgSend%20|%20HPSmartPrint%400xe1ef This is the #16 Mac topcrash in the last week, in fact, based on <http://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&platform=mac&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=&do_query=1>. Confirming it just to get it on the radar. Do we have any contacts at hp to look into comment 17?

And why is there an hp library in our address space anyway, by the by? Looking at the crashes in question, I see modules like "HPSmartPrint", "HPPrintSettings", "hpPostScriptPDE"...

kev, is there anyone you know at hp that might help make the right connections on this?

bz: basically the print setup dialog lets you configure printer specific stuff, to do that, it loads whatever libraries the printer vendors provide. As for why OS X eagerly loads the libraries, it's probably because it partially needs to information to fill in the drop down list and partially to make selecting a printer from the drop down list fast. imo the fix for this is to move the printing ui out of the main process, certainly i want to do something like that for windows :). bz: if your printer is new, could you complain to hp? it's a toll free call :)

As best I can tell these crashes only happen on OS X 10.5.X (not on 10.6 or 10.4). This could mean they're caused by an OS bug (as opposed to an HP bug).

My printer is about a year old, but I will definitely be complaining to HP once I get back to my printer, yes.

I don't have any printers in my apartment. But I did "install" a bunch of printers (in the Print & Fax pref panel) when I was at the MV offices last week, fixing bug 525277. So I'm able to reproduce this bug's crash, have found out more about it, and might even be able to find a workaround. First, whether you crash is determined by which printer you've set as the default in the Print & Fax pref panel -- not which printer you tell Firefox to print to. Second, it does appear that these crashes only happen when an HP printer has been selected as the default, and when you set it to use an HP-specific driver (e.g. "HP Color LaserJet 3800", "HP LaserJet 4350", "HP LaserJet P2015 Series"). (The crashes stop happening when you switch the default printer to use the "Generic PostScript Printer" driver.) But the crashes don't happen *in* a driver -- HPSmartPrint is a framework (installed to /Library/Frameworks/), presumably used by all the various HP printer drivers. Here's detailed STR for this bug's crash (on OS X 10.5.8): 1) Make sure you've selected an HP printer as the default in the Print & Fax pref panel, and make sure it's set to use an HP-specific printer driver. a) Open the Print & Fax pref panel. b) Make sure the "Default Printer" (near the bottom of the panel) is set to an HP printer. c) Select the same printer in the "Printers" list (to the left of the panel) and click on "Options & Supplies". d) Click on the "Driver" tab. e) Make sure "Print Using" is set to an HP-specific printer driver (one whose name starts with "HP"). 2) Start Firefox (any current version) and choose File : Print (or do command+p). 3) Click on the "PDF" button and choose "Save as PDF", then follow the prompts to actually save the current page as a PDF file. 4) Wait for about a minute. At this point I always crash. I also crash (the same crash) if I try to quit Firefox before the minute is up.

I was also noticing that threading issues might be involved on many of these printer related crahes objc_msgSend | HPSmartPrint@0xe1ef|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (94 crashes) 0% (0/94) vs. 14% (2391/16994) ppc with 1 cores 0% (0/94) vs. 4% (656/16994) ppc with 2 cores 0% (0/94) vs. 0% (40/16994) ppc with 4 cores 0% (0/94) vs. 0% (46/16994) x86 with 1 cores 94% (88/94) vs. 79% (13408/16994) x86 with 2 cores 0% (0/94) vs. 1% (251/16994) x86 with 4 cores 5% (5/94) vs. 1% (168/16994) x86 with 8 cores 1% (1/94) vs. 0% (34/16994) x86 with 16 cores

That looks more like it's just x86-specific to me. There are few enough x86 with 1 core in the table that we learn nothing from them (e.g. x86 with 4 cores also has 0 of this crash, and more total incidents!), and there are no crashes at all on ppc, no matter how many cores...

Here's a gdb stack trace which shows the symbols near the top of the stack that Breakpad obscures. But even this stack trace cuts off the crucial top few lines. All the symbols above _LongTimerCallBack() belong to the HPSmartPrint module. But this bug's crashes (at least those I can reproduce) actually happen in Apple's PrintCocoaUI module, when HPSmartPrint's [SPHostInfo printSettings] method attempts to call PrintCocoaUI's [PDEPluginCallback printSettings] method (SPHostInfo's "host" is a PDEPluginCallback object). The [PDEPluginCallback printSettings] method attempts to call the printSettings method of its _printWindowController (a PMPrintWindowController object, also implemented in PrintCocoaUI). But the _printWindowController object was previously deleted, so a crash occurs. I found all this out by turning on step-mode in gdb and stepping through the relevant code. So this turns out to be an Apple bug -- PrintCocoaUI's PDEPluginCallback object fails to retain and release _printWindowController. The fix/workaround is quite simple (as you'll see in my next comment). It's conceivable this is also a threading issue, but I think that's unlikely. The traces for this bug's crash contain three threads created by/for Apple's DesktopServicesPriv framework (in /System/Library/PrivateFrameworks). This framework is multithreaded, has to do with OS-provided modal dialogs, and causes trouble on ShowLeopard (see bug 514921). But there aren't any signs of it on the main thread (_LongTimerCallback belongs to CFNetwork).

As I said in my previous comment, these crashes are an Apple bug. Here's a patch that works around them. Please try out, Boris. And Derek too, if you're still around. A tryserver build will follow in a few hours. It's possible this patch will also fix bug 525277 (which may involve crashes accessing a PMPrintWindowController object's currentPrinter method). In which case this patch should probably replace my current patch for bug 525277 (attachment 417218 [details] [diff] [review]), since this patch is more narrowly targeted. Marcia, I can no longer test the STR from bug 525277 comment #12, since I'm no longer at the MV office. So please test it yourself with this bug's patch, and let us know your results.

Here's a tryserver build made with my patch from comment #30: https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla396680/bugzilla396680-macosx.dmg Please test with it!

So, I have an HP LaserJet 5MP set as my default printer in Print & Fax, am using the HP driver, am running 10.5.8, and I have never, ever crashed when printing. Why?

(In reply to comment #32) Apparently you need to do my STR from comment #26 with the printer offline ("unreachable"). I could have made that clearer in my STR. Sorry.

Revised STR for this bug's crashes, to make clear that the default printer needs to be offline: 1) Make sure you've selected an HP printer as the default in the Print & Fax pref panel, and make sure it's set to use an HP-specific printer driver. a) Open the Print & Fax pref panel. b) Make sure the "Default Printer" (near the bottom of the panel) is set to an HP printer. c) Select the same printer in the "Printers" list (to the left of the panel) and click on "Options & Supplies". d) Click on the "Driver" tab. e) Make sure "Print Using" is set to an HP-specific printer driver (one whose name starts with "HP"). 2) Make sure the default printer is offline -- turn it off, or disconnect it from the network. 3) Start Firefox (any current version) and choose File : Print (or do command+p). 4) Click on the "PDF" button and choose "Save as PDF", then follow the prompts to actually save the current page as a PDF file. 5) Wait for about a minute. At this point I always crash. I also crash (the same crash) if I try to quit Firefox before the minute is up.

In addition to being offline, your printer may need to be on the network (as opposed to connected "locally"), in order to see these crashes: CFNetwork's _LongTimerCallback() and _ShortTimerCallback() perform some kind of Bonjour-specific name lookup. See http://opensource.apple.com/source/CFNetwork/CFNetwork-128/NetServices/CFNetServices.c.

Yeah, it's a network printer located at home, so it's always unreachable when I'm in the office. Earlier today I performed these steps at the office; just now I repeated them at home with the network unreachable. Still no crash. Also, despite this bug's initial Mac-related comments implying this bug has existed at least since early Gecko 1.9.0.x, I tested with Minefield nightlies to be sure "recent" changes weren't required (late November at the office, today's m-c here at home), and I still don't crash.

(In reply to comment #36) There must be some additional key factor that we haven't yet identified. But I still have reason to hope that my patch will fix many (and perhaps all) of this bug's crashes.

For what it's worth, at home (where all my tests on this bug have been performed) my MacBook Pro has an Ethernet connection. The crashes happen whether the ip address is provided by DHCP or manually configured (I run my own DHCP

Oops, I submitted before I'd finished the last sentence: I run my own DHCP server on another computer.

I can confirm that Steven's patch fixes the crash I was seeing (in my debug build, at least).

Please makes sure to file a bug with Apple outlining how their code is incorrect, now that we know exactly what they are doing wrong.

Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/0e27300ec598

I've filed an Apple bug -- rdar://7476910.

Tryserver builds should follow in a few hours.

The 1.9.1-branch build died with a spurious error ("compareZipArchives: members differ"). But here's the 1.9.2-branch tryserver build: https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla396680-192branch/bugzilla396680-192branch-macosx.dmg

Comment on attachment 420429 [details] [diff] [review] 1.9.2 branch fix/workaround (corrected with patch for bug 535908) Looks good, lets give this a little time on the 1.9.2 branch before taking a patch for 1.9.1.

Using the tryserver build in Comment 47, I do not crash using the instructions in Comment 34. I tested with an HP printer that was on our corporate network but offline at the time of th test.

Crash still occurs for me on second print try of session to networked Brother printer in OS X 10.5.8 with Firefox 3.6rc1but all works well in current 3.7a1pre. I posted Bug 537354 which was declared duplicate of this one

jim: firefox3.6 is a relative of mozilla1.9.2, as you can see here, this bug has status1.9.2: --- and there's an approval1.9.2.1? request. The RESOLVED FIXED state explains why it works in firefox 3.7a1pre. Once approvals are provided, someone should push the fix into Firefox 3.6 (hopefully before release, but possibly depending on timing in a service release).

(In reply to comment #51) > jim: firefox3.6 is a relative of mozilla1.9.2, as you can see here, this bug > has status1.9.2: --- and there's an approval1.9.2.1? request. The RESOLVED > FIXED state explains why it works in firefox 3.7a1pre. Once approvals are > provided, someone should push the fix into Firefox 3.6 (hopefully before > release, but possibly depending on timing in a service release). As an average user, I would sure like this to be fixed in release version of 3.6. And I would expect plenty of complaints if it affects a lot of users. I freely admit I do not know all the complications in getting that done.

Roughly speaking: we're working on it (as evidenced by the existing approval1.9.2.1 request, and more recently by the approvail1.9.1.8 request which would be for Firefox 3.5.something), but your comments (and mine) aren't helping. In general, we ask for input from customers until we can figure out what's wrong with something. Once we've actually worked to fix it, we ask for verification that our fix works. We do not ask in general for people to lobby for fixes to be put back. In general our goal is to bring back stability improvements such as this one, but that should not generally be interfered with by the general public. Sometimes we will choose not to backport something, e.g., because it requires substantial changes or requires significant effort. FWIW, we also hope to increase the speed with which we introduce newer versions of our products. Anyway, if you as an end user would like to place pressure somewhere, in this case, I'd request that you complain to Apple, as we've identified the underlying fault as being theirs. You can reference rdar://7476910 which is their tracking number.

Comment on attachment 420430 [details] [diff] [review] 1.9.1 branch fix/workaround (corrected with patch for bug 535908) Approved for 1.9.1.8, a=dveditz for release-drivers

Comment on attachment 420430 [details] [diff] [review] 1.9.1 branch fix/workaround (corrected with patch for bug 535908) Wrong bug -- sorry! This one is _not_ approved for 1.9.1.8 yet, we need more testing and are going to wait to ship with 1.9.2.1

The patch in this bug fixes Bug 525277. This looks to be the top crash on Mac for Firefox 3.6 ->http://tinyurl.com/yarok5a. I think this is a strong case to consider this for a dot release.

This bug's patch is (basically) trivial, and should fix all the following crashes in the current topcrasher list (for FF 3.6 on OS X): Rank Signature Number of crashes 1 objc_msgSend | _nsnote_callback 4456 5 _nsnote_callback 579 6 libobjc.A.dylib@0x15688 | _nsnote_callback 504 13 objc_msgSend | CanonIJPDE@0x1531e 258 36 objc_msgSend | HPSmartPrint@0xe1ef 130 37 libobjc.A.dylib@0x1568c | _nsnote_callback 123

Blocking, and a=beltzner

Landed on the 1.9.2 branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ae68009f697c

Landed on the 1.9.1 branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e97d4004517b

For those seeing this on Firefox 3.6, could you try getting a nightly build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/, installing it, and seeing if the issue is fixed? For those on Firefox 3.5, you can do the same with a build at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/. This will help us confirm that we have correctly fixed this issue.

I am poster of what was originally bug 537394 that was rolled into this one. While the crashes listed in comment 57 mention HP and Canon printers, I am pleased to report that 2/27 3.6.2pre nightly fixes the crashing problem on second print I had with a Brother HL-3040CN when printing to printer connected via Ethernet or simply printing to PDF. OS X 10.5.8, MacPro 2008.

> I am poster of what was originally bug 537394 that was rolled into > this one. You mean bug 537354 :-) > While the crashes listed in comment 57 mention HP and Canon > printers, I am pleased to report that 2/27 3.6.2pre nightly fixes > the crashing problem on second print I had with a Brother HL-3040CN > when printing to printer connected via Ethernet or simply printing > to PDF. OS X 10.5.8, MacPro 2008. Thanks for letting us know!

Marking as verified for 1.9.2.

(Following up comment #57) > This bug's patch is (basically) trivial, and should fix all the > following crashes in the current topcrasher list (for FF 3.6 on OS > X): > > Rank Signature Number of crashes > 1 objc_msgSend | _nsnote_callback 4456 > 5 _nsnote_callback 579 > 6 libobjc.A.dylib@0x15688 | _nsnote_callback 504 > 13 objc_msgSend | CanonIJPDE@0x1531e 258 > 36 objc_msgSend | HPSmartPrint@0xe1ef 130 > 37 libobjc.A.dylib@0x1568c | _nsnote_callback 123 All of these crashes have disappeared as of FF 3.6.2. (There are still some crashes at _nsnote_callback on OS X 10.6.X, but these are a different bug. See bug 525277 comment #39.) Furthermore, the number of crashes per user on OS X has now dropped from 0.39% (in FF 3.6) to 0.29% (in FF 3.6.2): http://crash-stats.mozilla.com/daily?form_selection=by_version&p=Firefox&v[]=3.6&throttle[]=100&v[]=&throttle[]=100&v[]=&throttle[]=100&v[]=&throttle[]=100&os[]=Mac&date_start=2010-03-15&date_end=2010-03-22&submit=Generate http://crash-stats.mozilla.com/daily?form_selection=by_version&p=Firefox&v[]=3.6.2&throttle[]=100&v[]=&throttle[]=100&v[]=&throttle[]=100&v[]=&throttle[]=100&os[]=Mac&date_start=2010-03-18&date_end=2010-04-01&submit=Generate The elimination of these crashes accounts for the entire drop: During the week of 2010-03-16 through 2010-03-22 there were 27187 of these crashes, for a total of 26537410 active daily users (for the ADU figure see the first link above). http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.6&platform=mac&date=03%2F23%2F2010&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=&build_id=&process_type=all&do_query=1 Furthermore, in FF 3.6.2 the number of crashes per user on OS X (0.29%) is consistently about 17% below that number on Windows (0.35%) -- the first time I've ever seen this happen. http://crash-stats.mozilla.com/daily?form_selection=by_version&p=Firefox&v[]=3.6.2&throttle[]=100&v[]=&throttle[]=100&v[]=&throttle[]=100&v[]=&throttle[]=100&os[]=Windows&date_start=2010-03-18&date_end=2010-04-01&submit=Generate

yeah, baby! thats what I'm talkin' about... ;-) very cool. thanks to all those that helped to get this fixed.