Closed Bug 27265 Opened 26 years ago Closed 26 years ago

saving file from URL link crashes seamonkey

Categories

(SeaMonkey :: UI Design, defect, P1)

Other
Linux
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: bugzilla, Assigned: law)

References

()

Details

(Keywords: crash, platform-parity, Whiteboard: [PDT-])

found this while fiddling with bug 26249; using 2000-02-10-08 comm bits on linux. 1. go to bug report for bug 26249, http://bugzilla.mozilla.org/show_bug.cgi?id=26249 2. right-click the URL link and select Save Link As... from the context menu. 3. the Save File dialog appears; click OK to save the file. result: seamonkey crashes... at first, i thought that this was the same as bug 23690 --but (a) the stack trace in 23690 looks useless and (b) on linux http://www.webvan.com always loads as a blank page. ;-( http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=17&cp=1&ck1=SUser+ID&cd1=UB609CD3C%2DAD8C%2D11D3%2D81150060%2D0811D696&bbid=5190365 Trigger Type: Program Crash Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Call Stack: (Signature = PresShell::CreateRenderingContext() 223dfe7a) PresShell::CreateRenderingContext() PresShell::StyleChangeReflow() nsPresContext::PreferenceChanged() PrefChangedCallback() pref_DoCallback() pref_HashPref() PREF_SetCharPref() nsPref::SetFilePref() nsStreamTransfer::SelectFile() nsStreamTransfer::SelectFileAndTransferLocation() nsStreamTransfer::SelectFileAndTransferLocationSpec() XPTC_InvokeByIndex() nsXPCWrappedNativeClass::CallWrappedMethod() WrappedNative_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_Interpret() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() nsMenuFrame::Execute() nsMenuFrame::HandleEvent() PresShell::HandleEvent() nsView::HandleEvent() nsView::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() handle_gdk_event() libgdk-1.2.so.0 + 0x1700b (0x4067200b) libglib-1.2.so.0 + 0xfbe6 (0x4069fbe6) libglib-1.2.so.0 + 0x101a1 (0x406a01a1) libglib-1.2.so.0 + 0x10341 (0x406a0341) libgtk-1.2.so.0 + 0x8c209 (0x405c7209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402191eb)
nominating for beta1. also note that this is not a problem on mac and winNT, using the same comm bits.
Keywords: beta1, pp
I wonder if this is some kind of feedback loop in the pres context pref observer mechanism. Saving a file triggers a pref change (we store the last-saved-to directory). This generates pref-changed callbacks to the pres context which perhaps isn't in a state to properly handle it?
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Bill, save me! :-)
Assignee: don → law
Priority: P3 → P1
Target Milestone: M14
I am so not seeing this with linux 21014 bits, I think it was part of the general save horkage that has since been fixed. Marking resolved, and will let sairuh verify
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
okay I saw this again with 2/11 builds, same stack trace, but doesn't happen every time, hmmm. Re-opening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Do we see this on more than one machine? What percentage of links produce the crash? Unless the answers are "yes" and "some number greater than 10" I'd like to consider this be removed from the PDT+ category.
Status: REOPENED → ASSIGNED
Forgot to add: Works for me (my Linux debug build for today). Is there a QA lab machine where it fails?
I've only been able to reproduce it once, so I'm comfortable with you taking it off pdt+ unless sairuh as a reproducible cases.
I was able to reproduce a couple times on windows (same stack trace) also, but still no rhyme or reason to duplicate it consistently.
OK, I've removed the [PDT+] and ask that it be reclassified as PDT- or lower. The stack trace indicates that the crash occurs in layout while processing a pref change notification. This is likely to be timing-dependent and difficult to reproduce. If it starts appearing with greater frequency, we can reassess the situation.
Whiteboard: [PDT+]
Putting on the PDT- radar for beta1. Due to crash not often. If happens more, please remover PDT-.
Keywords: crash
Whiteboard: [PDT-]
*** Bug 30270 has been marked as a duplicate of this bug. ***
I used to crash on saving a m15 nightly each time (sometimes at the begining, sometimes after it started), but with 2000030516, have not been able to reproduce.
QA Contact: paulmac → sairuh
Here's another URL which crashes the beta1-branch nightly build from 3/17 Go to: http://www.spe.sony.com/movies/timecode/trailer.html Right-click on 'hi res trailer', select save link as.
I thought I added this comment already but I don't see it, so here goes again: stevep has found another instance of what is fundamentally the same problem as bug 23690. I have opened a new bug for that, 32341, rather than re-open 23690 because I've got a completely different, and better, fix. Please see bug 32341 for details. P.S. Has anybody tried reproducing the problem *this* bug discusses? I wonder if it isn't fixed by now, especially with the changes to Save As that I checked in yesterday.
this is no longer a problem for me --although i'm using beta1 branch bits (opt comm, 2000.03.20.06-nb1b), not trunk bits.
Since nobody can seem to repro this, i'm gonna resolve it as "WORKSFORME".
Status: ASSIGNED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → WORKSFORME
Target Milestone: M14 → ---
yep, able to verify using bits from the tip, 2000.03.21.09-m15 (linux op comm).
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.