Closed Bug 1123623 Opened 11 years ago Closed 10 years ago

Crash on second print to PDF

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Version:
35 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jdawiseman, Unassigned)

Details

(Keywords: crash, crashreportid, Whiteboard: [Apple bug])

Crash Data

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150108202552 Steps to reproduce: Command-P, save to PDF. Works. Second webmail, command-P, save to PDF: that crashes, and does so without saving the PDF. Seemingly reliably, the crash happens on the second print to PDF; printing the first page works. OS X Yosemite 10.10.1; Firefox 35.0 (and was having the same problem in 34.0). Actual results: Crash. Expected results: Not crash.
Since reporting earlier today, there have been many more crashes, always on the second print. It even happened with a second print that was cancelled: post cancellation, it crashed.
Can you please go to about:crashes and copy/paste some of the crash report IDs here for these PDF-print-related crashes you're seeing?
Flags: needinfo?(jdawiseman)
Severity: normal → critical
Keywords: crash
bp-5c8526e0-9fe2-4d9b-9d86-3394c2150120 20/01/2015 22:34 bp-f54782b6-a730-4df0-8a8c-252902150120 20/01/2015 22:28 bp-3a9ef577-88ff-4b44-b682-5bb882150120 20/01/2015 11:10 bp-0b1d9fd0-de54-43f0-adea-2ea492150120 20/01/2015 11:02 bp-0220ffd6-8906-4e0e-8f00-0918f2150120 20/01/2015 10:56 7B8BF761-7B4F-4A83-9274-A733F4016E12 20/01/2015 10:38 bp-460dc8d7-4f35-4ace-979b-d46182150120 20/01/2015 10:35
Flags: needinfo?(jdawiseman)
Markus, looks like our cocoa printing code is very sad here. :-\ Do you have ideas?
Component: Untriaged → Widget: Cocoa
Flags: needinfo?(mstange)
Keywords: crashreportid
Product: Firefox → Core
Crash Signature: [@ libobjc.A.dylib@0x10d7]
Please give URLs to a few pages you're trying to print, on which this bug happens.
> Second webmail Do you see this bug on any "ordinary" web pages? Ones which don't require a login to visit?
I'm unable to reproduce this bug, either printing "ordinary" pages or messages from my Gmail account. Do you see these crashes with a clean profile?
(In reply to :Gijs Kruitbosch from comment #4) > Markus, looks like our cocoa printing code is very sad here. :-\ > Do you have ideas? No ideas, except the ones Steven already mentioned. Steven is really the better person to look at this bug.
Flags: needinfo?(mstange)
Another thing: How, exactly, do you initiate printing? Do you choose File : Print from the menu, press cmd-p, or click somewhere on the page (on some button that says "print")?
Flags: needinfo?(jdawiseman)
Command-P. Then, bottom-left of system print dialog, second item in pop-up menu, ‘Save as PDF…’. Yesterday’s crashes were all from my webmail. Just re-tested with a random page on congestioncharging.tfl.gov.uk, the second print resulting in bp-3b4df1d5-9691-4fed-981c-91cd32150121 21/01/2015 21:07
Flags: needinfo?(jdawiseman)
Just re-re-tested, with command-P, esc (thus cancelling), command-p, esc, leading to: bp-9d47a199-df40-4fc9-9459-77dda2150121 21/01/2015 21:10 Second print: it is very reliable.
Interesting. Opened Firefox in Safe Mode. Closed all tabs. Command-T, for one new tab, and pasted in the URL of this page. Only this bugzilla page open. Command-P, esc, command-P, esc, command-P, esc, crash. On the third print rather than the second. Then did it again just to make sure: again, third not second. bp-14b7697c-7525-40cb-85ac-f73c62150121 21/01/2015 21:19 bp-f9972831-ab63-4d03-8741-3aa5a2150121 21/01/2015 21:18
Hopefully that answers all the questions above. Just in case it matters, my 2011 iMac has 20G of memory, of which about 7G is currently unused. And there is lots of spare space on the hard disk.
My evening is finishing, so tried once more. Again thrice: command-p, esc, command-p, esc, command-p, esc, crash. bp-c885e300-3444-4e5b-bd20-e84832150121 21/01/2015 23:18
I'll try your new suggestions when I get the chance. That may not be til tomorrow.
> Command-P, esc, command-P, esc, command-P, esc, crash. So it looks like you're just displaying the Print dialog (with command-P) then (quickly) closing it again, several times in a row. I can do this 10 times or more in a row, and still don't see any crashes. I'm testing with Firefox 35 in OS X 10.10.1 on a Retina MacBook Pro. I tried both with the (less detailed) default print dialog and more detailed one (what you get when you click Show Details in the default dialog). If I'm right about what you're doing to reproduce these crashes, they sound very much like an Apple bug. (The Print dialog is a native one, provided by the OS.) The crash stacks (yours and others') also make this seem likely, as they happen deep in system code. Opera uses a similar Print dialog. Do you see these crashes in Opera?
Do you have an actual printer installed in the OS? If so, what kind is it?
Have you customized your printer settings in the Print dialog?
Excellent questions. • I am using the more detailed dialog. • And I have just tested with Opera, and it crashed just the same.
It looks like you have CorePDF and PDFKit installed. Does this crash still occur when you disable/remove those?
It looks like those are just the names of internal Apple libraries. They're loaded in my Firefox, too, and I haven't installed anything special.
Hmm, strange. I didn't see those libraries when I checked my own instance of Firefox and I seemed to find third-party libraries with these product names, but none that I could correlate with the dylib names. If there are no third-party pdf libraries installed, please ignore my comment.
(In reply to comment #19) Thanks for the info. So this is definitely an Apple bug. But I'd like to get as much information about it as possible before reporting it to them -- hopefully including a way to reproduce it that also works for me. So ... please also answer my questions from comment #17 and comment #18, and provide any other information that you think might be relevant.
CorePDF and PDFKit are definitely Apple system libraries. CorePDF is a framework under /System/Library/PrivateFrameworks/, and PDFKit is a "PlugIn" for the QuickLookUI framework, which is in turn a component framework of the Quartz framework. I imagine they get loaded whenever you try to print to PDF.
My home printer is “Samsung ML-2950 Series (SEC001…)”, where the ellipsis might be a machine ID — and which google doesn’t know). Driver version 1.08. This printer was recently removed and re-added, as that was the only way to change WiFi settings within printer. Maybe that was the cause of the problem. There is also a “PDFwriter”, version 1.1. I have not knowingly customised printer settings. Indeed, rummaging now it seems that there aren’t many options to set. Paper is A4. “Presets: Default Settings”.
Thanks, Julian. I also have a "real" printer (a Lexmark X363dn). But its presence or absence in the Printers & Scanners pref panel doesn't make any difference. I doubt that *which* printer you have (and the printer drivers you're using) makes any difference, since the crashes happen before you actually print anything. So I'm at a loss. I don't know what other questions to ask. Besides the following :-) Stephen and Markus, have you tried to reproduce these crashes? Have you seen any?
I've tried and couldn't see any.
Julian, I just looked through the modules list in one of your crash stacks, and found two files that don't exist anywhere on my OS X 10.10.1 partition: librooksmce.dylib librooksbas.dylib Looking around on the web, I find that these files belong to something called Rapport: http://www.trusteer.com/Products/pc-and-mac-security http://antivirus.about.com/od/vendorwhitepapers/a/rapport.htm Try disabling this (and any other security/antivirus programs you have installed), and see if the crashes still happen.
I've tried also and couldn't get it to crash either.
Mathematica was also crashing with printing, which reminded me to come back here. • Trusteer switched off. • Machine restarted. • Re-test printing from Mathematica: oops, crash. • Re-test printing from Firefox: oops, crash. bp-09407b53-af4d-4a44-9e2b-66dde2150127 27/01/2015 10:07
Thanks, Julian, for your tests. I've since looked at other peoples' crashlogs for this bug, and didn't find the Rapport/Trusteer modules in any logs but yours. Both of our results tend to confirm that Trusteer has nothing to do with these crashes. So once again I'm stumped. You probably should report this bug to Apple. If enough people do that, they might try to investigate it. I'm not going to submit one myself, because we don't have STR.
Whiteboard: [Apple bug]
Apple will ignore it unless I can nail the bug as Apple’s. Is there anything else I can do? Separately, I thank the good burghers of Firefox for taking an interest in a problem which has been proven not be their responsibility.
> I've since looked at other peoples' crashlogs for this bug Please post links thereto in this thread, so that it is as easy as possible for Apple to locate the problem.
(Following up comment #35) I should have mentioned that the above link only shows crashes that happened in the last week, from the time you clicked it.
> Apple will ignore it unless I can nail the bug as Apple’s. That it happens with the same Print dialog in different apps is pretty strong evidence of this.
Should I pick out the first few crashes and post them here? Apple might claim that it is an add-on to my machine that is at fault.
> Should I pick out the first few crashes and post them here? Not a bad idea. You don't need to choose a large number. I suggest including one or two of yours and two or three others, all on different versions of Firefox. Make sure that for all of them, the crash stack includes addresses in PrintCocoaUI (to show that the crashes happen in the Print dialog) and nsPrintDialogServiceX::Show (to show that they happen when Firefox tells the OS to display the dialog) -- otherwise they may not be this bug. And if you really want to go to the trouble, choose reports (other than yours) that don't have anything listed under Extensions than the default extension (which will have the same version as the browser itself). Also feel free to include a URL to this bug in your report to Apple. Good luck! :-)
> the crash stack includes addresses in PrintCocoaUI Can somebody with expertise select those automatically? Or do I have to learn where to look, and then look?
> Can somebody with expertise select those automatically? I don't think so. At least I don't know how to do it. It's not hard to do :-)
Flags: needinfo?(twalker)
On Mac10.11, Nightly 49.0a1, 20160504043118 I am unable to reproduce this. Printing to PDF, doesn't crash. Also per Stevens link in comment #35, there are only two crashes reported recently, that was on release Firefox 45.0.2. No crashes reported on Beta, aurora or Nightly. Closing WFM. If anyone can reproduce, please re-open and provide latest associated crash report(s).
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(twalker)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.