Closed Bug 14325 Opened 26 years ago Closed 26 years ago

[BLOCKER] browser intermittently hangs on startup

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: waterson, Assigned: buster)

Details

Seems to be GTK-specific. We are not getting any nsWindow::Show() calls that fire on a top-level window.
Assignee: pavlov → srinivas
Severity: normal → blocker
Priority: P3 → P1
Summary: browser intermittently hangs on startup → [BLOCKER] browser intermittently hangs on startup
ramiro sez reverting to r3.23 of plevent.c cures this problem. Reassigning to srinivas. chofmann: we may want to back this out.
we need to have this not be a side effect of the fix for http://bugzilla.mozilla.org/show_bug.cgi?id=13660 which is a key bug for getting good beta bits..
I can back out rev 3.24 of plevent.c, which was checked in for troy. The tree is closed now; should I wait until it is opened?
Before people start panicking, can we have some analysis on why Linux is having a problem. Don't back the change out on Windows, the code that's there now is completely broken on Windows. If necessary, #ifdef _WIN32 the code so on Windows we work properly
srinivas, please follow troy's suggestion and ifdef the changes for windows only. do this now, while the tree is closed, as this is blocking linux.
srinivas, can you do the ifdef for win32 only for now and check that in? we want to get that into testing. waterson brendan and other fine minds will follow up with investigating what looks like windows specific side effects.
here is the diff we need to ifdef around. http://cvs-mirror.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whi tespace_mode=show&root=/cvsroot&subdir=mozilla/nsprpub/lib/ds&command=DIFF_FRAME SET&root=/cvsroot&file=plevent.c&rev1=3.23&rev2=3.24 it would be great if we could get this checked in as soon as poosible to get the tree back open today... thanks
I have checked in the "ifdef WIN32" code.. Can someone give it a try?
OK, why is Linux hanging with the XP fix to 13660? Is it stuck at one point in the program's execution, in which case, what's the backtrace? Or is it going meta-stable and just not drawing? Who should own this bug? I hesitate to say ramiro, but he could help answer the above, which might let travis and me help. /be
I am not debugging this. Nor do I plan to.
Assignee: srinivas → brendan
Why not? Isn't it a bug that PL_ProcessPendingEvents can never return? And why shouldn't the Mac benefit from troy's fix to 13660? If you (Ramiro) won't debug it, I will -- but as I wrote, you could at least say why or where Linux hung? /be
I dont know why or where linux hung. I didnt debug it. I did the selfish thing and backed out the obvious offending code so that I could get on with my work.
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee: brendan → kipp
Status: ASSIGNED → NEW
Kipp, I heard from vidur that you fixed this bug, or something that sounded a lot like it -- can you close, or bounce back to me if still open? Thanks, /be
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
The PL_ProcessPendingEvents code is now XP and now only delivers (approximately) as many events that are in the queue at the time of the call.
QA Contact: leger → cpratt
Old bug...I have not seen this on Linux in months. cpratt, can you mark Verified if you agree please. Thanks!
Status: RESOLVED → VERIFIED
Yup, I agree. Marking verified.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.