Closed Bug 27962 Opened 25 years ago Closed 25 years ago

Memory Problem when printing.

Categories

(Core :: Printing: Output, defect, P3)

Product:
Core
Component:
Printing: Output
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: andyb, Assigned: dcone)

References

(
URL
)

Details

(Whiteboard: [PDT-])

From Bug Helper: User-Agent: Mozilla/4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) BuildID: 2000012520 The first attempt to print this page does nothing after clicking "OK" in the print dialog. Trying to print again eventually starts the print process but crashes the browser. Reproducible: Always Steps to Reproduce: 1. Open browser. Go to the (long) URL above. 2. Scroll down the page. Click the link for "Replace this column with detailed maps for all turns." 3. Once the new page loads, select "Print..." from the file menu. 4. Click OK. 5. Nothing happens, so go back to step 3 and repeat through step 5 until something does. Actual Results: The page starts printing finally. However, Mozilla crashes. See below for Dr. Watson info. Expected Results: The page should print the first time, and Mozilla should not crash. :) GKHTML.DLL attempted to use a null data pointer variable. Module Name: GKHTML.DLL Application Name: Mozilla.exe Command line: "C:\Program Files\Netscape\Seamonkey\mozilla.exe" Trap 0e 0000 - Invalid page fault eax=00000000 ebx=60b83900 ecx=6026701c edx=00000000 esi=01f9c010 edi=00000000 eip=60176260 esp=0063fb70 ebp=0063fb9c -- -- -- nv up EI pl ZR na PE nc cs=015f ss=0167 ds=0167 es=0167 fs=9bdf gs=0000 GKHTML.DLL:.text 0x5260: >015f:60176260 8b08 mov ecx,dword ptr [eax] sel type base lim/bot ---- ---- -------- -------- cs 015f r-x- 00000000 ffffffff ss 0167 rw-e 00000000 0000fe60 ds 0167 rw-e 00000000 0000fe60 es 0167 rw-e 00000000 0000fe60 fs 9bdf rw-- 8bd55490 00000037 gs 0000 ---- stack base: 00540000 TIB limits: 0062c000 - 00640000 -- stack summary -- 0167:0063fb9c 015f:60176260 GKHTML.DLL:.text 0x5260 (02203650,007adbd0,02203650,60bf186b, 02203650,007adbd0,0063fc24,0063fbf0) -- stack trace -- 0167:0063fb9c 015f:60176260 GKHTML.DLL:.text 0x5260 (02203650,007adbd0,02203650,60bf186b, 02203650,007adbd0,0063fc24,0063fbf0) 015f:60176248 5b pop ebx 015f:60176249 ff764c push dword ptr [esi 4c] 015f:6017624c 8b4e08 mov ecx,dword ptr [esi 08] 015f:6017624f 8d4608 lea eax,[esi 08] 015f:60176252 ff75fc push dword ptr [ebp-04] 015f:60176255 50 push eax 015f:60176256 ff5118 call dword ptr [ecx 18] 015f:60176259 8b4658 mov eax,dword ptr [esi 58] 015f:6017625c 897e48 mov dword ptr [esi 48],edi 015f:6017625f 50 push eax GKHTML.DLL:.text 0x5260: *015f:60176260 8b08 mov ecx,dword ptr [eax] 015f:60176262 ff5150 call dword ptr [ecx 50] 015f:60176265 8b4658 mov eax,dword ptr [esi 58] 015f:60176268 50 push eax 015f:60176269 8b08 mov ecx,dword ptr [eax] 015f:6017626b ff5108 call dword ptr [ecx 08] 015f:6017626e 8b465c mov eax,dword ptr [esi 5c] 015f:60176271 897e58 mov dword ptr [esi 58],edi 015f:60176274 50 push eax 015f:60176275 8b08 mov ecx,dword ptr [eax] 015f:60176277 ff5108 call dword ptr [ecx 08] Let me know if you need any of the other Dr. Watson info.
I think you ran out of memory.. printing this image is about 25 megs of memory.. two copies at once can stress the system. I don't know really what to do about this since we basically layout to the printer, which means we need lots of memory.. just another device we are going out to. I printed this out fine, multiple copies.. but I have a different machine.. different printer.. etc. I will look into why the job is so large.. it may because of clipping, and printers don't handle that well.
If it matters, I am using an HP DeskJet 400L. Notice also that the crash only occurs if the maps of each individual "turn" are present in the right-hand column of the page (as per step 2 in my original description). I have 128Mb of memory and a very large swapfile capacity.
I think this is a size issue with the print Job. It prints find for me.. but I have a different configuration. Is there a background image asscociated with this page?
Status: NEW → ASSIGNED
No background image, only a bgcolor attribute in the body tag.
I tried to reproduce this many times on win 98. andyb@rconnect.com, If you select the file->print menu option for the first time, try waiting for some time and see that the printer icon appears on the taskbar. I noticed that it takes a while to come up on the taskbar and I assume that was why u mentioned that printing does not work for the first time. Printing this page worked for me on NT and 98 both.
That is indeed what happened -- if I waited long enough, the printer icon showed up on the taskbar. I could still see someone impatient (like me? no) thinking that Mozilla did not print and trying to print again, which could still cause a crash.
Yes.. all my test show the virtual memory runs really low.. this file used 28 megs to print.. a couple of these could bring down the best of application. I will be trying to optimize the memory usage.. I have a few things I can do to bring this requirement down.
Summary: crash if I try to print twice or more → Memory Problem when printing.
It looks like the image that is printed is 28 megs.., the only thing I can imagine is that ImageLib is asking for an image this big. Pam can you look at this, the image on the screen is alot smaller.. the one being requested to print is 28 megs. This just may be the way it is..
Assignee: dcone → pnunn
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M14
Today's build on windows(2000022208m14), prints pages very very slow(www.sun.com, www.netscape.com). I have a 450 Mhz, pentium3 machine with 128mb ram. Nominating for beta1.
Keywords: beta1
I haven't had time to look at this one yet. -p
we would relook if it was a top 100 site.
Whiteboard: [PDT-]
Don: Here's what I can see from the imglib side. First I singled out the image so it is the only thing on the page. I saved the image url and pasted it in. http://MapsOnUs.switchboard.com/tclients.pub/tu.3/1c5a1/d3/~38b428d3.cc1ce.660e. 7.38b428d3.1.gif This prints fine. The image is 550x450. At IL_GetImage(), the requested width=0 and height=0, which designates we want to decode to the natural image size of 550x450. It finds the image container in the image cache, and the src_hdr dimens are 550x450. The target imghdr dimens are 550x450. So far, so good. When we print, at PrintDDB, the dimens are at 3438x2813. And it prints ok. When I print the whole page: http://www.MapsOnUs.com/bin/maps-route/usr=~38b428d3.cc1ce.660e.7/c=2/isredir=1/ By the time I get to IL_GetImage the requested width and height is 2788x3413. This comes from nsFrameImageLoader::Init(), where the desiredWidth and desiredHeight is calculated in the TwipsToPixels conversion. I don't think we want to do that. I think we want to request the image at natural dimensions and when we send it to the printer, let the print scale it to the desired dimens. That way we get the benefit of printer scaling. This is what we ended up doing in 4.x, at least on windows, so we could get better than displayscreen resolution on printers. I'm reassigning this back to you, but I'd be more than happy to work with you on it. It kind of a fun problem. -P
Assignee: pnunn → dcone
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
*** Bug 29637 has been marked as a duplicate of this bug. ***
The images are now 10x smaller for the printer. Fixed the initcall in nsFrameImageLoader.cpp to use the canonical pixel scale when requesting an image.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Yeah..this has definitely become fast. Verified with build 2000032909. Marking as such.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.