Closed
Bug 69586
Opened 24 years ago
Closed 24 years ago
crash loading webpage after closing sidebar
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
mozilla0.9.1
People
(Reporter: danm.moz, Assigned: danm.moz)
Details
(Keywords: qawanted)
I have no idea who to give this to. I don't particularly want it. But I guess I'll hold onto it for the nonce. 1) Launch Mozilla browser with sidebar visible 2) Close the sidebar (View->My Sidebar) 3) Type something into the URL bar (http://www.mozilla.org, say) and hit return All steps are necessary: there's no problem working with a window opened with the sidebar already hidden. The first sign of trouble comes with an assertion in the JS engine. Power through it and eventually, you crash. I'll concentrate on the assertion, which has enough going wrong with it to make me think it's worth concentrating on. The assertion complains that the JS engine is being asked to allocate a new JSObject while the JS GC is running. Way up on the stack, an nsGlobalWindow is being given a new mDocument (SetNewDocument()), which is causing a GC on the old mContext. Frames and views are consequently destroyed. One of the views destroys its native HWND window. This sends a WM_SETFOCUS message directly to another window, without going through the message queue. This other window, processing the focus message, eventually calls a JS event handler and mayhem ensues. Ick. The moral is, don't be processing events that could have JS event handlers while the GC is running. Easier preached than stopped. It seems like this could be a more widespread problem than it appears to be. It may be happening because closing the sidebar leaves an unusual focus state in the browser window. (It's closed by setting frames' "hidden" attribute.) But there does seem to be a more general worry here.
Brendan wanted me to add jband and himself to the cc: list on this bug, because I'm planning on exercising nothing but my butt on this one for now. John: here's a possible argument for teaching the JS runtime to allocate new objects while in the garbage collector.
Comment 3•24 years ago
|
||
adding qawanted keyword: is this still reproducible? Are there any symptoms in optimized builds?
Keywords: qawanted
Updated•24 years ago
|
Severity: major → critical
Comment 4•24 years ago
|
||
I get this on 0.8, 0.8.1 and current nightlies (Linux, Win NT and 2000), but only with my own sidebar code, if I havn't used the code then the browser will stay up until I close a window, but I get "Error loading URL <url>: 2152398850" every time I click on a link, and no pages or images will display. If I have been using the sidebar code then the browser segfaults instantly. My code is similar to the "What's related" code, but is much bigger. I am happy to answer any questions and can provide a copy of the code if it will help.
Comment 5•24 years ago
|
||
Forgot to add, closing a window with my sidebar visible will put it into the same state.
Comment 6•24 years ago
|
||
Sorry, for the quantity of messages. I have narrowed the source of the problem down to my use of: @mozilla.org/scriptableinputstream;1 , @mozilla.org/network/standard-url;1 or @mozilla.org/network/io-service;1 Full source is visible at: http://inanna.ecs.soton.ac.uk/~swh/net.txt If I don't call the newDownload() function then there is no crash.
The bug as originally described no longer happens. There have been a lot of bizarre changes to the behaviour of WM_SETFOCUS lately. Maybe one of those killed the inopportune focus message or its handler. Yeah sure. Anyway, it no longer crashes. Not much I can do with it then but close it. Stephen: for starters, you'll have to grab a more recent build. I'd suggest tomorrow morning's nightly (or morningly). If it's not too unstable for other reasons. This bug has disappeared and it was some time much later than 0.8.1. With any luck, your problem will have been fixed, too. If not, please open a new bug, supply your sidebar source in the bug and give step-by-steps for dummies (I've never written a sidebar, so I'm a dummy). We'll take a look. I have to say that it'll be low priority for us, though, since while it's no doubt a bug in our code, it's not exercised by code in the release we're currently running ourselves ragged over.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Comment 8•24 years ago
|
||
If its low priority then, please, don't worry. I'm using XMLExtras now, which is stable and much better. Thanks, Steve
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•