If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash on "Print To File"

VERIFIED WORKSFORME

Status

()

Core
Printing: Output
--
critical
VERIFIED WORKSFORME
16 years ago
16 years ago

People

(Reporter: R.B., Assigned: dcone (gone))

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
I crash every time when I try "Print To File" with Linux 2002040808. Talkback ids:
TB4973351H
TB4974129G
(Not sure if this is related to Bug 136199, "Fails to print at all". I get no
error when printing to printer, the job gets spooled, but I have no printer
attached atm.)
(Reporter)

Updated

16 years ago
Keywords: crash

Comment 1

16 years ago
confirming...I also crash using 4/8 trunk build on linux.
Can people try it out again using 4/9 build ?

stack trace = 

nsPostScriptObj::finalize_translation() 
nsPostScriptObj::~nsPostScriptObj() 
nsDeviceContextPS::~nsDeviceContextPS() 
DeviceContextImpl::Release() 
nsDeviceContextPS::Release() 
nsCOMPtr_base::~nsCOMPtr_base() 
nsDeviceContextGTK::GetDeviceContextFor() 
DocumentViewerImpl::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() 
nsXULElement::HandleDOMEvent() 
nsXULElement::HandleDOMEvent() 
PresShell::HandleDOMEventWithTarget() 
nsButtonBoxFrame::MouseClicked() 
nsButtonBoxFrame::HandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEventWithTarget() 
nsEventStateManager::CheckForAndDispatchClick() 
nsEventStateManager::PostHandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsViewManager::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 + 0x170fb (0x403360fb) 
libglib-1.2.so.0 + 0xfa86 (0x40363a86) 
libglib-1.2.so.0 + 0x10041 (0x40364041) 
libglib-1.2.so.0 + 0x101e1 (0x403641e1) 
libgtk-1.2.so.0 + 0x8b7a9 (0x4028d7a9) 
nsAppShell::Run() 
nsAppShellService::Run() 
netscape-bin + 0x8c79 (0x08050c79) 
netscape-bin + 0x9457 (0x08051457) 
libc.so.6 + 0x17cb3 (0x40462cb3) 
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

16 years ago
I can't reproduce, over to don
Assignee: rods → dcone

Comment 3

16 years ago
R.B., we can't reproduce using latest build...

can you try again with newer build ? it should be fixed...

marking this RESOLVED-WORKSFORME.

if you still have the same problem with newer build, then REOPEN this
bug..

thanks.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 4

16 years ago
This works for me.. I pulled this morning.

Comment 5

16 years ago
verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 6

16 years ago
Worksforme Linux 2002041008.

This bug has in fact from the beginning been a dupe of Bug 136053, "A crash
occurs if you try to print to a file in a directory where you do not have write
permissions" (a regression of Bug 34706), just I didn't notice that I was trying
to print to Mozilla's install directory.

It is rather strange that the default for "Print To File" is mozilla.ps in
Mozilla's install directory, which is normally not writable to mere users. This
happens every time, i.e. a different choice made by the user is not persistent
even across a single session. I'll write a note about that in the other bug.
You need to log in before you can comment on or make changes to this bug.