Closed Bug 602829 Opened 14 years ago Closed 14 years ago

SeaMonkey hangs at startup

Categories

(SeaMonkey :: General, defect)

All
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 602826

People

(Reporter: tonymec, Unassigned)

Details

(Keywords: hang, regression)

Attachments

(1 file, 2 obsolete files)

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.
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.
Attached file hang trace (obsolete) —
I've been told on IRC to get a gdb trace for this hang.
Attached file hang trace (obsolete) —
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
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
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.
Attached file mozconfig
(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
(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 → ---
s/.gz/.bz2/
It's not yet clear what factors cause users to see the problem.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → DUPLICATE
blocking2.0: ? → ---
Moving back to SeaMonkey product, in order to be able to clear blocking-seamonkey2.1=? :-/
Product: Core → SeaMonkey
QA Contact: general → general
blocking-seamonkey2.1: ? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: