Closed
Bug 173234
Opened 22 years ago
Closed 22 years ago
Mozilla crashes [@ GDI32.DLL][@ nsDrawingSurfaceWin::Lock]
Categories
(Core :: Print Preview, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.2beta
People
(Reporter: Peter.Thomassen, Assigned: dcone)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(2 files, 1 obsolete file)
2.26 KB,
text/plain
|
Details | |
2.52 KB,
patch
|
rods
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
please mention build ID, Talkback ID for this crash (bin/mozilla/bin/components/talkback.exe) and attach reduced testcase (if possible).
Keywords: crash,
stackwanted
Reporter | ||
Comment 2•22 years ago
|
||
Build ID: 2002091014 Talkback ID: TB12241606Y Sorry, no time for a reduced testcase.
Comment 3•22 years ago
|
||
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•22 years ago
|
||
TB ID TB12252579K, Build ID 2002100804, Win2k SP2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•22 years ago
|
Whiteboard: TB12241606Y
Keywords: stackwanted
Summary: Mozilla crashes → Mozilla crashes [@ GDI32.DLL][@ nsDrawingSurfaceWin::Lock]
Whiteboard: TB12241606Y
Comment 6•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
don, a fun one for you.
Assignee: rods → dcone
Priority: -- → P1
Target Milestone: --- → mozilla1.2beta
Comment 9•22 years ago
|
||
Dumb question: |NS_ENSURE_TRUE()| is working even in non-debug builds, right ?
Assignee | ||
Comment 10•22 years ago
|
||
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•22 years ago
|
||
Comment on attachment 102574 [details] [diff] [review] Checks for a valid bitmap before proceeding with the lock. r=rods
Comment 12•22 years ago
|
||
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•22 years ago
|
||
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...
Assignee | ||
Updated•22 years ago
|
Attachment #102574 -
Flags: review+
Comment 14•22 years ago
|
||
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);
Assignee | ||
Comment 15•22 years ago
|
||
Checkin for success of CreateBitmapInfo()
Assignee | ||
Updated•22 years ago
|
Attachment #102574 -
Attachment is obsolete: true
Comment 16•22 years ago
|
||
Comment on attachment 103179 [details] [diff] [review] Updated patch r=rods
Attachment #103179 -
Flags: review+
Comment 17•22 years ago
|
||
Comment on attachment 103179 [details] [diff] [review] Updated patch sr=kin@netscape.com
Attachment #103179 -
Flags: superreview+
Comment 18•22 years ago
|
||
patch ready to be checked in ?
Assignee | ||
Comment 19•22 years ago
|
||
Fixed
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Crash Signature: [@ GDI32.DLL]
[@ nsDrawingSurfaceWin::Lock]
You need to log in
before you can comment on or make changes to this bug.
Description
•