User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 Camino crashes when "save as PDF" is selected on Mac 10.3.9 print dialog window Reproducible: Always

This is probably bug 289612 (which in turn is probably bug 301720), which none of the developers have been able to reproduce. Reporter, can you please *attach* (not paste) the Mac OS X crashlog you get from this crash? (See http://www.caminobrowser.org/support/sup_bugzilla.html for detailed instructions.)

i got email saying: "you can duplicate bug 311365 with http://www.ssa.gov/policy/docs/progdesc/ssi_st_asst/2005/ma.html Although Camino v1.0a1 crashes, the pdf is properly created. Safari 1.3.1 has no difficulty with this url"

OK, this is not any of the bugs mentioned in comment 1. FWIW, the print dialogue goes away, but I never saw the "Printing..." progress dialogue, and my PDF was corrupted. There are some other bugs out there with this in their summary (bug 268157, bug 305386, bug 285212) but they all seem to involve viewing the page, not printing. I can view this page without problem. So this may be a dupe, may not be. Stack coming. Still needs to see if this crashes Firefox.

bz, can you or someone from layout have a look at this and see if this bug is just a Camino-only manifestation (and thus a dupe) of one of the bugs in comment 3 or if it is a separate bug? The stacks looked different beyond the top lines to me, and this page displays fine unlike those other bugs, but layout stacks are not my forte. This crashes recent Camino branch nightlies when choosing "Save as PDF" from the Mac OS X print dialogue, but it does not cause a crash at all in equivalent Fx branch nightlies.

I have no idea with just the stack. Having local member values (and arg values) could help some -- at least we'd know whether stuff is unexpectedly null or unexpectedly dead.

wfm. Camino trunk build 2005101522 (v1.0+) Mac OS X 10.3.9

I guess it's branch-only, then. It's also a regression, since it doesn't crash 0.8.4. To get bz answers for comment 6, I assume smfr or pink need to crash this in a debug build?

Or Josh, yeah....

Seen in talkback, so confirming.

I'll take a look, I have a 10.3 box at work.

how prevalent is this? every PDF? most PDFs? 2 on the web?

(In reply to comment #12) > how prevalent is this? every PDF? most PDFs? 2 on the web? I think it's probably a small set that are involved in crashing the function or whatever. I only flagged it ? early on because it was a Camino-only regression that was a crasher. It's hard to really tell from Talback because some of the incidents (i.e., me testing) come up as "Camino" rather than as "nsHTMLReflowState::ComputePadding", but it's not a topcrasher. And it may in fact be one of the existing core bugs I mentioned in comment 3, but Boris can't tell without more info.

Saw this in the list blocking Camino 1.0+, bopped on over to check it out. WFM with trunk (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051025 Camino/1.0+). No crash. PDF launched in Preview fine, with no corruption. WFM with branch (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051028 Camino/1.0+). No crash. PDF launched in Preview fine, with no corruption. ...later.

(In reply to comment #14) > WFM with branch (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) > Gecko/20051028 Camino/1.0+). No crash. PDF launched in Preview fine, with no > corruption. > You sure that was the branch? It says "Camino/1.0+" which would infer the trunk. However, "rv:1.8" is the branch. Nick, have you had a chance to look at this on 10.3 in a debug build yet?

Works for me: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051214 Camino/1.0b1+ (Mac OS X 10.3.9 up-to-date with security patches) I tried the posted problem url as well as a few others. I also tried various scale/rotation options.

This still crashes for me on the branch, and I just checked in yesterday's trunk nightly and it crashes there as well, so unfortunately it's not any of the now-fixed bugs with the same signature in comment 3. There are six other instances of this in the 1.0b2 talkback, but only one of them mentioned printing, so it doesn't seem to be too common of an issue.

Pretty sure this is the same thing as bug 336427, so duping. *** This bug has been marked as a duplicate of 336427 ***