78948 - Printing crashes with Linux RedHat 6.2 - M092 & N610 crash [@ libc.so.6 - nsPostScriptObj::begin_document]

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Jimmy Lee]

Build: 2001-05-03-08-trunk(LINUX)

1. From Sun workstation, rlogin to any Linux machine
2. Launch browser
3. Print anything

RESULT:
Crash.

EXPECTED RESULT:
Document prints.  Browser does not crash.

TalkBack Incident ID 30016591

Stack Trace
libc.so.6 + 0xa2574 (0x4026f574) 
libc.so.6 + 0x54dd4 (0x40221dd4) 
libc.so.6 + 0x54eb4 (0x40221eb4) 
libc.so.6 + 0x54970 (0x40221970) 
libc.so.6 + 0x5402e (0x4022102e) 
libc.so.6 + 0x557b7 (0x402227b7) 
libc.so.6 + 0x546b0 (0x402216b0) 
libc.so.6 + 0x44980 (0x40211980) 
libc.so.6 + 0x4c6f7 (0x402196f7) 
nsPostScriptObj::begin_document() 
nsPostScriptObj::Init() 
nsDeviceContextPS::BeginDocument() 
DocumentViewerImpl::SetupToPrintContent() 
DocumentViewerImpl::DocumentReadyForPrinting() 
DocumentViewerImpl::Print() 
GlobalWindowImpl::Print() 
WindowInternalPrint() 
js_Invoke() 
js_Interpret() 
js_Invoke() 
js_InternalInvoke() 
JS_CallFunctionValue() 
nsJSContext::CallEventHandler() 
nsJSEventListener::HandleEvent() 
nsEventListenerManager::HandleEventSubType() 
nsEventListenerManager::HandleEvent() 
nsXULElement::HandleDOMEvent() 
PresShell::HandleDOMEventWithTarget() 
nsMenuFrame::Execute() 
nsMenuFrame::HandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsView::HandleEvent() 
nsView::HandleEvent() 
nsView::HandleEvent() 
nsView::HandleEvent() 
nsViewManager::DispatchEvent() 
HandleEvent() 
nsWidget::DispatchEvent() 
nsWidget::DispatchWindowEvent() 
nsWidget::DispatchMouseEvent() 
nsWidget::OnButtonReleaseSignal() 
nsWindow::HandleGDKEvent() 
dispatch_superwin_event() 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x16ab2 (0x4066eab2) 
libglib-1.2.so.0 + 0xf2c6 (0x406982c6) 
libglib-1.2.so.0 + 0xf801 (0x40698801) 
libglib-1.2.so.0 + 0xf979 (0x40698979) 
libgtk-1.2.so.0 + 0x85f3a (0x405caf3a) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x17cb3 (0x401e4cb3)

Comment 1

[Jimmy Lee]

Adding keywords crash, pp.

Comment 2

[Jimmy Lee]

FYI...it seems that it does matter which Linux machine.  I reproduce the crash 
logging into dialupredhat (6.x) while I do not from pc629815 (7.0)

Comment 3

[Kevin McCluskey (gone)]

Taking this bug

Comment 4

[Kevin McCluskey (gone)]

Removing nsBranch keyword for now. This bug may have been fixed by a recent
checkin this afternoon which fixed a crash when printing to to a file that could
not be opened.

Sujay, could you try it with a current build? thanks.

Comment 5

[sujay]

Jimmy Lee is gonna try this again, as soon as he gets a linux box
he can rlogin to....

Comment 6

[sujay]

works for Jimmy Lee now.....and it has been working for sometime for him...

Comment 7

[sujay]

marking verified. Jimmy, reopen this one if it happens again for you..
thanks.

Comment 8

[Jimmy Lee]

Build: 2001-06-27-15-0.9.2(LINUX)

I lied to Sujay.  Dialupredhat is a dead machine.  But I can reproduce the crash 
rlogging into orb.  Be kind to orb if you check it out or Samir will kill me.  
Anyway, the stack is listed as shown.  I don't know if this is related to 
version, but 6.2 does seem to give me grief.

Marking Reopen!

Incident ID 32301135

Stack Trace

libc.so.6 + 0xa6af4 (0x404cfaf4) 
libc.so.6 + 0x567c4 (0x4047f7c4) 
libc.so.6 + 0x568a4 (0x4047f8a4) 
libc.so.6 + 0x56360 (0x4047f360) 
libc.so.6 + 0x55a1e (0x4047ea1e) 
libc.so.6 + 0x571a7 (0x404801a7) 
libc.so.6 + 0x560a0 (0x4047f0a0) 
libc.so.6 + 0x477cd (0x404707cd) 
libc.so.6 + 0x4e027 (0x40477027) 
nsPostScriptObj::begin_document() 
nsPostScriptObj::Init() 
nsDeviceContextPS::BeginDocument() 
DocumentViewerImpl::SetupToPrintContent() 
DocumentViewerImpl::DocumentReadyForPrinting() 
DocumentViewerImpl::Print() 
GlobalWindowImpl::Print() 
XPTC_InvokeByIndex() 
XPCWrappedNative::CallMethod() 
XPC_WN_CallMethod() 
js_Invoke() 
js_Interpret() 
js_Invoke() 
js_InternalInvoke() 
JS_CallFunctionValue() 
nsJSContext::CallEventHandler() 
nsJSEventListener::HandleEvent() 
nsEventListenerManager::HandleEventSubType() 
nsEventListenerManager::HandleEvent() 
nsXULElement::HandleDOMEvent() 
PresShell::HandleDOMEventWithTarget() 
nsButtonBoxFrame::MouseClicked() 
nsButtonBoxFrame::HandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEventWithTarget() 
nsEventStateManager::CheckForAndDispatchClick() 
nsEventStateManager::PostHandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsView::HandleEvent() 
nsViewManager::DispatchEvent() 
HandleEvent() 
nsWidget::DispatchEvent() 
nsWidget::DispatchWindowEvent() 
nsWidget::DispatchMouseEvent() 
nsWidget::OnButtonReleaseSignal() 
nsWindow::HandleGDKEvent() 
dispatch_superwin_event() 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x174db (0x403184db) 
libglib-1.2.so.0 + 0x10186 (0x40348186) 
libglib-1.2.so.0 + 0x10751 (0x40348751) 
libglib-1.2.so.0 + 0x108f1 (0x403488f1) 
libgtk-1.2.so.0 + 0x8c5b9 (0x4026c5b9) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x189cb (0x404419cb)

Comment 9

[Jay Patel [:jay]]

Not sure if this is exactly the same crash, but it's showing up inthe latest
M092 topcrash reports for Mozilla 0.9.2.  Here are some entries and a stack trace:

libc.so.6 + 0xbf264 (0x40550264) 6119baa3
         line 
        Build: 2001062823 CrashDate: 2001-07-02 UptimeMinutes: 1375  Total: 1375 
        OS: Linux 2.4.4-4GB
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32418630
         StackTrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32418630
     (32418630) URL: http://www.mapquest.com
     (32418630) Comments: Again

libc.so.6 + 0xbf264 (0x40543264) 5ce0fd30
         line 
        Build: 2001062823 CrashDate: 2001-07-01 UptimeMinutes: 12  Total: 12 
        OS: Linux 2.4.5
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32400831
         StackTrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32400831

libc.so.6 + 0xa6b14 (0x404d9b14) f6d39bb8
         line 
        Build: 2001062823 CrashDate: 2001-07-01 UptimeMinutes: 50  Total: 50 
        OS: Linux 2.2.14-5.0
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32396167
         StackTrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32396167

libc.so.6 + 0xd7584 (0x4058f584) 9fe8a0ac
         line 
        Build: 2001062823 CrashDate: 2001-07-01 UptimeMinutes: 0  Total: 174 
        OS: Linux 2.4.5
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32392497
         StackTrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32392497
     (32392497) URL: Tigerdirect.com
     (32392497) Comments: I was viewing a shopping cart at tigerdirect

Incident ID 32392497 
libc.so.6 + 0xd7584 (0x4058f584) 
libc.so.6 + 0x79ab3 (0x40531ab3) 
libc.so.6 + 0x79b48 (0x40531b48) 
libc.so.6 + 0x78c45 (0x40530c45) 
libc.so.6 + 0x79347 (0x40531347) 
libc.so.6 + 0x548ea (0x4050c8ea) 
libc.so.6 + 0x5e2f3 (0x405162f3) 
nsPostScriptObj::begin_document() 
nsPostScriptObj::Init() 
nsDeviceContextPS::BeginDocument() 
DocumentViewerImpl::SetupToPrintContent() 
DocumentViewerImpl::DocumentReadyForPrinting() 
DocumentViewerImpl::Print() 
GlobalWindowImpl::Print() 
XPTC_InvokeByIndex() 
XPCWrappedNative::CallMethod() 
XPC_WN_CallMethod() 
js_Invoke() 
js_Interpret() 
js_Invoke() 
js_InternalInvoke() 
JS_CallFunctionValue() 
nsJSContext::CallEventHandler() 
nsJSEventListener::HandleEvent() 
nsEventListenerManager::HandleEventSubType() 
nsEventListenerManager::HandleEvent() 
nsXULElement::HandleDOMEvent() 
PresShell::HandleDOMEventWithTarget() 
nsButtonBoxFrame::MouseClicked() 
nsButtonBoxFrame::HandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEventWithTarget() 
nsEventStateManager::CheckForAndDispatchClick() 
nsEventStateManager::PostHandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsView::HandleEvent() 
nsViewManager::DispatchEvent() 
HandleEvent() 
nsWidget::DispatchEvent() 
nsWidget::DispatchWindowEvent() 
nsWidget::DispatchMouseEvent() 
nsWidget::OnButtonReleaseSignal() 
nsWindow::HandleGDKEvent() 
dispatch_superwin_event() 
handle_gdk_event() 

Comment 10

[dcone (gone)]

Retry this bug with the latest build.. I think this is fixed.. and the version 
you tried my not have been in the branch when tested. Reopen if the lastes 9.2 
still crashes.

Comment 11

[sujay]

Jimmy, try again with latest branch build...it should work now.

thanks.

Comment 12

[Jimmy Lee]

Build: 2001-07-09-04-0.9.2(LINUX)

I still crash printing from Browser.  This time I logged into doodams.  You
should be able to easily reproduce this, Sujay.

Comment 13

[sujay]

REOPENING based on Jimmy Lee's comments...

Jimmy, I an trying to install Linux on my Sun home directory..
having problems doing that....maybe you can show me how...
I tried gunzipping and tar'ing the extractable...I freeze up.
any ideas?

Comment 14

[sujay]

adding install instructions per jimmylee:

% gzip -dc <filename>
% tar -xvf *.tar

Comment 15

[sujay]

crash if using 6.2 redhat.

6.1 is fine...see bug 90210

Comment 16

[sujay]

Updating summary

Comment 17

[sujay]

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

Comment 18

[sujay]

also see talkback ID = 32744223

Comment 19

[sujay]

updating summary

Comment 20

[sujay]

cc: lchiang, Lisa can put the necessary keywords in the status whiteboard.

Lisa, this affects RedHat Linux 6.2 users...6.1 users will
not crash after printing, but 6.2 users will crash.

Comment 21

[Jay Patel [:jay]]

Quick Talkback update: Almost all the crashes under the libc.so.6 stack 
signature for the latest N610 branch builds are of this kind.  Here are a couple 
of recent entries:

 libc.so.6 + 0xa6b14 (0x404cfb14) 612fae2e
         line 
        Build: 2001070904 CrashDate: 2001-07-10 UptimeMinutes: 1607  Total: 1607 
        OS: Linux 2.2.14-5.0
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32744454
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32744454
     (32744454) Comments: crashes on Linux (branch build: 2001-07-09-04-0.9.2)

    libc.so.6 + 0xa4df4 (0x404c2df4) 8732ed35
         line 
        Build: 2001071008 CrashDate: 2001-07-10 UptimeMinutes: 1  Total: 1 
        OS: Linux 2.2.12-20smp
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32744223
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32744223


I also found a few crashes in the MozillaTrunk data.  Here are a few 
of those entries:

libc.so.6 + 0xa6b14 (0x404d4b14) 22a424ea
         line 
        Build: 2001070508 CrashDate: 2001-07-05 UptimeMinutes: 1  Total: 1 
        OS: Linux 2.2.19
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32571318
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32571318
     (32571318) URL: www.foodtv.com
     (32571318) Comments: trying to print

libc.so.6 + 0xd7584 (0x40591584) 9a182046
         line 
        Build: 2001070308 CrashDate: 2001-07-04 UptimeMinutes: 21  Total: 474 
        OS: Linux 2.4.3-20mdk
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32518832
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32518832

Then there was this entry in the trunk data that looked related, but the stack 
was a bit different:

libc.so.6 + 0x3e51b (0x4048751b) c895562e
         line 
        Build: 2001070508 CrashDate: 2001-07-05 UptimeMinutes: 227  Total: 227 
        OS: Linux 2.2.19
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=32574983
         StackTrace: 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=32574983
     (32574983) Comments: unknown

Comment 22

[sujay]

internal 6.2 users = twalker, pmac, jimmylee
internal 6.1 users = jrgm, shrir

Comment 23

[lchiang]

sujay - what about RH 7.0?   does this bug happen only when rlogin to a Linux
machine from a remote machine?

dcone - any null pointer type of fix possible for this bug?  crashing each time
after printing is pretty bad if this is reproducible directly from Linux.

Comment 24

[sujay]

This bug has nothing to do with rlogin anymore...the bug
is reproducible directly from Linux RH 6.2

I can try 7.0, I need to find a box that has this...

Comment 25

[Jimmy Lee]

RH 7.0 does not crash for me.  I made this comment on 2001-06-05.

Comment 26

[lchiang]

ah!  This is reproducible all the time on Linux 6.2?

Comment 27

[sujay]

yes all the time on Linux RH 6.2...

Comment 28

[shrirang khanzode]

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

Comment 29

[selmer (gone)]

PDT+, is there any fix in sight?

Comment 30

[chris hofmann]

don, any additional ideas on what's going on with this one.
this is one of the one or two serious problems we need to 
fix before shipping n6.1.

Comment 31

[Syd Logan]

I have RH 6.2 up and running at home, but I can crash on RH 7.0 in a debug 
build as well after a few ugly asserts.

Comment 32

[Syd Logan]

Here's the console output:

JavaScript strict warning: 
chrome://global/content/printdialog.js line 148: assignment to undeclared
variable inx

/content/printdialog.xul
nsWidget::~nsWidget() of toplevel: 25 widgets still exist.
WEBSHELL- = 5
###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2133
###!!! Break: at file nsFrame.cpp, line 2133
###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2133
###!!! Break: at file nsFrame.cpp, line 2133
###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2133
###!!! Break: at file nsFrame.cpp, line 2133
Enabling Quirk StyleSheet
###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2133
###!!! Break: at file nsFrame.cpp, line 2133
###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2133
###!!! Break: at file nsFrame.cpp, line 2133
###!!! ASSERTION: no window in frame tree: 'nsnull != window', file nsFrame.cpp,
line 2133
###!!! Break: at file nsFrame.cpp, line 2133
Enabling Quirk StyleSheet

PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
top 0.500000 bottom 0.500000 left 0.500000 right 0.500000

PreWidth = 8.500000 PreHeight = 11.000000

Width = 612 Height = 792
dpi 72.000000 top 36 bottom 36 left 36 right 36
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(NS_OpenURI(getter_AddRefs(in),
uri))) failed: '(!((NS_OpenURI(getter_AddRefs(in), uri)) & 0x80000000))', file
nsPostScriptObj.cpp, line 1598
###!!! Break: at file nsPostScriptObj.cpp, line 1598
/opt/raptor/branch/ns/dist/bin/run-mozilla.sh: line 72: 18379 Segmentation
fault      $prog ${1+"$@"}

Comment 33

[Syd Logan]

A stack from gdb

(gdb) where
#0  0x401a63b9 in dosprintf (ss=0xbfffec60, fmt=0x8a8ef80, ap=0x31eccc)
    at nsTextFormatter.cpp:1013
#1  0x401a6ca7 in nsTextFormatter::vsmprintf (fmt=0x8a8ef68, ap=0xbfffecc4)
    at nsTextFormatter.cpp:1289
#2  0x401a6c1f in nsTextFormatter::smprintf (fmt=0x8a8ef68)
    at nsTextFormatter.cpp:1267
#3  0x41d10387 in nsPageFrame::Paint (this=0x8b5904c, aPresContext=0x8a71350, 
    aRenderingContext=@0x81b5088, aDirtyRect=@0xbffff050, 
    aWhichLayer=eFramePaintLayer_Overlay) at nsPageFrame.cpp:432
#4  0x41d212db in PresShell::Paint (this=0x8aa6bb0, aView=0x81a6b60, 
    aRenderingContext=@0x81b5088, aDirtyRect=@0xbffff050)
    at nsPresShell.cpp:5301
#5  0x41f3aa7f in nsView::Paint (this=0x81a6b60, rc=@0x81b5088, 
    rect=@0xbffff050, aPaintFlags=128, aResult=@0xbffff068) at nsView.cpp:273
#6  0x41f458f6 in nsViewManager::RenderDisplayListElement (this=0x8a9c208, 
    element=0x8aa34e8, aRC=@0x81b5088) at nsViewManager.cpp:1437
#7  0x41f45635 in nsViewManager::RenderViews (this=0x8a9c208, 
    aRootView=0x81a6b60, aRC=@0x81b5088, aRect=@0xbffff190, 
    aResult=@0xbffff18c) at nsViewManager.cpp:1361
#8  0x41f4982b in nsViewManager::Display (this=0x8a9c208, aView=0x81a6b60, 
    aX=720, aY=720) at nsViewManager.cpp:3017
#9  0x41d29ac4 in nsSimplePageSequenceFrame::PrintNextPage (this=0x8b58ef4, 
    aPresContext=0x8a71350, aPrintOptions=0x8833720)
    at nsSimplePageSequence.cpp:745
#10 0x412b5e41 in DocumentViewerImpl::PrintPage (this=0x87c6480, 
    aPresContext=0x8a71350, aPrintOptions=0x8833720, aPO=0x89b1f00)
    at nsDocumentViewer.cpp:2221
#11 0x413ff9a5 in nsPagePrintTimer::Notify (this=0x8a3f298, timer=0x8a8f068)
    at nsDocumentViewer.cpp:614
#12 0x4184077c in nsTimerGtk::FireTimeout (this=0x8a8f068)
    at nsTimerGtk.cpp:186
#13 0x418409be in process_timers (array=0x8418de8) at nsTimerGtk.cpp:256
#14 0x41840a9e in TimerCallbackFunc (data=0x0) at nsTimerGtk.cpp:278
#15 0x40473983 in g_timeout_dispatch () from /usr/lib/libglib-1.2.so.0
#16 0x40472987 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#17 0x40473001 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#18 0x404731cc in g_main_run () from /usr/lib/libglib-1.2.so.0
#19 0x40389e57 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#20 0x40c9df29 in nsAppShell::Run (this=0x81154f0) at nsAppShell.cpp:360
#21 0x40943d2b in nsAppShellService::Run (this=0x8126bc0)
    at nsAppShellService.cpp:431
#22 0x0805a94d in main1 (argc=1, argv=0xbffff864, nativeApp=0x0)
    at nsAppRunner.cpp:1235
#23 0x0805b623 in main (argc=1, argv=0xbffff864) at nsAppRunner.cpp:1539
#24 0x405b0b65 in __libc_start_main (main=0x805b424 <main>, argc=1, 
    ubp_av=0xbffff864, init=0x8053a20 <_init>, fini=0x80665a8 <_fini>, 
    rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffff85c)
    at ../sysdeps/generic/libc-start.c:111
(gdb) 

Comment 34

[Syd Logan]

These are the args being passed to smprintf:

432             valStr = nsTextFormatter::smprintf(mPageNumFormat, mPageNum,
mTotNumPages);

(gdb) print mPageNum
$4 = 1
(gdb) print mTotNumPages
$5 = 3
(gdb) print mPageNumFormat
$6 = (PRUnichar *) 0x8a8ef68
(gdb) x/30c 0x8a8ef68
0x8a8ef68:      37 '%'  0 '\000'        49 '1'  0 '\000'        36 '$'  0
'\000'100 'd' 0 '\000'
0x8a8ef70:      32 ' '  0 '\000'        111 'o' 0 '\000'        102 'f' 0
'\000'32 ' '  0 '\000'
0x8a8ef78:      37 '%'  0 '\000'        50 '2'  0 '\000'        36 '$'  0
'\000'100 'd' 0 '\000'
0x8a8ef80:      0 '\000'        0 '\000'        115 's' 0 '\000'        1
'\001'0 '\000'

== "%1$d of %2$d"

Which looks normal.

Comment 35

[Syd Logan]

Ok, seems like someone renamed the properties file from
resource:/res/unixpsfonts.properties to
resource:/res/sample.unixpsfonts.properties" but failed to change the source
code. Explains all the JS exception errors. Patch attached.

Comment 36

[Syd Logan]

Attachment: Patcfh to address JS exception failures

Comment 37

[Syd Logan]

Ok, so, although I suspect the above patch is critical, we still crash even with
it. I looked around in nsTextFormatter::dosprintf, the "ap" argument seems to be
bogus, my crash happens when it tries to call va_arg with it on line 1013:

1012                  case TYPE_INTN:
1013                    u.l = va_arg(ap, int);

Now, the arguments coming in all seem to point to valid memory. This implies
that sprintf is either being given too few arguments for the specified format
string, or the format string is bogus. Could be something else, but those are my
best guesses. As I said above, the format string "%1$d of %2$d" is being passed
in. Perhaps we can verify this is the correct format string (could it be "%d of
%d" that we want instead) and that the number of arguments being passed is ok?

Comment 38

[Syd Logan]

If I comment out the code that prints page numbers, I don't crash, and can
print. Hardly the right fix, but ought to be enough of a clue (for what is
crashing *me* at least). Adding a patch to show what I commented out.

Comment 39

[Syd Logan]

Attachment: patch that works around the problem

Comment 40

[Syd Logan]

Attachment: patch that works around the problem

Comment 41

[Syd Logan]

Don and I undid the last patch, kept the first, and came up with a resonable 
patch that gets around it. I'm going to put up binaries for someone to test on 
6.2, check here for URLS.

Comment 42

[Syd Logan]

Please test the following on RH 6.2

This one should print without crashing:

http://jazz.netscape.com/Users/syd/publish/good.tar.gz

This one should crash:

http://jazz.netscape.com/Users/syd/publish/bad.tar.gz

And let us know what you find.

Comment 43

[Syd Logan]

By the way, the above are debug builds, they will be slower, and they will spit
stuff out to the console and beep at you occasionally. That is to be expected.

Comment 44

[sujay]

testing right now...will post results....

Comment 45

[sujay]

Syd, how did you build this good.tar.gz file ? when I launch
mozilla-bin, I get Command not found

Also seems like we have symbolic links here:

/u/sujay/LINUX/dist/bin=> ls -al mo*
lrwxrwxrwx    1 sujay    wheel          47 Jul 23 09:21 mozilla-bin ->
/opt/raptor/branch/mozilla/dist/bin/mozilla-bin
lrwxrwxrwx    1 sujay    wheel          50 Jul 23 09:21 mozilla-config ->
/opt/raptor/branch/mozilla/dist/bin/mozilla-config
lrwxrwxrwx    1 sujay    wheel          57 Jul 23 09:21 mozilla-installer-bin ->
/opt/raptor/branch/mozilla/dist/bin/mozilla-installer-bin
lrwxrwxrwx    1 sujay    wheel          53 Jul 23 09:21 mozilla-viewer.sh ->
/opt/raptor/branch/mozilla/dist/bin/mozilla-viewer.sh
-rw-r--r--    1 sujay    wheel      888832 Jul 23 04:50 mozilla.ps
/u/sujay/LINUX/dist/bin=> ./mozilla-bin
./mozilla-bin: Command not found.
/u/sujay/LINUX/dist/bin=> ./mozilla-bin
./mozilla-bin: Command not found.

Comment 46

[Syd Logan]

sorry, forgot a flag when creating the tar files, I'll post ones that work in a 
moment

Comment 47

[selmer (gone)]

Syd!  Awesome!

Comment 48

[Syd Logan]

ETA on a build is 1 pm -- sorry, things didn't go well when I tried to strip 
symbols, and need to rebuild as a result.

Comment 49

[sujay]

we tried all morning/afternoon to get a binary working. didn't work.

Syd went home to build a binary on his RH 6.2 system.

Comment 50

[selmer (gone)]

Any progress?  Do we have something to check in tonite?

Comment 51

[Syd Logan]

No.

I spent the evening building on RH 6.2. While the patch I have clearly addressed 
what appears to be an error in the sprintf code, it is not "the fix" to the 
problem, just demonstrates (to me) that there is a problem. And I couldn't 
dup on RH 6.2 but so is the way of subtle memory overwrite errors. So, I'm going 
to push another binary up onto my ftp site for sujay to play with (this time 
build on RH 6.2 so he should have no problems running it). And we will see what 
happens. If it fixes him, then we should look at how the sprintf code is 
converting the %d %d to a %$1d %$2d and undo that since it appears later code 
has a problem parsing it. 

Comment 52

[Syd Logan]

Sujay, a Red Hat 6.2 build is available as good.tar.gz (see the earlier links). 
I tested on h-208-12-39-167 by printing to a file and it did not crash, so 
further substantiates I am on the right track. 

Going to see what is the best patch i can get into the branch by 3 am...

Comment 53

[Syd Logan]

Attachment: Patch to _fix_ the problem

Comment 54

[Syd Logan]

Fix is to use a format string that doesn't break us, and also need to point to
correct unixpsfonts.properties file.

Comment 55

[Stuart Parmenter]

r=pavlov

Comment 56

[Syd Logan]

Fix checked into branch. Need sr= for trunk. Will wait for verification of fix
on branch first, however.

Comment 57

[Syd Logan]

Sujay, it is better to just run the branch build. I removed the tar.gz file from
the ftp site since we want to actually verify the branch at this point. Please
annotate here when and if you verify. If it fails to verify for some reason,
please find me and let me know.

Comment 58

[dcone (gone)]

I looked at the patch.. this seems like it will fix all the areas in the 
nsPageFrame that use the format strings.  I can get this into the trunk if you 
want also Syd.. its up to you.  This will fix the 7.0 problems also, that have 
the different stack trace.

Comment 59

[sujay]

Just installed 7/24 branch build on linux.

we still crash when print to a printer.

I tried on a couple RH 6.2 systems(Jimmy Lee's and Chris Kritzer's)

Printing to a file works though.

Comment 60

[sujay]

talkback incident ID = 33281749 for the last crash using 7/24 build.

Comment 61

[Blake Ross]

Why does "%1$d" break us?  This is the localizable-friendly way of doing string
substitution.  It allows localizers to choose the order in which the substited
strings will go.  I admit in this case that I don't know where the two numbers
would have to be switched.  cc'ing msanz for comment.

Comment 62

[dcone (gone)]

I think its a bug.  On 7.0 this crashes us.. because I know its a supported way 
of using the format string,  but there seems to be a linux bug that crashes.. at 
least on 7.0 it does.  It seems to go past the memory that is allocated.  

Comment 63

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It wouldn't work if you send that format string straight to fprintf.  Is that
what we were doing?

Comment 64

[selmer (gone)]

So, 7.0 doesn't crash at all anymore and 6.2 can print to file as a workaround?
 That might be enough for us to declare today's build the winner.  I'd still
look at an updated patch if I got it in the next hour or two.

Comment 65

[sujay]

just to clarify: RH 7.0 AND 6.1 do not crash.

6.2 crashes only when printing to a printer; printing to a file works.

Comment 66

[Syd Logan]

Sujay, just to verify, you tested against *branch* builds, not the trunk, right?
I did not check this patch into the trunk. 

Blake, it appeared *our* sprintf code was having problems dealing with the
"%$1d" etc. format. I understand how it is "better" for i18n, but it was clearly
crashing down in the sprintf code, walking off the end of the argument array
unless I changed that format to a more typical one. 

So, need to make sure we only tested on the branch builds. I appear to have
addressed one issue, if it is tubing for you sujay on the branch, then we simply
may have other issues still to go.

Comment 67

[sujay]

yes, 7/24 branch build on linux.

Comment 68

[Eric Pollmann]

The string %1$d also appears all over /security/psm/ui/psm_ui.properties.in, but
that file is processed by a perl script - does the resulting .properties file
have %1$d in it?  Are we seeing crashes there on Linux 6.2 due to this?

There is also one more occurance that could be hit at runtime:
http://lxr.mozilla.org/seamonkey/source/security/psm/server/certres.c#2680

Comment 69

[Eric Pollmann]

Please ignore my last post, /security/psm is not part of PSM2 and should
therefore not be part of the build.  I could not find %1$d anywhere in the
mozilla or commercial source base except in this .properties file and in one
place in nsTextFormatter in a #ifdef DEBUG.

Comment 70

[sujay]

I have added this bug to the release notes tracking bug 90577

Comment 71

[sujay]

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

Comment 72

[ckritzer (gone)]

I think I found a work-around...
/***************************************************************************/
In the Print dialog (CTL+P), if you enter the following text, you can print
without crashing:

lpr -P lp0

where 'lp0' = the name of your default printer
/***************************************************************************/

To check the name of your default printer, open a terminal window, login as
root, type 'printtool' and hit enter at the command line, then check the name of
the default printer (in RH6.2, it's the item on the far left of the [first?]
line, visually situated more or less under the 'PrintTool' menu).

Many thanks to Syd for his explainations of lpd & lpr, which prompted me to ask
'stupid questions' which led to this workaround.

Comment 73

[selmer (gone)]

Can one of you ensure this gets into the release notes?  Thanks!

Comment 74

[Karen Huang]

please note: bug 92344 crash is different as this bug......

Comment 75

[Syd Logan]

Please ignore selmer's comments :-)

Not at all clear this is a workaround. We could just have a new bug here, "Unix 
printing crashes if "lp" printer is not configured.

Let me explain again, looks like we have one of two cases here:

1) Sujay can print to a file, but not the printer. Perhaps he has his printer 
configured wrong (which explains why the print to file works), and so the bug is 
that the print code is not handling the error from lpr correctly, and perhaps we 
do have a workaround, and we a very good place to start looking for a 
(probably easy) fix.

2) Sujay has his printer configured correctly, and is crashing, and if that is 
the case, this problem with crashing on a misconfigured system is a new bug.

Sujay, can you print from 4.x on this system?

Sujay, if you run the following command from a prompt:

$ cat /etc/passwd | lpr

what happens?

If you can print from 4.x to the printer and/or the above command works, then 
your crash is probably due to some unknown error. If you can't print, configure 
your system and/or try the lp0 suggestion and see if it works.

I never did crash on my RH 6.2 system, but then again my printer is configured 
correctly.

Comment 76

[Syd Logan]

Of course, we should release note that printing won't work if your printer does 
not support the printer "lp". In fact, here is what I would say:

"You may experience a crash on RedHat linux systems if you try to print to a 
printer, but do not have a printer named lp configured. There are two ways to 
work around this. You can either configure the printer named lp (which is by 
default the printer name assigned on Redhat Linux, or you can use another 
printer e.g., lp0 by changing the print command in the print dialog so that it 
reads lpr -P lp0. To see a list of configured printers, log in as root and use 
the following command: 'lpc status' to see the list of printers. Alternately, 
you can use the RedHat 'printtool' application to graphically view and configure 
printers on your system."

Comment 77

[Syd Logan]

Yuck, let me try again:

"You may experience print failures, or a crash on RedHat linux if you try to 
print to a printer, but do not have a printer named lp configured. There are two 
ways to work around this. 

1) Configure the printer named lp (which is by default the printer name assigned 
on Redhat Linux).

2) Use a printer that is configured, e.g., lp0, by changing the print command in 
the print dialog so that it reads lpr -P lp0 (replace lp0 with the name of your 
printer). 

To see the list of configured printers, you can log in as root and use the 
following command: 'lpc status'. Alternately, you can use the RedHat 'printtool' 
application to graphically view and configure the printers on your system."

Comment 78

[sujay]

This bug has taken an interesting detour.

Up until yesterday every 6.2 I was using to print was crashing. Then I 
went upstairs to the Mail QA team, and Laurel's 6.2 system "did not" crash.
and Karen's 6.1 system "did" crash. So after reading Syd and Kritzer's
comments, Laurel has a properly configured system and Karen does not.

I will release note Syd's last comments. 

Bug 92344 has been filed for Unix printing crashes if "lp" printer is not
configured.

Also Syd, from the two cases you mentioned, number 1 is correct. looks
like me and Jimmy Lee were printing from an incorrectly configured system.

Comment 79

[sujay]

marking this bug RESOLVED-WORKSFORME cause any system, regardless of OS, 
that is properly configured to "lp" will print fine. There is a new
bug filed 92344 on the crashing behavior when lp is not defined. 
And the workaround is documented in the relase notes bug 90577.

Comment 80

[sujay]

verified in 7/25 build

Comment 81

[dcone (gone)]

Syd.. did you check in this patch to the Trunk.. I think it should be if you did 
not.. keep RH 7.0 from crashing

Comment 82

[dcone (gone)]

I just want to re-open this bug until I know if we put this patch on the 
branch... I think its important to keep 7.0 from crashing..or resolve what to do 
with this format string issue.

Comment 83

[Shiva Thirumazhusai]

Is somebody working on this ?

Comment 84

[Syd Logan]

The patch only applies to the branch, is not on the trunk, and there is no
evidence it is needed on the trunk. So closing this bug. 

Comment 85

[Blake Ross]

Why is this only needed on the branch?  Would it hurt to put it on the trunk? 
greer/jpatel, can you confirm that this crash is not happening on the trunk?

Comment 86

[Jay Patel [:jay]]

Yes, this is still happening with MozillaTrunk builds.  I have recently updated
bug 92344 with Talkback data, but I'm not sure if that is a dup of this crash. 
Can QA (Sujay) take a look and see if they are both the same crash and dup it if
necessary?

Comment 87

[sujay]

crash is happening on the trunk, but that is covered in bug 92344.

we can close out this one.

verified.