1092553 - "Segmentation fault" at the very start of startup

Status: VERIFIED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Tony Mechelynck [:tonymec]]

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.

Comment 1

[Tony Mechelynck [:tonymec]]

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."

Comment 2

[rsx11m]

I'm seeing the same with the October 31st Thunderbird 36.0a1 Linux x86_64 trunk nightly build.

Comment 3

[Tony Mechelynck [:tonymec]]

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.

Comment 4

[Tony Mechelynck [:tonymec]]

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

[rsx11m]

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.

Comment 6

[Tony Mechelynck [:tonymec]]

(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

[rsx11m]

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...

Comment 8

[Tony Mechelynck [:tonymec]]

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.

Comment 9

[Tony Mechelynck [:tonymec]]

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.

Comment 10

[Tony Mechelynck [:tonymec]]

P.P.S. AFAIK, neither "seamonkey -browser" nor "seamonkey -h", which is where I saw the bug, use anything from MailNews.

Comment 12

[Tony Mechelynck [:tonymec]]

Duplicate bug 1092801 is for a different hardwre platform (x86) so x86_64 => All.

Comment 13

[Tony Mechelynck [:tonymec]]

(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

[rsx11m]

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

[Robert Kaiser]

AFAIK, bug 1092200 fixed this.

Comment 16

[rsx11m]

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?

Comment 17

[Tony Mechelynck [:tonymec]]

(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.