Closed Bug 14325 Opened 25 years ago Closed 25 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: 25 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.