193081 - Mozilla locks up when percent complete hits 100% when printing via Xprint

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, defect, P1)

Description

[Coy Krill]

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

When printing to an Xprint 008 printer, the print progress bar reaches 100%, the
window unhighlights and Mozilla 1.3b locks up until killed. The printout comes
out find and Xprint is still running fine.

Reproducible: Always

Steps to Reproduce:
1. go to a page
2. print to an Xprint served printer
3. once printing is complete, it locks

Actual Results:  
Mozilla required a kill.

Expected Results:  
Continued to let me browse

Comment 1

[Roland Mainz]

1. Where did you download the Mozilla binary from (URL) ?
2. Can we get a stacktrace from the hung mozilla (details how to use gdb/dbx on
demand) ?
3. Starting Mozilla like this:
  % export NSPR_LOG_MODULES=nsXPrintContext:5
  % ./mozilla
  Is there any output when printing with Mozilla's Xprint module ? If "yes" -
can you paste it here or attach the log as plain text, please ?

Comment 2

[Coy Krill]

Attachment: nsXprint module log as requested

Comment 3

[Coy Krill]

Attachment: gdb backtrace of hung mozilla session

Comment 4

[Coy Krill]

I got the mozilla 1.3b rpms from 
ftp://ftp.suse.com/pub/projects/mozilla/experimental/1.3b and I'm running on 
Suse 8.1 with all packages updated and current. 

Comment 5

[Roland Mainz]

Comment on attachment 114572 [details]
gdb backtrace of hung mozilla session

Looking at the stack trace...
-- snip --
#8  0x400e312b in pthread_sighandler () from /lib/libpthread.so.0
#9  <signal handler called>
#10 0x4049d6b2 in chunk_free () from /lib/libc.so.6
#11 0x4049d5f6 in free () from /lib/libc.so.6
#12 0x4184b078 in nsMsgFolder::kLocalizedTrashName ()
-- snip --
... this smells like a memory allocation/deallocation issue... ;-(

Comment 6

[Roland Mainz]

Just tested the Xlib port Mozilla (the Xlib port toolkit shares lots of code
with the Xprint module)
% (LD_PRELOAD=libmapmalloc.so ./mozilla-viewer.sh -g -d dbx)
crashes like this:
-- snip --
t@1 (l@1) signal BUS (invalid address alignment) in defrag at 0xff370f44
0xff370f44: defrag+0x007c:      ld      [%o1 + 0x8], %o3
Current function is nsFontMetricsXlibContext::~nsFontMetricsXlibContext
 1033       free((void *)mCharSetMap);
(dbx) where
current thread: t@1
  [1] defrag(0xfdc9e338, 0xa, 0xfd8c5cc8, 0xfdc9e339, 0xff381098, 0xff381098),
at 0xff370f44
  [2] free(0xfd8c3030, 0xff381268, 0x0, 0xff3e4270, 0xfcc118f3, 0x8c), at
0xff370e34
=>[3] nsFontMetricsXlibContext::~nsFontMetricsXlibContext(this = 0xfcd31d50),
line 1033 in "nsFontMetricsXlib.cpp"
  [4] DeleteFontMetricsXlibContext(aFontMetricsXlibContext = 0xfcd31d50), line
1066 in "nsFontMetricsXlib.cpp"
  [5] nsDeviceContextXlib::~nsDeviceContextXlib(this = 0xf9e833b8), line 117 in
"nsDeviceContextXlib.cpp"
  [6] __SLIP.DELETER__C(0xf9e833b8, 0x1, 0xff1652a0, 0x3, 0xff33ca24,
0xff3c5af0), at 0xfcc370f0
  [7] DeviceContextImpl::Release(this = 0xf9e833b8), line 38 in
"nsDeviceContext.cpp"
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-02-07-08-trunk/objdir_ws7_xlib/xpcom/build/nsCOMPtr.o"
dbx: warning: see `help finding-files'
  [8] nsCOMPtr_base::assign_assuming_AddRef(0xfcdf1420, 0x0, 0x0, 0xff3e4270,
0xff33ca24, 0xff3c5af0), at 0xff015700
  [9] nsCOMPtr_base::assign_with_AddRef(0xfcdf1420, 0x0, 0x1, 0xff3e4270,
0xfc786fca, 0x116), at 0xff015524
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-02-07-08-trunk/objdir_ws7_xlib/docshell/build/nsWebShell.o"
  [10] nsCOMPtr<nsIDeviceContext>::operator=(0xfcdf1420, 0x0, 0x1, 0xff3e4270,
0xfc886dac, 0x6b), at 0xfc803360
  [11] nsWebShell::~nsWebShell(0xfcdf1388, 0x0, 0x132, 0x546e7344, 0x31634473,
0x3163546e), at 0xfc7f6dac
  [12] __SLIP.DELETER__D(0xfcdf1388, 0x1, 0xfc847329, 0x1, 0x5f765f00,
0x5f765f00), at 0xfc80bf70
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-02-07-08-trunk/objdir_ws7_xlib/docshell/build/nsDocShell.o"
  [13] nsDocShell::Release(0xfcdf1388, 0x0, 0xb49c0, 0x0, 0xff3e4270, 0x0), at
0xfc79c634
  [14] nsWebShell::Release(0xfcdf1388, 0xfcdf13a4, 0x0, 0xff3e4270, 0xff33ca24,
0xff3c5af0), at 0xfc7f7494
  [15] nsCOMPtr_base::assign_assuming_AddRef(0xfcdf0d60, 0x0, 0x0, 0xff3e4270,
0xfc88623c, 0x67), at 0xff015700
  [16] nsCOMPtr_base::assign_with_AddRef(0xfcdf0d60, 0x0, 0xff3e3cec, 0x0,
0xff3e4270, 0x0), at 0xff015524
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-02-07-08-trunk/objdir_ws7_xlib/embedding/browser/build/nsWebBrowser.o"
  [17] nsCOMPtr<nsITextScroll>::operator=(0xfcdf0d60, 0x0, 0x3, 0xff3e4270,
0xff33ca24, 0xff3c5af0), at 0xfc8bf6c0
  [18] nsWebBrowser::SetDocShell(0xfcdf0d08, 0x0, 0x1, 0xff3e4270, 0xfc886dac,
0x6b), at 0xfc8bc434
  [19] nsWebBrowser::InternalDestroy(0xfcdf0d08, 0xfcd30740, 0x0, 0x0, 0x0,
0x0), at 0xfc8b2608
  [20] nsWebBrowser::~nsWebBrowser(0xfcdf0d08, 0x0, 0x0, 0x21fe8, 0x20000,
0xff3812b0), at 0xfc8b227c
  [21] __SLIP.DELETER__B(0xfcdf0d08, 0x1, 0xfc8f422e, 0x21fe8, 0x20000,
0xff3812b0), at 0xfc8c45e8
  [22] nsWebBrowser::Release(0xfcdf0d08, 0xfcdf0d08, 0xff324570, 0xfed50a48,
0x0, 0x0), at 0xfc8b29f0
  [23] nsCOMPtr_base::~nsCOMPtr_base(0xfcd3065c, 0x1, 0x9fbe3, 0xffbeec6c, 0x0,
0x0), at 0xff015494
  [24] nsCOMPtr<nsIWebBrowser>::~nsCOMPtr(0xfcd3065c, 0x1, 0x0, 0x0, 0x0, 0x0),
at 0x4de74
  [25] nsBrowserWindow::~nsBrowserWindow(this = 0xfcd30620), line 1353 in
"nsBrowserWindow.cpp"
  [26] nsNativeBrowserWindow::~nsNativeBrowserWindow(this = 0xfcd30620), line 63
in "nsXlibMain.cpp"
  [27] __SLIP.DELETER__A(0xfcd30620, 0x1, 0x9a0be, 0x0, 0x0, 0x0), at 0x867e8
  [28] nsBrowserWindow::Release(this = 0xfcd30620), line 1357 in
"nsBrowserWindow.cpp"
  [29] nsViewerApp::CloseWindow(this = 0xfe8298d0, aBrowserWindow = 0xfcd30620),
line 706 in "nsViewerApp.cpp"
  [30] HandleBrowserEvent(aEvent = 0xffbef0a0), line 605 in
"nsBrowserWindow.cpp"
  [31] nsWidget::DispatchEvent(this = 0xfcd307e0, aEvent = 0xffbef0a0, aStatus =
nsEventStatus_eIgnore), line 1234 in "nsWidget.cpp"
  [32] nsWidget::DispatchWindowEvent(this = 0xfcd307e0, aEvent = STRUCT), line
1141 in "nsWidget.cpp"
  [33] nsWidget::DispatchDestroyEvent(this = 0xfcd307e0), line 1075 in
"nsWidget.cpp"
  [34] nsWidget::OnDeleteWindow(this = 0xfcd307e0), line 1060 in "nsWidget.cpp"
  [35] nsAppShell::HandleClientMessageEvent(event = 0xffbef27c, aWidget =
0xfcd307e0), line 1160 in "nsAppShell.cpp"
  [36] nsAppShell::DispatchXEvent(event = 0xffbef27c), line 597 in
"nsAppShell.cpp"
  [37] nsAppShell::Run(this = 0xfd85bc40), line 363 in "nsAppShell.cpp"
  [38] nsNativeViewerApp::Run(this = 0xfe8298d0), line 53 in "nsXlibMain.cpp"
  [39] main(argc = 1, argv = 0xffbef41c), line 101 in "nsXlibMain.cpp"
-- snip --

Comment 7

[Roland Mainz]

Taking...

Comment 8

[Roland Mainz]

Attachment: Patch for 2003-02-07-08-trunk

Todays lesson:
Getting memory from |malloc()|, aligning that pointer (not neccesary since it
is already aligned) and passing that twice-aligned pointer to |free()| is a BAD
idea (heap corruption).

Comment 9

[Roland Mainz]

Comment on attachment 114618 [details] [diff] [review]
Patch for 2003-02-07-08-trunk

Requesting r= ...

Comment 10

[Roland Mainz]

Attachment: New patch for 2003-02-07-08-trunk per jkeisers IRC comments

Comment 11

[Roland Mainz]

Comment on attachment 114622 [details] [diff] [review]
New patch for 2003-02-07-08-trunk per jkeisers IRC comments

Requesting sr= (while waiting for jkeiser to place his stamp... :) ...

Comment 12

[John Keiser (jkeiser)]

Comment on attachment 114622 [details] [diff] [review]
New patch for 2003-02-07-08-trunk per jkeisers IRC comments

All right, good enough for this, but please try and use the language facilities
for allocation and alignment in the future, not only does this cause code
bloat, it causes data bloat on platforms that have less alignment foo.

Comment 13

[Roland Mainz]

Asking for 1.3final blocker status - PostScript module is already busted for
some users and shipping with both Unix/Linux print modules defunct is not a good
idea...

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll probably approve this once you have superreview.

Comment 15

[Roland Mainz]

Robert O'Callahan wrote:
> I'll probably approve this once you have superreview.

You could sr= it if you want, too... :)

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 114622 [details] [diff] [review]
New patch for 2003-02-07-08-trunk per jkeisers IRC comments

good point

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Plus'ing because no risk for most users, high return for xlib users

Comment 18

[Roland Mainz]

Comment on attachment 114622 [details] [diff] [review]
New patch for 2003-02-07-08-trunk per jkeisers IRC comments

Requesting a= for mozilla1.3final ...

Comment 19

[Brendan Eich [:brendan]]

Roland, please get this checked in ASAP for 1.3final.  Thanks,

/be

Comment 20

[Roland Mainz]

Patch checked-in
(http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1045526040&maxdate=1045527060&who=smontagu%25netscape.com),
marking bug as FIXED...

Comment 21

[Roland Mainz]

Another lesson... something I forgot to use a while ago - now re-discoverted:
Patches on Solaris can be tested for their correctness about memory allocations
via replacing the libc default memory allocator with Solaris's mmap() allocator
- any double/mismatched/illegal free() will immediately end in SIGSEGV:
% (LD_PRELOAD=libmapmalloc.so ./mozilla)

Comment 22

[Roland Mainz]

*** Bug 194728 has been marked as a duplicate of this bug. ***