Closed
Bug 602829
Opened 14 years ago
Closed 14 years ago
SeaMonkey hangs at startup
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 602826
People
(Reporter: tonymec, Unassigned)
Details
(Keywords: hang, regression)
Attachments
(1 file, 2 obsolete files)
926 bytes,
text/plain
|
Details |
No bug with:
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre SeaMonkey/2.1b1pre - Build ID: 20101006004332
Bug happens with later builds, including (at least) nightly dated 2010-10-07 and the first hourly builds of 2.1b2pre
Reproducible: Always
Steps to reproduce:
1. Try to start SeaMonkey.
Actual results:
Nothing. (There is a seamonkey-bin process consuming CPU time, but no window opens.)
Expected results:
Browser and Mailer windows should appear.
Additional info:
This happens also in Safe Mode.
I notice that compilation parameters have changed (SeaMonkey won't compile anymore without an ac_add_options line for --enable-chrome-format=something) but I can't easily test it because on my machine a clobber build takes about 25 hours.
Reporter | ||
Updated•14 years ago
|
blocking-seamonkey2.1: --- → ?
The same thing happens on my x86_64 Linux running firefox trunk.
The browser is spinning 100% on one core and no window appears.
Reporter | ||
Comment 2•14 years ago
|
||
I've been told on IRC to get a gdb trace for this hang.
Reporter | ||
Comment 3•14 years ago
|
||
sorry, the previous one omitted some threads at the end. This one is probably just as useless though (not a debug build).
Attachment #481826 -
Attachment is obsolete: true
Reporter | ||
Comment 4•14 years ago
|
||
Moving to Core since the bug is also seen on Firefox according to comment #1. "General" is probably not the right Component but ATM I don't see what would fit better.
Product: SeaMonkey → Core
QA Contact: general → general
Hardware: x86 → All
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
I've bisected this down to bug 542595.
markus@arch mozilla-central % hg bisect -s
Due to skipped revisions, the first bad revision could be any of:
changeset: 55021:4abdb488ea62
user: L. David Baron <dbaron@dbaron.org>
date: Wed Oct 06 21:25:45 2010 -0700
summary: Convert nsIFrame APIs from having a single overflow rect to having two distinct overflow rects. (Bug 542595, patch 1) r=roc sr=bzbarsky a2.0=blocking2.0:beta8
changeset: 55022:28874ce55ee1
user: L. David Baron <dbaron@dbaron.org>
date: Wed Oct 06 21:25:45 2010 -0700
summary: Use split overflow areas in nsAbsoluteContainer::Reflow. Fixes overflow handling bug in nsPositionedInlineFrame where non-positioned overflow was ignored. (Bug 542595, patch 2) r=roc a2.0=blocking2.0:beta8
changeset: 55023:1b5cdef4b9d6
user: L. David Baron <dbaron@dbaron.org>
date: Wed Oct 06 21:25:45 2010 -0700
summary: Make ReflowOverflowContainerChildren handle split overflow areas. (Bug 542595, patch 3) r=roc a2.0=blocking2.0:beta8
changeset: 55024:ce61761d254d
user: L. David Baron <dbaron@dbaron.org>
date: Wed Oct 06 21:25:45 2010 -0700
summary: Change FinishAndStoreOverflow API to take two overflow areas. (Bug 542595, patch 4) r=roc a2.0=blocking2.0:beta8
changeset: 55025:1302a184ae9c
user: L. David Baron <dbaron@dbaron.org>
date: Wed Oct 06 21:25:45 2010 -0700
summary: Remove unused method nsLineBox::CombinedAreaIntersects. (Bug 542595, patch 5) r=roc a2.0=blocking2.0:beta8
...
and so on.
All changesets point to:
https://bugzilla.mozilla.org/show_bug.cgi?id=542595
Comment on attachment 481828 [details]
hang trace
These stacks are useless.
Attachment #481828 -
Attachment is obsolete: true
Do you see this on a clean profile?
If not, what aspects of your profile trigger it?
If so, are all users seeing this? If they're not, what's unusual about your system?
>Do you see this on a clean profile?
Yes
>If so, are all users seeing this?
Yes.
I'll attach my mozconfig. Maybe it helps debugging this issue.
Reporter | ||
Comment 10•14 years ago
|
||
(In reply to comment #7)
> Do you see this on a clean profile?
starting as
./seamonkey/seamonkey -ProfileManager -no-remote
I don't even see the Profile Manager.
However, without -no-remote and with the Aug. 6 nightly already running, the latter opens a new browser window.
I see this in SeaMonkey builds downloaded from ftp.mozilla.org (Linux i686 comm-central-trunk nightlies dated August 7 and 8).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 12•14 years ago
|
||
(In reply to comment #11)
>
> *** This bug has been marked as a duplicate of bug 602826 ***
Bug 602826 "Freshly homemade builds (minefield or shredder) cannot start on a python3 / python 2.7 enabled linux distribution."
- I'm seeing this on builds downloaded from ftp.mozilla.org _and_ on homemade builds (and I protect myself against "bleeding" files from one install to the next by means of "rm -Rvf /usr/local/seamonkey; tar -jxvC /usr/local -f seamonkey-blahblah.tar.gz" replacing blahblah by whatever is currently needed). I don't often use homemade builds because "making them at home" can take me more than 24 hours if the configure pass has to be redone.
- "python --version" answers "Python 2.6.5" and "rpm -qa |grep python" shows no evidence of an additional python2.7 or python3 installed in parallel
- Bug 602826 is billed for x86_64, I'm on i686 (32-bit)
=> REOPENing.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 13•14 years ago
|
||
s/.gz/.bz2/
It's not yet clear what factors cause users to see the problem.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
Updated•14 years ago
|
blocking2.0: ? → ---
Comment 15•14 years ago
|
||
Moving back to SeaMonkey product, in order to be able to clear blocking-seamonkey2.1=? :-/
Product: Core → SeaMonkey
QA Contact: general → general
Updated•14 years ago
|
blocking-seamonkey2.1: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•