196306 - [ps] Mozilla goes into a loop when trying to print (even to a file)

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[greg jones]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030306
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030306

Open File/Print. Select print to file. Enter file name and hit print.  Mozilla
goes into an infinite loop and hangs.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Expected Results:  
Printed the page to a file

Comment 1

[Andrew Schultz]

does this happen with every page?  is the printer listed as "Postscript/default"?

Comment 2

[greg jones]

Attachment: what resulted when I tried to print this bug page to file

The Printer is Postscript default.  I select the file button and print to the
default file (mozilla.ps).  Mozilla prints out a partial file and goes into
what 
appears an infinite loop.  I recompiled the 1_3_Branch with --disable-xprint
and
it made no difference. FWI (gtk1, gcc-3.2.2, glibc-2.2.5 using the LFS patches)


Right now, if I want to print the page, I save it to html, and then open it in
OpenOffice to print it. (The latest snap OpenOffice 644_m4).

It appears that Mozilla is getting to a certain point in converting the page to

postscript and then the problem shows up.

Comment 3

[Andrew Schultz]

if you are building Mozilla yourself, can you grab a stracktrace with gdb (be
sure not to compile with --enable-strip)?

Comment 4

[greg jones]

I downloaded the 1.3b seamonkey binary and it worked fine. This is my problem.
Hopefully a recompile of the 1_3_Branch without the extra tweaks will resolve this.

Regards,

Comment 5

[greg jones]

I have something wrong with my build scripts.  The recompile now works.
Sorry for the trouble.

Comment 6

[Andrew Schultz]

FIXED is reserved for bugs fixed by code patches

Comment 7

[Andrew Schultz]

this is WORKSFORME

Comment 8

[Roland Mainz]

Reporter:
Does printing work when you print using Mozilla's Xprint module (which means you
do not have to build with --disable-xprint before trying that out...) ?

Comment 9

[greg jones]

Attachment: This is the patch that is causing the problem.

If in .mozilla, I reverse this patch in user.js with

user_pref("font.FreeType2.enable", false)
user_pref("font.FreeType2.unhinted", true)

then there is no problem printing to a file.

Comment 10

[greg jones]

Roland,

Finally got around to getting the Xprint server up and running. Very nice.

The bad.patch doesn't seem to affect the 1_3_Branch and Xprint.  The page was
written to file prefectly.

Greg

Comment 11

[greg jones]

Mozilla 1_3_Branch && these preferences are set as shown:

pref("font.FreeType2.enable", false)
pref("font.FreeType2.unhinted", true)


Mozilla will print to a file prefectly if an "xprint" printer is selected.

If the "PostScript/Default" printer is selected, Mozilla goes into the infinite
loop when printing to a file.

Regards,

Comment 12

[greg jones]

This looks like a legitimate bug now.

Comment 13

[Andrew Schultz]

I added these two prefs:
user_pref("font.FreeType2.enable", true);
user_pref("font.FreeType2.unhinted",false);

but I still could not reproduce the hang.  Is it any particular page that causes
problems?

Comment 14

[greg jones]

Attachment: what I used to build 1_3_Branch CVS

This is built with gcc-3.2, glibc-2.2.5, gnome 2.2.

Could it be something to do with --enable-xft?

Comment 15

[Andrew Schultz]

worksforme with Xft/CVS build.

greg: if you still have the build directory, can you run from there (libs there
shouldn't be stripped) and grab a stacktrace with gdb?

Comment 16

[Andrew Schultz]

my Xft/CVS build crashed on shutdown after trying to print, but gdb seems
worthless (the stack is just a bunch of ??), even if I attach gdb before the crash.

But I also have the stack walker code active, and it gave an almost as worthless
stack, but at least gave me lib names which included libgfx_gtk and libxpcom, so
my guess would be that xft/gtk2 was trying to shutdown and crashed.

==> blizzard

Comment 17

[Andrew Schultz]

Attachment: stacktrace

less optimization made gdb happy.

it seems to be freeing FreeType stuff, but I have no problems with a
non-gtk2/xft build.

Comment 18

[Andrew Schultz]

valgrind basically claims that |face| at nsFreeType.cpp:950 is an uninitialized
pointer (Address 0x46430D54 is not stack'd, malloc'd or free'd)

I'm a bit suspicious that I'm seeing the same crash as greg, but everything is
the same except for the timing.

Comment 19

[Wayne Mery (:wsmwk)]

greg writes: "Not [seen] for a while!" so closing WFM.
Please reopen if you still see this or believe it is not gone.

Comment 20

[Wayne Mery (:wsmwk)]

[wrong click - sorry for bugspam]