1220539 - Segmentation Fault in js::ConstraintTypeSet::sweep()

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[sgilles]

Attachment: Backtraces from inspecting core file with gdb

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38
Build ID: 20151016164609

Steps to reproduce:

Nothing special that I can determine, except for using Seamonkey for a few hours/days.

-----
I am trying to follow the bug writing guidelines here, but many of the fields that the guidelines mention are not present in this form, so I will put them here.

OS: I am running Gentoo, with Seamonkey installed from the Gentoo ebuild.

$ eix -I seamonkey
[I] www-client/seamonkey
     Available versions:  2.35 2.38 {+chatzilla +crypt custom-cflags custom-optimization dbus debug +gmp-autoupdate gstreamer gstreamer-0 +ipc +jemalloc3 +jit minimal pulseaudio +roaming selinux startup-notification system-cairo system-icu system-jpeg system-libvpx system-sqlite test wifi LINGUAS="be ca cs de en_GB es_AR es_ES fi fr gl hu it ja lt nb_NO nl pl pt_PT ru sk sv_SE tr uk zh_CN zh_TW"}
     Installed versions:  2.38(05:03:26 PM 10/16/2015)(crypt gmp-autoupdate ipc jemalloc3 jit startup-notification system-cairo system-icu system-jpeg system-libvpx system-sqlite -chatzilla -custom-cflags -custom-optimization -dbus -debug -gstreamer -gstreamer-0 -minimal -pulseaudio -roaming -selinux -test -wifi LINGUAS="-be -ca -cs -de -en_GB -es_AR -es_ES -fi -fr -gl -hu -it -ja -lt -nb_NO -nl -pl -pt_PT -ru -sk -sv_SE -tr -uk -zh_CN -zh_TW")
     Homepage:            http://www.seamonkey-project.org
     Description:         Seamonkey Web Browser

Overview: After running for long periods of time, Seamonkey will occasionally crash from a segmentation fault. From the attached stack trace, this appears to have something to do with the javascript garbage-collection.  During this time, I am only using the browser portion of Seamonkey.

Build ID: 20151016164609



Actual results:

The issue is not nicely reproducible.  The symptom is that after one, two, ... twenty ... hours of use, Seamonkey will suddenly crash (no crash dialog, but a core dump is obtainable).  If I get lucky, it crashes quickly and the resulting core file is small enough to be written out.

After a few attempts, I have a core file that is ‘only’ 1.7G large.  I have attached a backtrace from it, and can perform other investigation on it as requested.


Expected results:

Seamonkey shouldn't crash.

I should note that this issue appears to be new.  It did not happen in Seamonkey 2.35, but happens in 2.38

Comment 1

[sgilles]

Attachment: Contents of about:support

Comment 2

[Rainer Bielefeld]

currently only observed with LINUX

Comment 3

[sgilles]

I have also reproduced this issue using candidate build1 of 2.39b1.  The stack trace appears the same, so I have not attached any additional logs.

Comment 4

[sgilles]

Reproduced for version 2.39.  Stack trace is the same.

Comment 5

[sgilles]

I do not believe this is a dup of bug 1191465 , since I do not (knowingly) have any kind of Flash plugin installed on my system, and I'm rather sure this has happened when I was browsing pages that I am 100% sure do not contain embedded flash.

This bug and bug 1220385 seem very similar. I'm not sure about bug 1174997.  I've updated the whiteboard accordingly.

Comment 6

[Philip Chee]

> OS: I am running Gentoo, with Seamonkey installed from the Gentoo ebuild.
Can you reproduce the problem if you use official SeaMonkey from:
http://www.seamonkey-project.org/releases/

Comment 7

[sgilles]

The official builds expect libraries that this machine doesn't have, but the 2.39 release source tarball compiles with no complaints, and after ~12 hours I got a crash.  I didn't get a coredump (though I can certainly try for one if requested), but the symptoms were the same.

Comment 8

[Emanuel Hoogeveen [:ehoogeveen]]

CCing the usual suspects, though considering this involves typesets perhaps :bhackett would also be a logical choice. I'll let them make that call though :)

Comment 9

[sgilles]

Reproduced for version 2.40.  Stack trace is the same.

Comment 10

[sgilles]

Reproduced for version 2.42

Comment 11

[Frank-Rainer Grahl (:frg)]

Looking at bug 1220385 and the backtrace they really seem to match. I would just set it to new and wait and see until bug 1220385 gets fixed.

Comment 12

[Jan de Mooij [:jandem]]

Code no longer exists.