If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"Segmentation fault" at the very start of startup

VERIFIED FIXED in seamonkey2.33

Status

SeaMonkey
Startup & Profiles
--
critical
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: tonymec, Unassigned)

Tracking

({crash, dogfood, regression})

Trunk
seamonkey2.33
All
Linux
crash, dogfood, regression

Firefox Tracking Flags

(firefox36 unaffected, seamonkey2.33 verified)

Details

(Whiteboard: [fixed as part of bug 1092200])

GOOD:
20141030003001
http://hg.mozilla.org/mozilla-central/rev/80e18ff7c7b2
http://hg.mozilla.org/comm-central/rev/273bcc4d6e9b

BAD:
20141031003001
http://hg.mozilla.org/mozilla-central/rev/e0b505a37b1c
http://hg.mozilla.org/comm-central/rev/5df0a26967c8

Both with "seamonkey -P default -browser" and even with "seamonkey -h" I saw "Segment violation" at the console, but only when started from the shell with no redirection. When redirection is in effect, nothing gets logged. No Breakpad (or other) window in any case.

Tested with bash shell in konsole terminal. Don't know if relevant.
Does not happen in this build of Firefox 36.0a1:
20141031061804
https://hg.mozilla.org/mozilla-central/rev/6bd2071b373f

There, "firefox -h" gives the usual usage message, however preceded by a line saying
(process:5426): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

and "firefox -no-remote -ProfileManager" starts almost normally (with a lot of stuff output at the console) after selecting a profile not already in use by Fx31.2.0esr. "Almost" because in addition to the expected multitab startup page, another window opens up saying "Well, this is embarrassing. Nightly is having trouble recovering your windows and tabs. This is usually caused by a recently opened web page."
status-firefox36: --- → unaffected

Comment 2

3 years ago
I'm seeing the same with the October 31st Thunderbird 36.0a1 Linux x86_64 trunk nightly build.
Oops, misremembered the console display.

(In reply to rsx11m from comment #2)
> I'm seeing the same with the October 31st Thunderbird 36.0a1 Linux x86_64
> trunk nightly build.

Maybe you should report it in Thunderbird::General with "See also" to this bug? The alternative would be moving this to MailNews Core but somehow I have a hunch that it wouldn't be adequate.
Summary: "Segment violation" at the very start of startup → "Segmentation fault" at the very start of startup
P.S. You can get the Build ID and moz&com changesets from the .txt that accompanies the .tar.bz2 on the FTP server.

Comment 5

3 years ago
Given that the segfault is related to console/std{out,err} output, which I'd expect to be rather far down in the stack of software components, I'd be more surprised if it's *not* a MailNews Core issue.
(In reply to rsx11m from comment #5)
> Given that the segfault is related to console/std{out,err} output, which I'd
> expect to be rather far down in the stack of software components, I'd be
> more surprised if it's *not* a MailNews Core issue.

Which component then? The descriptions of "SeaMonkey::Startup&Profiles" of course includes startup bugs, and the description of "Thunderbird::General" mentions "startup/exit crashes" but I don't see where to put this as a MailNews Core bug.

Comment 7

3 years ago
Yeah, there isn't really a good match for either of Bugzilla's MailNews Core components (I was rather referring to components of the program, given that it broke in both SM and TB at the same time; such cases a frequently covered in a common MailNews bug report as they may require either a single fix in the common code or identical fixes in both applications). I'll see if I get a debug build to be a bit more verbose than the default nightly...
There are a number of "forked sources" existing in more or less similar versions in the suite/ and mail/ trees. If a bug is in MailNews, SeaMonkey and Thunderbird will both have it; but the reciprocal isn't true. My hunch (of comment #3) was that this startup crash was in one of those forked source files.
P.S. The "broken at the same time" could be from something "fixed" in Core and Firefox by removing something which Thunderbird and SeaMonkey relied on. IIRC, it has happened before.
P.P.S. AFAIK, neither "seamonkey -browser" nor "seamonkey -h", which is where I saw the bug, use anything from MailNews.

Updated

3 years ago
Duplicate of this bug: 1092881
Duplicate bug 1092801 is for a different hardwre platform (x86) so x86_64 => All.
Hardware: x86_64 → All
(In reply to Tony Mechelynck [:tonymec] from comment #12)
> Duplicate bug 1092801 is for a different hardwre platform (x86) so x86_64 =>
> All.

Oops: bug 1092881

Comment 14

3 years ago
Update: Today's trunk nightly build (SeaMonkey/2.33a1, BuildID 20141103003001) does no longer crash for me, I'm using it right now. Same for today's Thunderbird Daily 36.0a1 build on Linux x86_64.

"Something" seems to have fixed it, keeping fingers crossed.

Comment 15

3 years ago
AFAIK, bug 1092200 fixed this.

Comment 16

3 years ago
Yeah, gdb shows _GLOBAL__sub_I_Unified_cpp_dom_html1.cpp(void) on top of the stack trace for me as well with the broken build (bug 1092200 comment #4); the patch there porting bug 1077148 contained a suite/ part, so this looks like a duplicate fixed in the other bug. Tony?
Flags: needinfo?(antoine.mechelynck)
(In reply to rsx11m from comment #16)
> Yeah, gdb shows _GLOBAL__sub_I_Unified_cpp_dom_html1.cpp(void) on top of the
> stack trace for me as well with the broken build (bug 1092200 comment #4);
> the patch there porting bug 1077148 contained a suite/ part, so this looks
> like a duplicate fixed in the other bug. Tony?

Sorry I lost a full day between "in town" and "in bed". The following nightly doesn't have the bug. From what you say I suppose that it might be the second nightly without the bug (I didn't test yesterday's):

Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33a1 ID:20141104003001 c-c:e52b7e18a9b5 m-c:5dde8ea48fef

AFAICT this SeaMonkey bug was fixed in comm-central changeset 84b1d9656728 by Thunderbird bug 1092200.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-seamonkey2.33: affected → fixed
Flags: needinfo?(antoine.mechelynck)
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.33
See Also: → bug 1092200

Updated

3 years ago
Status: RESOLVED → VERIFIED
Whiteboard: [fixed as part of bug 1092200]
status-seamonkey2.33: fixed → verified
You need to log in before you can comment on or make changes to this bug.