682952 - [OS/2] FF 6 crashes for most of the pages I try to print.

Status: RESOLVED WONTFIX

(Core :: Printing: Output, defect)

Description

[eilygre]

Attachment: 003C_01.TRP

User Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110821145614

Steps to reproduce:

Printing from FF 6 does not work as it should. Some pages are printed as expected, others close down (crash) FF while producing a trap report.
This test is run in a "clean" system: All references to Mozilla (home/plugin) or FF folders are removed from the config.sys



Actual results:

This trap report is produced after trying to print page 2 from a newspaper. Page 1 was printed OK. After selecting Print Preview a "document" with all pages outlined is produced. When I then press Print, the Preview changes back to a full view of the newspaper without all pages outlined, but still in the preview window. I still can select to print page 2 in the Print window. After some display about preparing to print, the print job shows up in the printers job status window. Then FF crashes while producing the trap report and the job is immediately removed from the printers job status window.



Expected results:

FF should have printed the selected page

Comment 1

[Matthias Versen [:Matti]]

We need some OS/2 guys to get a stacktrace

Comment 2

[Peter Weilbacher]

The .TRP file is the equivalent of a stacktrace on OS/2...

Comment 3

[eilygre]

Trying to print the same pages on Vista using the same PC and Printer works OK.

Comment 4

[eilygre]

Printing text documents seem to work.

Comment 5

[eilygre]

After FF has ended its printing process it takes about 30 sec. before the printer starts printing in OS2, while it starts immediate in Vista. 
The printer is Brother HL-2070N. The driver is HP Laserjet 6L

Comment 6

[Dave Yeo]

(In reply to eilygre from comment #0)
> Created attachment 556661 [details]
> 003C_01.TRP
> 

0012F2AC  14B66740   LASERJET  0001:00086740  between LeaveDriver + 2C and EnterDriver - 48
 0012F2B8  14B5C20A   LASERJET  0001:0007C20A  between allocate_memory + 42 and GetPatterns - 8A
 0012F2D0  1F031181   FT2LIB    0001:00011181 
 0012F2D8  00010001   FIREFOX   0001:00000001  between __text + 1 and _main - 133  (in {standard input} and nsBrowserApp.o)
 0012F2DC  0001001A   FIREFOX   0001:0000001A  between __text + 1A and _main - 11A  (in {standard input} and nsBrowserApp.o)

The problem is probably ft2lib, the Innotek Font Engine which is not compatible with newer versions of Firefox (or SeaMonkey and Thunderbird).
You can quickly test by rebooting to a maintainence partition or command prompt and renaming \os2\dll\ft2lib.dll (could be in ecs\dll) or moving it away.
The reboot and test.
If you need it for OpenOffice or something you will need to use regedit2 to remove Firefox from the list of applications under the key innotek font engine IIRC.

Comment 7

[eilygre]

No, this didn't help. Same result.
But I have done some more testing.
If I select to print pages with little graphic, they will be printed. I can't print the pages from www.aftenposten.no, but from Shoutcast.com. The pages from Aftenposten can be printed to a file (PDF), and I then can print the PDF file. The whole process with printing to a PDF file and then print this is MUCH faster the printing directly from FF.

Comment 8

[Rich Walsh]

I can confirm this using both the LASERJET and OMNI drivers - the PSCRIPT driver seems unaffected.

The crash occurs as Cairo is emitting paths that form the outlines of glyphs.  This one occurred as a result of a call to GpiPolySpline().  A similar crash in PMMERGE at 0004:00073B15 may happen during a call to GpiLine().  For a given page, I can identify exactly where it will crash but I can't identify anything that distinguishes that call from any of the previous ones.  This makes me suspect the problem lies in Presentation Manager.

For the LASERJET driver (but not for OMNI), I've found a work-around that enables all of my test pages to print.  In the printer's Properties notebook, go to the "Queue Options" tab and check "printer-specific format", then close the notebook.

Comment 9

[eilygre]

Now works for most of the pages I try to print, but not all. Sometimes the last page is not printed. The printer seems to process the print (blinking lamp), but the PC goes gradually into a hang. The CPU-meter shows no (0.5 %) activity. If I restart the printer the last page is printed. I have to reboot the PC.

Another bug (same?)is, as mentioned earlier, that the content in the Print Preview pages change back to the normal browser display when I select Print, still in the Print Preview window. If I want to print another page I have to close the Print Preview window and then reopen it. Annoying. 
And -- sometimes only the first Print Preview window is filled with the expected content. The following pages are blank with only the header or footer filled in.

Comment 10

[merlincp2]

Attachment: more traps and icsdebug screen shot when exception happens

adding another set of trap files when printing to HPLaser4L.  Includes screen shot from icsdebug when the trap is caught.  Trap still happens with Innotek fontlib disabled for firefox, and also when printer specific format is specified in the output options.

Comment 11

[merlincp2]

Comment on attachment 559861 [details]
more traps and icsdebug screen shot when exception happens

attempting to change the MIME type of the upload to "application/zip"

Comment 12

[Peter Weilbacher]

I think catching stuff in icsdebug only helps, if you have a debug build. It doesn't show at all where in the code this happens, the info in the TRP files is much better.
But since I don't know what code was actually used in the FF that you are using (new versions of the patches were never posted anywhere?!), I cannot comment any further.

Comment 13

[Dave Yeo]

(In reply to Peter Weilbacher from comment #12)
> I think catching stuff in icsdebug only helps, if you have a debug build. It
> doesn't show at all where in the code this happens, the info in the TRP
> files is much better.

Unluckily non of our linkers can handle linking a full xul.dll debug build. Workaround is to only build some components with --enable-symbols

> But since I don't know what code was actually used in the FF that you are
> using (new versions of the patches were never posted anywhere?!), I cannot
> comment any further.

The patches are posted at netlabs, gecko8_patches.zip IIRC

Comment 14

[Steve Wendt]

In mozilla.dev.ports.os2, Steven Levine wrote:

If I believe the symbol decode, it appears that the Laserjet driver has a problem drawing splines or possibly ovals.  The exception occurs only when printing directly.  If I print to a file and drop the resulting file on the printer, it seems to print OK.

Comment 15

[Mats Palmgren (inactive)]

OS/2 is no longer a supported platform in Mozilla's tree.