Last Comment Bug 173234 - Mozilla crashes [@ GDI32.DLL][@ nsDrawingSurfaceWin::Lock]
: Mozilla crashes [@ GDI32.DLL][@ nsDrawingSurfaceWin::Lock]
Status: RESOLVED FIXED
: crash
Product: Core
Classification: Components
Component: Print Preview (show other bugs)
: Trunk
: x86 Windows XP
: P1 critical (vote)
: mozilla1.2beta
Assigned To: dcone (gone)
: sujay
Mentors:
http://www.riemenschneider-gymnasium.de/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-08 04:00 PDT by Peter Thomassen
Modified: 2002-11-25 16:28 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Stack from 12252579 (2.26 KB, text/plain)
2002-10-08 08:44 PDT, greer
no flags Details
Checks for a valid bitmap before proceeding with the lock. (2.02 KB, patch)
2002-10-11 06:32 PDT, dcone (gone)
dcone: review+
Details | Diff | Splinter Review
Updated patch (2.52 KB, patch)
2002-10-17 06:40 PDT, dcone (gone)
rods: review+
kinmoz: superreview+
Details | Diff | Splinter Review

Description Peter Thomassen 2002-10-08 04:00:43 PDT
Hi,

go to http://www.riemenschneider-gymnasium.de/, watch the Print Preview and look
what happens.
I think it's caused by the overflow property of one of the divs.

Peter
Comment 1 Olivier Cahagne 2002-10-08 05:28:43 PDT
please mention build ID, Talkback ID for this crash
(bin/mozilla/bin/components/talkback.exe) and attach reduced testcase (if possible).
Comment 2 Peter Thomassen 2002-10-08 05:31:51 PDT
Build ID: 2002091014
Talkback ID: TB12241606Y

Sorry, no time for a reduced testcase.
Comment 3 Tuomo Tikkanen 2002-10-08 06:55:47 PDT
I can confirm the same behaviour (crash) with:

Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827

Last few lines from "truss" output on that platform.

19334:  read(5, "\0\0\001\003\001\0\0\0\0".., 2688)     = 1232
19334:  read(5, "\0\0\0\0\0\0\0\0\0\0\0\0".., 1456)     = 1456
19334:      Incurred fault #6, FLTBOUNDS  %pc = 0xFF351A58
19334:        siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
19334:      Received signal #11, SIGSEGV [caught]
19334:        siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
19334:  sigprocmask(SIG_SETMASK, 0xFEAEEFF0, 0x00000000) = 0
19334:  unlink("/home/..../lock") = 0
19334:  _exit(11)
Comment 4 Peter 'vt100' Schwindt 2002-10-08 08:10:28 PDT
TB ID TB12252579K, Build ID 2002100804, Win2k SP2
Comment 5 greer 2002-10-08 08:44:25 PDT
Created attachment 102170 [details]
Stack from 12252579
Comment 6 Roland Mainz 2002-10-08 15:39:12 PDT
Tuomo Tikkanen wrote:
> I can confirm the same behaviour (crash) with:
> Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827
> Last few lines from "truss" output on that platform.

"truss" does not help much here - but using "/usr/proc/bin/pstack core" on the
resulting "core" file would deliver a detailed stack trace...
Comment 7 Olivier Cahagne 2002-10-08 16:49:14 PDT
not crashing using debug build 20020920 on Linux (trunk) but here're assertions
I get when loading/print previewing page:

###!!! ASSERTION: nsBlender::Blend() called with nsnull aSrc: 'aSrc', file
nsBlender.cpp, line 139
Break: at file nsBlender.cpp, line 139
###!!! ASSERTION: nsBlender::Blend() called with nsnull aDst: 'aDst', file
nsBlender.cpp, line 140
Break: at file nsBlender.cpp, line 140
WARNING: NS_ENSURE_TRUE(aSrc) failed, file nsBlender.cpp, line 141
WARNING: Blend failed!, file nsViewManager.cpp, line 1258
Comment 8 rods (gone) 2002-10-09 06:38:54 PDT
don, a fun one for you.
Comment 9 Roland Mainz 2002-10-09 15:14:34 PDT
Dumb question:
|NS_ENSURE_TRUE()| is working even in non-debug builds, right ?
Comment 10 dcone (gone) 2002-10-11 06:32:12 PDT
Created attachment 102574 [details] [diff] [review]
Checks for a valid bitmap before proceeding with the lock.

This will fix the crash, there is still and issue with support (or not
supporting) the blending code for print preview because the printers do not
support offscreen drawing surfaces.. this can cause a problem.	Printing does
not use this code path, but the print preview still does.
Comment 11 rods (gone) 2002-10-11 06:48:47 PDT
Comment on attachment 102574 [details] [diff] [review]
Checks for a valid bitmap before proceeding with the lock.

r=rods
Comment 12 Roland Mainz 2002-10-11 07:06:41 PDT
I thought I fixed this issue long ago.

The only possible issue may be that NS_ENSURE_TRUE() is a NO-OP in non-debug
builds... - can anyone confirm this ?
Comment 13 Roland Mainz 2002-10-11 07:17:11 PDT
The bug I was thinking of is bug 161364 ("Print preview crashes when page has
transparent content") - but it looks the macro is working even for non-debug
builds... weired...
Comment 14 kinmoz 2002-10-16 14:52:35 PDT
Comment on attachment 102574 [details] [diff] [review]
Checks for a valid bitmap before proceeding with the lock.

==== Should we be checking for valid |mDIBits| and |mBitmapInfo| pointers
before we use them after this call?

+	     mBitmapInfo = CreateBitmapInfo(mBitmap.bmWidth, mBitmap.bmHeight,
mBitmap.bmBitsPixel, (void **)&mDIBits);
Comment 15 dcone (gone) 2002-10-17 06:40:59 PDT
Created attachment 103179 [details] [diff] [review]
Updated patch

Checkin for success of CreateBitmapInfo()
Comment 16 rods (gone) 2002-10-17 09:59:10 PDT
Comment on attachment 103179 [details] [diff] [review]
Updated patch

r=rods
Comment 17 kinmoz 2002-10-17 14:08:29 PDT
Comment on attachment 103179 [details] [diff] [review]
Updated patch

sr=kin@netscape.com
Comment 18 Olivier Cahagne 2002-11-24 00:52:03 PST
patch ready to be checked in ?
Comment 19 dcone (gone) 2002-11-25 06:14:31 PST
Fixed

Note You need to log in before you can comment on or make changes to this bug.