Ubuntu
firefox package

Firefox crashes at http://pardusclock.rocks.it/

Bug #53372 reported by Spoilerhead
10
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Critical
firefox (Ubuntu)
Fix Released
Medium
Mozilla Bugs

Bug Description

Binary package hint: firefox

firefox crashes when http://pardusclock.rocks.it/ is open for some minutes.
even happens when i'm doing nothing for some minutes

Reproducible: Always

Steps to Reproduce:
1. go to http://pardusclock.rocks.it/
2. wait some minutes
3. firefox crashes suddenly

Actual Results:
spoilerhead@plasmafire:/$ firefox
GTK Accessibility Module initialized

(Gecko:2360): GLib-GObject-WARNING **: gsignal.c:1017: unable to lookup signal
"activate" of unloaded type `MaiAtkObject'

(Gecko:2360): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
`signal_id > 0' failed

GLib-GObject-ERROR **: file gtype.c: line 463 (type_node_new_W): assertion
failed: (pnode->n_children < MAX_N_CHILDREN)
aborting...
Aborted

Expected Results:
firefox shouldn't crash

working with Ubuntu Dapper 6.06 LTS

also reported on
https://bugzilla.mozilla.org/show_bug.cgi?id=345088

edit: fixed some typos

See original description
Revision history for this message
In , Bugzilla-mozilla-org (bugzilla-mozilla-org) wrote :

Every crash I've had in Firefox 1.5 has been in this routine, approximately one every 4 days: TB12934786E, TB12822352W, TB12690691W, TB12499680H, and TB12309736H. (I think TB12156428E was also but it's no longer in the database.) On another similarly-configured machine I've also had TB12884150Z. As can be seen in the comments, the crashes have happened at random times.

I've also had crashes in this routine in the Thunderbird 1.5 betas, talkbacks TB12862154X, TB12717731Z, TB12550030W, and TB12366086H, plus TB12225929M and TB12076817G which are no longer in the database either.

Revision history for this message
In , Dveditz (dveditz) wrote :

no patch, no trunk testing. If you get a reviewed patch you can ask for approval on the patch, but the bug itself is not blocking 1.8.0.1

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

I think I've figured this one out.

It appears that for EACH accessible wrapper object, mozilla registers a unique GType deriving from MAI_TYPE_ATK_OBJECT, see http://lxr.mozilla.org/seamonkey/source/accessible/src/atk/nsAccessibleWrap.cpp#421 and http://lxr.mozilla.org/seamonkey/source/accessible/src/atk/nsAccessibleWrap.cpp#436 . This is obviously bad for memory consumption (since registered types occupy memory that'll never be freed again while the program runs), but even worse, gobject limits the number of types that can directly derive from any given object type to 4095. So when we come to register MaiAtkTypefff (fff is the uniquified part), we hit the assertion in http://cvs.gnome.org/viewcvs/*checkout*/glib/gobject/gtype.c?rev=1.85 : type_node_new_W : g_assert (pnode->n_children < MAX_N_CHILDREN); and crash.

If the program runs long enough, this will ALWAYS happen. (Sooner if you make heavy use of a11y.)

Revision history for this message
In , Ginn-chen (ginn-chen) wrote :

chpe,

I added a printf in GetUniqueMaiAtkTypeName(void) and used a11y heavily.
I saw MaiAtkType15ff was used. But still no crash and everything's well.

Did I miss something?

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

(In reply to comment #4)
> chpe,
>
> I added a printf in GetUniqueMaiAtkTypeName(void) and used a11y heavily.
> I saw MaiAtkType15ff was used. But still no crash and everything's well.
>
> Did I miss something?

Maybe your glib/gobject libraries have assertions compiled out (compiled with --enable-debug=no) ? In a --enable-debug=minimum or =yes gobject build, the following testcase aborts at 4095 types: http://www.gnome.org/~chpe/testcases/testlimits.c

Revision history for this message
In , Ginn-chen (ginn-chen) wrote :

Reproduced.

Thanks, chpe!

Revision history for this message
In , Bugzilla-mozilla-org (bugzilla-mozilla-org) wrote :

May I suggest adding the "topcrash+" keyword to this bug? By my reading of the talkback summaries it is the second-most-reported Linux crash for Firefox 1.5.0.1 (423 occurrences in the 01-24-15 summary). It also affects Thunderbird, where it's the second-most-reported Linux crash in 1.5 (114 occurrences in the 12-01-13 report).

As far as I can tell most of the information recommended by http://wiki.mozilla.org/Talkback_Topcrash_Analysis has already been added to this report; given that it's been fairly clearly identified and reproduced at Sun "topcrash+" seems more appropriate than just "topcrash".

Revision history for this message
In , Evan Yan (evan-yan) wrote :

Created attachment 219113
patch

when the accessibleWrap object has the same MaiInterfaces, reuse the registered gtype, other than register a new one.

Revision history for this message
In , c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote :

Comment on attachment 219113
patch

>+ for (int index = 0; index < MAI_INTERFACE_NUM; index++) {
>+ if (interfaces[index])
>+ atkTypeNameId |= 1 << index;
>+ }

Currently MAI_INTERFACE_NUM is 10, so this will fit into the 4095 types allowed; but since in future that might change, so maybe we should add an assertion that atkTypeNameId < 4095 or maybe just that MAI_INTERFACE_NUM < 12 ?

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

I will wait for the answer to chpe's question before reviewing.

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

To be honest I don't understand what this code is doing. More comments would be very helpful.

Also, we want to avoid sprintf because it sets of warnings in terms of buffer overflow attacks. We have a safe version of that for use in Mozilla, so we should never actually see sprintf.

PR_snprintf defined here:
http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/io/prprf.c#1151

Revision history for this message
In , Ginn-chen (ginn-chen) wrote :

(In reply to comment #9)
> (From update of attachment 219113 [edit])
> >+ for (int index = 0; index < MAI_INTERFACE_NUM; index++) {
> >+ if (interfaces[index])
> >+ atkTypeNameId |= 1 << index;
> >+ }
>
> Currently MAI_INTERFACE_NUM is 10, so this will fit into the 4095 types
> allowed; but since in future that might change, so maybe we should add an
> assertion that atkTypeNameId < 4095 or maybe just that MAI_INTERFACE_NUM < 12 ?
>

atkTypeNameId doesn't need to below 4095, MAI_INTERFACE_NUM doesn't need to below 12 either.
The numer of class nsAccessibleXXX that implements different combination of MAI interfaces NEED to below 4095.
I don't think this could happen in near future since the total number of class nsAccessibleXXX is far below 4095.

Anyway, we can add a count here to avoid crash if MAI_INTERFACE_NUM grows up to 12.

Revision history for this message
In , Evan Yan (evan-yan) wrote :

Created attachment 219249
patch v2

refined according to chpe and Aaron's advice.

The root cause of this bug is that we register different GTypes for every accessibleWrap object, then it may exceed the GType register number limit sometimes.

The members we used to register a GType are MaiInterface::GetAtkType() and MaiInterface::GetInterfaceInfo(), which is the same with different MaiInterface objects. So we can reuse the registered GType when accessibleWrap objects having the same MaiInterface types.

Revision history for this message
In , Evan Yan (evan-yan) wrote :

Created attachment 219252
patch v3

add a count to avoid crash if we registered more than 4095 GTypes.

Revision history for this message
In , Evan Yan (evan-yan) wrote :

Created attachment 219260
patch v4

To avoid crash, if 4095 types have already been registered, do not register any more, just return null, and call NS_ENSURE_TRUE in the invoking function GetNativeInterface().

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

Still looking at this. I need to understand GType's and the Mai plumbing better to be able to review this.

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

Evan, sorry to be a little slow on this -- can you explain how GType type information is used by Mai? Does everything that supports ATK need to use it?

Revision history for this message
In , Evan Yan (evan-yan) wrote :

(In reply to comment #17)
> Evan, sorry to be a little slow on this -- can you explain how GType type
> information is used by Mai? Does everything that supports ATK need to use it?
>

to my knowledge, registering GType in GetMaiAtkType() is to let the objects could be used in other applications like GOK through GObject system. It is called by the ATK callback functions, like refChildCB().

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

Comment on attachment 219260
patch v4

Ginn is a better reviewer until I understand this code better.

Revision history for this message
In , Ginn-chen (ginn-chen) wrote :

Comment on attachment 219260
patch v4

r=me
besides
it should be return 0; instead of return NULL;
GType is not a pointer

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

I'm not really a good choice to sr this; I know nothing about any of this stuff. Maybe try roc?

Revision history for this message
In , Ginn-chen (ginn-chen) wrote :

Checking in nsAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleWrap.cpp,v <-- nsAccessibleWrap.cpp
new revision: 1.31; previous revision: 1.30
done

Revision history for this message
In , Ginn-chen (ginn-chen) wrote :

Checking in nsAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleWrap.cpp,v <-- nsAccessibleWrap.cpp
new revision: 1.25.4.3; previous revision: 1.25.4.2
done

Revision history for this message
Spoilerhead (spoilerhead) wrote :

Binary package hint: firefox

firefox crashes when http://pardusclock.rocks.it/ is open for some minutes.
even happens when i'm doing nothing for some minutes

Reproducible: Always

Steps to Reproduce:
1. go to http://pardusclock.rocks.it/
2. wait some minutes
3. firefox crashes suddenly

Actual Results:
spoilerhead@plasmafire:/$ firefox
GTK Accessibility Module initialized

(Gecko:2360): GLib-GObject-WARNING **: gsignal.c:1017: unable to lookup signal
"activate" of unloaded type `MaiAtkObject'

(Gecko:2360): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
`signal_id > 0' failed

GLib-GObject-ERROR **: file gtype.c: line 463 (type_node_new_W): assertion
failed: (pnode->n_children < MAX_N_CHILDREN)
aborting...
Aborted

Expected Results:
firefox sohuldn't crash

working with ubuntu Dapper 6.06 LTS

also reported on
https://bugzilla.mozilla.org/show_bug.cgi?id=345088

Revision history for this message
Spoilerhead (spoilerhead) wrote :

oh i forgot:

dpkg -l |grep firefox
ii firefox 1.5.dfsg+1.5.0.4-0ubuntu6.06

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → Unconfirmed
Revision history for this message
Spoilerhead (spoilerhead) wrote :

probably not a upstream bug, as it doesn't happen with FF 1.5 on w2k (got no other system ready to test, sorry)

bug google gave me some other reports od ubuntu users:

http://forum.ubuntu-fr.org/viewtopic.php?pid=352923 (french)
http://forum.ubuntuusers.de/topic/36951/ (german)

Revision history for this message
Wesley Schwengle (wesleys) wrote :

I cannot reproduce this bug.

Machine details:
Linux sinti 2.6.15-25-386 #1 PREEMPT Wed Jun 14 11:25:49 UTC 2006 i686 GNU/Linux

13:51 [wesleys@sinti:/home/wesleys] # dpkg -l | grep firefox
ii firefox 1.5.dfsg+1.5.0.5-0ubuntu6.06 lightweight web browser based on Mozilla
ii firefox-gnome-support 1.5.dfsg+1.5.0.5-0ubuntu6.06 Support for Gnome in Mozilla Firefox
ii libnspr4 1.firefox1.5.dfsg+1.5.0.5-0ubuntu6.06 Netscape Portable Runtime Library
ii libnss3 1.firefox1.5.dfsg+1.5.0.5-0ubuntu6.06 Network Security Service Libraries - runtime
ii mozilla-firefox-locale-en-gb 1.5.0.1ubuntu6-2 Mozilla Firefox English language/region pack

Revision history for this message
Apo (helpa-ch) wrote :

I can reproduce it:

Linux ncc-1701 2.6.15-26-k7 #1 SMP PREEMPT Thu Aug 3 03:40:32 UTC 2006 i686 GNU/Linux

apo@ncc-1701:~$ dpkg -l | grep firefox
ii firefox 1.5.dfsg+1.5.0.5-0ubuntu6.06.1 lightweight web browser based on Mozilla
ii firefox-gnome-support 1.5.dfsg+1.5.0.5-0ubuntu6.06.1 Support for Gnome in Mozilla Firefox
ii j2re1.4-mozilla-plugin 0ubuntu5 Java plugin for mozilla/firefox
ii libnspr4 1.firefox1.5.dfsg+1.5.0.5-0ubuntu6.06.1 Netscape Portable Runtime Library
ii libnss3 1.firefox1.5.dfsg+1.5.0.5-0ubuntu6.06.1 Network Security Service Libraries - runtime
ii mozilla-firefox-locale-de-de 1.5.0.1ubuntu6-2 Mozilla Firefox German language/region packa
ii mozilla-firefox-locale-en-gb 1.5.0.1ubuntu6-2 Mozilla Firefox English language/region pack

Spoilerhead (spoilerhead)
description: updated
Revision history for this message
Apo (helpa-ch) wrote :
Download full text (4.6 KiB)

this is the output from firefox -debug:

(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) run
Starting program: /usr/lib/firefox/firefox-bin -a firefox
[Thread debugging using libthread_db enabled]
[New Thread -1219942720 (LWP 10295)]
GTK Accessibility Module initialized
[New Thread -1224508496 (LWP 10300)]
[New Thread -1235915856 (LWP 10301)]
[New Thread -1254601808 (LWP 10302)]
[New Thread -1269052496 (LWP 10303)]
[New Thread -1277445200 (LWP 10304)]
[Thread -1269052496 (LWP 10303) exited]

(Gecko:10295): GLib-GObject-WARNING **: gsignal.c:1017: unable to lookup signal
"activate" of unloaded type `MaiAtkObject'

(Gecko:10295): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
`signal _id > 0' failed
[Thread -1277445200 (LWP 10304) exited]
[Thread -1254601808 (LWP 10302) exited]
[New Thread -1254601808 (LWP 10307)]
[Thread -1254601808 (LWP 10307) exited]
[New Thread -1254601808 (LWP 10310)]
[New Thread -1277445200 (LWP 10311)]
[Thread -1254601808 (LWP 10310) exited]
[Thread -1277445200 (LWP 10311) exited]
[New Thread -1277445200 (LWP 10314)]
[New Thread -1254601808 (LWP 10317)]
[Thread -1277445200 (LWP 10314) exited]
[New Thread -1277445200 (LWP 10321)]

GLib-GObject-ERROR **: file gtype.c: line 463 (type_node_new_W): assertion
faile d: (pnode->n_children < MAX_N_CHILDREN)
aborting...

Program received signal SIGABRT, Aborted.
[Switching to Thread -1219942720 (LWP 10295)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb75929a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb75942b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb77f1006 in g_logv () from /usr/lib/libglib-2.0.so.0
#4 0xb77f103a in g_log () from /usr/lib/libglib-2.0.so.0
#5 0xb77f10a6 in g_assert_warning () from /usr/lib/libglib-2.0.so.0
#6 0xb786d38b in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0
#7 0xb78729d9 in g_type_register_static () from /usr/lib/libgobject-2.0.so.0
#8 0xb352131c in GetMaiAtkType (interfaceCount=@0x91fd848,
    interfaces=0x9ed7360) at nsAccessibleWrap.cpp:423
#9 0xb3522643 in nsAccessibleWrap::GetNativeInterface (this=0x91fd810,
    aOutAccessible=0xbfb7e074) at nsAccessibleWrap.cpp:234
#10 0xb35211e0 in nsAccessibleWrap::GetAtkObject (this=0x6)
    at nsAccessibleWrap.cpp:251
#11 0xb3521f8b in refChildCB (aAtkObj=0x8a26168, aChildIndex=0)
    at nsAccessibleWrap.cpp:859
#12 0xb7a7095d in atk_object_ref_accessible_child ()
   from /usr/lib/libatk-1.0.so.0
#13 0xb736f1f4 in gnome_accessibility_module_shutdown ()
   from /usr/lib/gtk-2.0/modules/libatk-bridge.so
#14 0xb786510f in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#15 0xb7866b19 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#16 0xb786a030 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#17 0xb3522f83 in nsDocAccessibleWrap::FireToolkitEvent (this=0x0,
    aEvent=32772, aAccessible=0x8df9d34, aEventData=0x0)
    at nsDocAccessibleWrap.cpp:389
#18 0xb350493f in nsDocAccessible::FlushPendingEvents (th...

Read more...

Revision history for this message
In , Adam Guthrie (ispiked) wrote :

*** Bug 345088 has been marked as a duplicate of this bug. ***

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unconfirmed → Rejected
Revision history for this message
Spoilerhead (spoilerhead) wrote :

marked in upstream as bug of
https://bugzilla.mozilla.org/show_bug.cgi?id=302250

any chance the ubunt ustable team will backport the patch for it?
stacktraces are availaible at the original bug entry at
https://bugzilla.mozilla.org/show_bug.cgi?id=345088

Revision history for this message
Dean Sas (dsas) wrote :

Described in upstream bug as "top linux crasher", also http://blogs.sun.com/roller/page/richb?entry=my_favorite_firefox_bug

Changed in firefox:
status: Unconfirmed → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → Fix Released
Revision history for this message
Grant (gsupp) wrote :

I experience this crash on a daily basis, if not multiple times a day on a production workstation. This has been fixed upstream, any chance of backporting the patch?

gsupp@gsupp:~$ dpkg -l |grep firefox
ii firefox 1.5.dfsg+1.5.0.5-0ubuntu6.06.1 lightweight web browser based on Mozilla
ii firefox-gnome-support 1.5.dfsg+1.5.0.5-0ubuntu6.06.1 Support for Gnome in Mozilla Firefox
ii libnspr4 1.firefox1.5.dfsg+1.5.0.5-0ubuntu6.06.1 Netscape Portable Runtime Library
ii libnss3 1.firefox1.5.dfsg+1.5.0.5-0ubuntu6.06.1 Network Security Service Libraries - runtime
ii mozilla-firefox-locale-en-gb 1.5.0.1ubuntu6-2 Mozilla Firefox English language/region pack

Revision history for this message
PaulReiber (paulreiber) wrote : Re: Firefox crashes - also happens on gmail.com (BAD thing!)

Here's the entire stdout/stderr from the run. This crash has happened multiple times to me while I was composing email in google's gmail.com AJAX email application.

---------------------------------------------------------------
"activate" of unloaded type `MaiAtkObject'

(Gecko:30095): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `signal_id > 0' failed
LoadPlugin: failed to initialize shared library /home/pbr/RealPlayer/mozilla/nphelix.so [/home/pbr/RealPlayer/mozilla/nphelix.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /home/pbr/RealPlayer/mozilla/nphelix.so [/home/pbr/RealPlayer/mozilla/nphelix.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /home/pbr/RealPlayer/mozilla/nphelix.so [/home/pbr/RealPlayer/mozilla/nphelix.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /home/pbr/RealPlayer/mozilla/nphelix.so [/home/pbr/RealPlayer/mozilla/nphelix.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /home/pbr/RealPlayer/mozilla/nphelix.so [/home/pbr/RealPlayer/mozilla/nphelix.so: cannot open shared object file: No such file or directory]

GLib-GObject-ERROR **: file gtype.c: line 463 (type_node_new_W): assertion failed: (pnode->n_children < MAX_N_CHILDREN)
aborting...
---------------------------------------------------------------

Notes:
- the browser had been running for some time - over a day. I've never seen the crash shortly after starting FF.
- I'm running an AMD64 version of dapper drake.
- I didn't notice these crashes on a stock firefox, but then again, Google's been changing things recently as well.
- I added a bunch of plugins recently including firebug adblockplus greasemonkey imagezoom chatzilla fireFTP and webdeveloper
- also added the "walnut" theme but I'm thinking that wood isn't the problem either :-)

I'm willing to do some debugging/testing assuming anyone's got anything other than a brute force strategy for how to proceed.

Regards,
-Paul Reiber
President, Silicon Valley Linux Users Group
http://svlug.org/~pbr

Revision history for this message
PaulReiber (paulreiber) wrote :

This is still a problem... getting worse...
-Paul

Revision history for this message
Spoilerhead (spoilerhead) wrote :

at least it seems to be fixed in FF2(edgy works fine)

David Farning (dfarning)
Changed in firefox:
assignee: nobody → mozillateam
importance: Undecided → Medium
David Farning (dfarning)
Changed in firefox:
assignee: mozillateam → mozilla-bugs
Revision history for this message
Hilario J. Montoliu (hjmf) (hmontoliu) wrote :

Confirmed upstream bugs goes to status 'in progress'

Changed in firefox:
status: Confirmed → In Progress
Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

Page works fine on FF2 in gutsy.

Changed in firefox:
status: In Progress → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.