Last Comment Bug 833117 - Does not disable glib slice allocator with glib >= 2.35. Startup warning.
: Does not disable glib slice allocator with glib >= 2.35. Startup warning.
Status: RESOLVED FIXED
[gs][notacrash]
: common-issue+
Product: Toolkit
Classification: Components
Component: Startup and Profile System (show other bugs)
: unspecified
: All Linux
: -- normal with 58 votes (vote)
: mozilla42
Assigned To: Mike Hommey [:glandium]
:
Mentors:
https://getsatisfaction.com/mozilla_m...
: 926192 928236 943605 1075079 (view as bug list)
Depends on:
Blocks: slimerjs 431221
  Show dependency treegraph
 
Reported: 2013-01-21 14:51 PST by Chris Coulson
Modified: 2016-05-26 16:47 PDT (History)
112 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
-
affected
-
affected
-
affected
affected
affected
affected
fixed
wontfix


Attachments
replace g_slice_set_config with G_SLICE env var (4.68 KB, patch)
2014-01-28 21:01 PST, Karl Tomlinson (:karlt)
mh+mozilla: feedback-
Details | Diff | Splinter Review
firefox-fine-host.txt: Works with NV-GLX on HW system (56.10 KB, text/plain)
2015-03-22 22:45 PDT, Yuri
no flags Details
firefox-hang-VM-in-xorg.txt: Hangs in VM on xorg with SGI-GLX (30.52 KB, text/plain)
2015-03-22 22:45 PDT, Yuri
no flags Details
firefox-fine-VM-in-xnest.txt: Works fine in VM on Xnest w/out GLX (1.75 KB, text/plain)
2015-03-22 22:47 PDT, Yuri
no flags Details
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch (4.37 KB, patch)
2015-06-26 16:31 PDT, Mike Hommey [:glandium]
karlt: review-
nfroyd: review+
Details | Diff | Splinter Review
Replace g_slice_set_config() with G_SLICE environment variable (4.26 KB, patch)
2015-06-30 22:02 PDT, Mike Hommey [:glandium]
karlt: review+
Details | Diff | Splinter Review
Replace g_slice_set_config() with G_SLICE environment variable (7.05 KB, patch)
2015-07-07 04:51 PDT, Mike Hommey [:glandium]
nfroyd: review+
Details | Diff | Splinter Review
Replace g_slice_set_config() with G_SLICE environment variable (6.84 KB, patch)
2015-07-09 01:53 PDT, Mike Hommey [:glandium]
karlt: review+
Details | Diff | Splinter Review

Description Chris Coulson 2013-01-21 14:51:53 PST
On Linux, the glib slice allocator is disabled in |XREMain::XRE_main| by calling |g_slice_set_config| (see bug 431221). However, this no longer works since glib 2.35 because libgobject (which libxul depends on) now has a static initializer which indirectly initializes the slice allocator before |main| is reached (in order to automatically initialize the gobject dynamic type system). This means that the call to g_slice_set_config always fails with the following assertion:

(process:24722): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

See https://bugzilla.gnome.org/show_bug.cgi?id=687763

glib 2.35 is currently the version in Ubuntu 13.04
Comment 1 Alan Robertson 2013-04-30 17:53:38 PDT
Thunderbird doesn't start AT ALL in kubuntu 13.04.  because of this bug.  Or rather, it starts, but the part of it that opens a display window doesn't start.  If I log in with web mail I see that it is filing emails as they arrive according to the rules I've established -- but the display never comes up.

And, in this particular case, I could have been completely unable to report this bug - because you forced me to change my password -- and sent me an email so I could do it :-D.  Of course, since Thunderbird isn't working -- it became more challenging...

Strangely enough, Firefox _does_ start.
Comment 2 Alan Robertson 2013-04-30 18:00:22 PDT
Following the link to the gnome bugzilla -- I ran across a tolerable workaround for the moment: If G_SLICE=always-malloc is in the environment, then it will start.  It still complains, but it starts and appears to work (so far).

This makes it consume more CPU (and Lord knows it already consumes enough CPU), but it does allow Thunderbird to start - which is a good thing.
Comment 3 peten 2013-05-02 12:04:14 PDT
I have the same report from firefox 20.0.1 on arch linux x86_64 running KDE 4.10.2 . it will fail to start 3 or 4 times then will start but can crash and burn instantly or continue all night ..
Comment 4 Alan Robertson 2013-05-02 12:50:14 PDT
OK.  I agree with comment 3.  I have found out that Thunderbird will crash and burn - or just hang.
Comment 5 Ginn Chen 2013-05-03 11:10:41 PDT
I just saw this:
Deprecate and remove g_slice_[sg]et_config.*
https://bugzilla.gnome.org/show_bug.cgi?id=680831
Comment 6 Dan Jacobson 2013-05-03 12:48:42 PDT
Hi everybody. In Bug 672671#c21 they say the warning is harmless in some cases.
So please remove the warning in those cases... we heavy users of remote calls see it once every minute often! Gad. Gasp. Thanks!
Comment 7 Chris Coulson 2013-05-13 08:48:28 PDT
Note, this bug doesn't cause Firefox or Thunderbird to fail to start. People who are having problems with Firefox hanging on startup are most likely hitting https://launchpad.net/bugs/1179554
Comment 8 Mike Hommey [:glandium] 2013-05-21 07:59:43 PDT
(In reply to Chris Coulson from comment #0)
> On Linux, the glib slice allocator is disabled in |XREMain::XRE_main| by
> calling |g_slice_set_config| (see bug 431221). However, this no longer works
> since glib 2.35 because libgobject (which libxul depends on) now has a
> static initializer which indirectly initializes the slice allocator before
> |main| is reached (in order to automatically initialize the gobject dynamic
> type system). This means that the call to g_slice_set_config always fails
> with the following assertion:
> 
> (process:24722): GLib-CRITICAL **: g_slice_set_config: assertion
> `sys_page_size == 0' failed

That's not what the glib code suggests. That error (sys_page_size == 0) happens because the slice allocator is *not* initialized. If it was initialized, sys_page_size would be set (it is set in g_slice_init_nomessage).
Comment 9 Chris Coulson 2013-05-21 08:05:54 PDT
Isn't that the wrong way around? :)

It's asserting that sys_page_size == 0, so the error is displayed because sys_page_size is something other than zero.
Comment 10 Mike Hommey [:glandium] 2013-05-21 08:07:37 PDT
gah these things are confusing.
Comment 11 Daniel Neugart 2013-05-28 11:59:13 PDT
I can confirm this bug for:
Firefox Version 21.0-1 (64bit)
glib Version: 2.36.2-1
Distribution: Arch Linux
Kernel: 3.9.4-1-ARCH

This bug renders Firefox unusable for me, as it crashes almost immediately.

The proposed workaround with "G_SLICE=always-malloc" does not work on my machine.
Comment 12 Wayne Mery (:wsmwk, NI for questions) 2013-06-14 08:17:48 PDT
(In reply to Daniel Neugart from comment #11)
> I can confirm this bug for:
> Firefox Version 21.0-1 (64bit)
> glib Version: 2.36.2-1
> Distribution: Arch Linux
> Kernel: 3.9.4-1-ARCH
> 
> This bug renders Firefox unusable for me, as it crashes almost immediately.
> 
> The proposed workaround with "G_SLICE=always-malloc" does not work on my
> machine.

Hangs?  Or crashes?  
Does it start OK in safe mode?  https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Comment 13 Daniel Neugart 2013-06-14 11:53:08 PDT
(In reply to Wayne Mery (:wsmwk) from comment #12)
> (In reply to Daniel Neugart from comment #11)
> > I can confirm this bug for:
> > Firefox Version 21.0-1 (64bit)
> > glib Version: 2.36.2-1
> > Distribution: Arch Linux
> > Kernel: 3.9.4-1-ARCH
> > 
> > This bug renders Firefox unusable for me, as it crashes almost immediately.
> > 
> > The proposed workaround with "G_SLICE=always-malloc" does not work on my
> > machine.
> 
> Hangs?  Or crashes?  
> Does it start OK in safe mode? 
> https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode

It crashes:
$ firefox 
(process:647): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Segmentation fault (core dumped)
$ firefox --version
(process:702): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Mozilla Firefox 21.0

If I start it in safe-mode it crashes as well:
$ firefox -safe-mode
(process:706): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Segmentation fault (core dumped)

I additionally created a new empty profile and the problem occurs there too.
Comment 14 stradionov 2013-06-18 15:15:09 PDT
(In reply to Daniel Neugart from comment #11)
> I can confirm this bug for:
> Firefox Version 21.0-1 (64bit)
> glib Version: 2.36.2-1
> Distribution: Arch Linux
> Kernel: 3.9.4-1-ARCH
> 
> This bug renders Firefox unusable for me, as it crashes almost immediately.
> 
> The proposed workaround with "G_SLICE=always-malloc" does not work on my
> machine.

Exactly the same thing with thunderbird. This bug is just disastrous for me.
Comment 15 Wayne Mery (:wsmwk, NI for questions) 2013-06-18 17:13:09 PDT
(In reply to stradionov from comment #14)
> Exactly the same thing with thunderbird. This bug is just disastrous for me.

as reported at https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_craches_in_arch_linux
Comment 16 olsen 2013-06-28 05:58:56 PDT
same problemo with icedove on debian testing:
 Icedove: 10.0.12
 Glib Version: 2.36.1-2build1
Firefox works though...
Comment 17 asdfasdfasdf 2013-07-04 01:26:34 PDT
Mozilla Thunderbird 17.0.7 on Linux Mint 15 with Cinnamon 1.8.8:
(process:7895): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

(process:7944): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

(process:7960): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

But Thunderbird works normal so far.
Comment 18 Wayne Mery (:wsmwk, NI for questions) 2013-07-05 07:18:55 PDT
Does this belong in startup?  Or should it move to core, or back to Thunderbird?

Also, https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_craches_in_arch_linux#reply_12417609 states TB23 beta works. Can others confirm?
Comment 19 asdfasdfasdf 2013-07-05 07:30:06 PDT
(In reply to Wayne Mery (:wsmwk) from comment #18)
> Does this belong in startup?  Or should it move to core, or back to
> Thunderbird?
> 
> Also,
> https://getsatisfaction.com/mozilla_messaging/topics/
> thunderbird_craches_in_arch_linux#reply_12417609 states TB23 beta works. Can
> others confirm?

The warnings only appear on startup and everything works normal so far.
Comment 20 Launchpad 2013-07-08 05:52:48 PDT
Nigel Horne added the following comment to Launchpad bug report 1160569:

On 05/07/2013 10:30, iflow wrote:
> (In reply to Wayne Mery (:wsmwk) from comment #18)
>> Does this belong in startup?  Or should it move to core, or back to
>> Thunderbird?
>>
>> Also,
>> https://getsatisfaction.com/mozilla_messaging/topics/
>> thunderbird_craches_in_arch_linux#reply_12417609 states TB23 beta works. Can
>> others confirm?
> The warnings only appear on startup and everything works normal so far.
>
It's not a warning - it's a critical message:

GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

-Nigel





-- 
http://launchpad.net/bugs/1160569
Comment 21 stradionov 2013-07-08 07:20:12 PDT
(In reply to Wayne Mery (:wsmwk) from comment #18)
> Does this belong in startup?  Or should it move to core, or back to
> Thunderbird?
> 
> Also,
> https://getsatisfaction.com/mozilla_messaging/topics/
> thunderbird_craches_in_arch_linux#reply_12417609 states TB23 beta works. Can
> others confirm?

This is not so on my Arch Linux with beta version of Thunderbird installed from AUR. Beta hangs just like normal one.
Comment 22 Daniel Neugart 2013-07-08 12:55:29 PDT
(In reply to Daniel Neugart from comment #11)
> I can confirm this bug for:
> Firefox Version 21.0-1 (64bit)
> glib Version: 2.36.2-1
> Distribution: Arch Linux
> Kernel: 3.9.4-1-ARCH
>  
> This bug renders Firefox unusable for me, as it crashes almost immediately.
> 
> The proposed workaround with "G_SLICE=always-malloc" does not work on my
> machine.

Little update from me:
I'm now using 
Firefox  Ver. 22.0-1
glib 2.36.3-2
Kernel 3.9.9-1-ARCH

And  Firefox does not crash immediately at startup and is normal usable.
Firefox still crashes sometimes though (like once within two hours).
The error message: (process:755): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Still shows up directly after startup of the browser.
Comment 23 bugs.mozilla.07.2013 2013-07-19 12:37:31 PDT
I can confirm this bug for:
Firefox Version 22.0-3.2 (64bit)
glib Version: 2.36.2-1.1
Distribution: openSuSE 12.3
Kernel: 3.7.10-1.16.1-Desktop

Firefox doesn't start, even if I create a new profile or try to use safe-mode.

Terminal shows following errors:


(process:10918): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Fontconfig warning: "/etc/fonts/conf.d/56-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: ignoring german: not a valid language tag
Fontconfig warning: ignoring german: not a valid language tag
Fontconfig warning: ignoring german: not a valid language tag
Fontconfig warning: "/etc/fonts/conf.d/56-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
Comment 24 stradionov 2013-07-31 09:59:48 PDT
I switched to Linux Mint Debian Edition, and guess what, the bug is here too, but, I as far as I remeber, it appeared after update. So I would like to know, where can I find old versions of thunderbird in deb format to test them?
Comment 25 irukandjiandme 2013-08-04 12:55:26 PDT
Confirming this bug for:

Firefox Version: 22.0-1 (64bit)
glib Version: 2.36.3-2
Distribution: Manjaro 0.8.6 Ascella
Kernel: x86_64 Linux 3.10.4-1-MANJARO

GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

Firefox starts, runs at normal speed, and has not crashed yet.
Comment 26 Jonathan Baron 2013-08-26 07:52:36 PDT
(In reply to irukandjiandme from comment #25)
> Confirming this bug for:
> 
> Firefox Version: 22.0-1 (64bit)
> glib Version: 2.36.3-2
> Distribution: Manjaro 0.8.6 Ascella
> Kernel: x86_64 Linux 3.10.4-1-MANJARO
> 
> GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
> 
> Firefox starts, runs at normal speed, and has not crashed yet.

Same thing with Fedora 19.
Nightly 26.0a1 (2013-08-26)
glibc-2.17-13.fc19.x86_64
kernel-3.10.9-200.fc19.x86_64
(I also have glibc.i686 installed. I think Skype likes it.)
Comment 27 Karl Tomlinson (:karlt) 2013-08-26 16:48:47 PDT
g_slice_set_config() is labelled "internal debugging API" (in 2.32.4 at least), and so Gecko should not be using this.
But, unless GLib has been compiled with G_DISABLE_CHECKS, this call will be a no-op, and so will not prevent the app from starting.

It seems unfortunate that different libraries and apps have a need to implement their own allocators.
Comment 28 Mike Hommey [:glandium] 2013-08-26 16:57:03 PDT
(In reply to Karl Tomlinson (:karlt) from comment #27)
> It seems unfortunate that different libraries and apps have a need to
> implement their own allocators.

It seems unfortunate that disabling a library's internal allocator is an "internal debugging API"
Comment 29 chaser.andrey 2013-10-04 04:11:04 PDT
I use Firefox on Linux Gentoo. With vanilla kernel I have only warning in console
(process:31441): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

But when I load Hardened kernel (with PaX) — firefox always crash.

Firefox 24.0
glib-2.36.4-r1
kernel linux-3.11
Comment 30 [:Aleksej] 2013-10-28 07:16:39 PDT
*** Bug 926192 has been marked as a duplicate of this bug. ***
Comment 31 [:Aleksej] 2013-10-28 07:17:10 PDT
*** Bug 928236 has been marked as a duplicate of this bug. ***
Comment 32 Henrik Skupin (:whimboo) 2013-10-28 07:46:28 PDT
Is there anything we could do here to get this fixed for at least Firefox 26 or 27?
Comment 33 bhavana bajaj [:bajaj] 2013-10-28 11:08:26 PDT
(In reply to Henrik Skupin (:whimboo) from comment #32)
> Is there anything we could do here to get this fixed for at least Firefox 26
> or 27?

Would not track for a release given how old the bug is as we will not block a release on this. Although, a low risk uplift can be nominated once a patch is found.

Also CCing a few folks who may be able to help here.
Comment 34 j 2013-10-28 22:50:43 PDT
(In reply to bhavana bajaj [:bajaj] from comment #33)
> (In reply to Henrik Skupin (:whimboo) from comment #32)
> > Is there anything we could do here to get this fixed for at least Firefox 26
> > or 27?
> 
> Would not track for a release given how old the bug is as we will not block
> a release on this. Although, a low risk uplift can be nominated once a patch
> is found.

This makes Firefox 24 on Debian Sid essentially useless because it crashes all the time, is there anything that can be done in the meantime to work around this bug? Any known workaround?
Comment 35 Karl Tomlinson (:karlt) 2013-10-28 22:58:06 PDT
(In reply to jonasa from comment #34)
> This makes Firefox 24 on Debian Sid essentially useless because it crashes
> all the time, is there anything that can be done in the meantime to work
> around this bug? Any known workaround?

See comment 27.

What makes you think that this is causing the crash?
Do you have a stack trace?
Comment 36 Mike Hommey [:glandium] 2013-10-29 03:21:27 PDT
I concur with Karl. In fact, those crashes might be related to bug 920200.
Comment 37 cervantes.raphael12 2013-10-31 12:37:17 PDT
Is it possible that this error causes firefox to start up slowly. Chromium starts up within a second, whereas firefox usually takes up around 3.
Comment 38 kelaskakap 2013-11-22 18:28:26 PST
just reporting this error from my netbook (aspire one 722)

$ strace /usr/bin/firefox
.........................
open("/usr/share/X11/XErrorDB", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=41532, ...}) = 0
read(4, "!\n! Copyright 1993, 1995, 1998  "..., 41532) = 41532
close(4)                                = 0
write(2, "\7", 1)                       = 1
write(2, "###!!! ABORT: XINERAMAIsActive: "..., 166###!!! ABORT: XINERAMAIsActive: BadLength (poly request too large or internal Xlib length error): file /tmp/mozilla-esr24/toolkit/xre/nsX11ErrorHandler.cpp, line 157
) = 166
write(2, "###!!! ABORT: XINERAMAIsActive: "..., 165###!!! ABORT: XINERAMAIsActive: BadLength (poly request too large or internal Xlib length error): file /tmp/mozilla-esr24/toolkit/xre/nsX11ErrorHandler.cpp, line 157) = 165
write(2, "\n", 1
)                       = 1
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
unlink("/home/agan/.mozilla/firefox/zqj9evmo.default/lock") = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x7f81349eb670}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(5137, 5137, SIGSEGV)             = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_TKILL, si_pid=5137, si_uid=1000} ---
+++ killed by SIGSEGV +++
Segmentation fault



bash-4.2$ uname -a                                                                                                                                                                              
Linux darkstar 3.10.17 #1 SMP Wed Oct 23 16:28:33 CDT 2013 x86_64 AMD C-60 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux 
Slackware 14.1 64 bit
using driver amd catalyst/fglrx
Mozilla Firefox 24.1.0
Comment 39 Widya Walesa 2013-11-22 18:58:15 PST
This is interesting. Because while my firefox 24.1esr (slackware 14.1 package) does complaint about the g_slice_set_config, it's still able to run. But my friend's firefox was unable to runs (#38).

I am using ATI Radeon HD 6310 with radeon open source driver (linux 3.12.0) and mesa 9.2.3 (slackware's original package was 9.1.7), instead of amd catalyst/fglrx
Comment 40 Widya Walesa 2013-11-22 19:07:34 PST
(In reply to Widya Walesa from comment #39)
> This is interesting. Because while my firefox 24.1esr (slackware 14.1
> package) does complaint about the g_slice_set_config, it's still able to
> run. But my friend's firefox was unable to runs (#38).
> 
> I am using ATI Radeon HD 6310 with radeon open source driver (linux 3.12.0)
> and mesa 9.2.3 (slackware's original package was 9.1.7), instead of amd
> catalyst/fglrx

This is the output of my firefox strace, the g_slice_set_config part:
open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
write(2, "\n(process:6194): GLib-CRITICAL *"..., 93
(process:6194): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
) = 93
clock_gettime(CLOCK_MONOTONIC, {59677, 545560635}) = 0
pipe([3, 4])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb747e768) = 6196
close(4)                                = 0
rt_sigaction(SIGFPE, {0xb48ea3bd, [], SA_STACK|SA_RESTART|SA_SIGINFO}, {SIG_DFL, [], 0}, 8) = 0

This the xinerama part:
writev(4, [{"\2 \4\0\267\2\0\0\0\10\0\0\0\0B\0\20\0\6\0\r\0 \4_NET_WOR"..., 40}, {NULL, 0}, {"", 0}], 3) = 40
poll([{fd=4, events=POLLIN}], 1, -1)    = 1 ([{fd=4, revents=POLLIN}])
recv(4, "\1\0\370\2\0\0\0\0L\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0) = 32
recv(4, 0xb72af058, 4096, 0)            = -1 EAGAIN (Resource temporarily unavailable)
recv(4, 0xb72af058, 4096, 0)            = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"b \4\0\10\0\0\0", 8}, {"XINERAMA", 8}, {"", 0}], 3) = 16
poll([{fd=4, events=POLLIN}], 1, -1)    = 1 ([{fd=4, revents=POLLIN}])
recv(4, "\1\0\371\2\0\0\0\0\1\214\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0) = 32
recv(4, 0xb72af058, 4096, 0)            = -1 EAGAIN (Resource temporarily unavailable)
recv(4, 0xb72af058, 4096, 0)            = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
Comment 41 [:Aleksej] 2013-11-30 12:18:41 PST
*** Bug 943605 has been marked as a duplicate of this bug. ***
Comment 42 Karl Tomlinson (:karlt) 2014-01-28 21:01:35 PST
Created attachment 8367119 [details] [diff] [review]
replace g_slice_set_config with G_SLICE env var
Comment 43 Mike Hommey [:glandium] 2014-01-28 21:31:25 PST
Comment on attachment 8367119 [details] [diff] [review]
replace g_slice_set_config with G_SLICE env var

Review of attachment 8367119 [details] [diff] [review]:
-----------------------------------------------------------------

Considering g_slice_set_config is only deprecated at the moment, I'd rather use it and fallback to environment variables if it can't be used.
Also, you're only touching browser, while at least b2g and xulrunner have the same initialization code (which is why it was better in nsAppRunner in the first place, but i guess it's too late there).
Comment 44 Karl Tomlinson (:karlt) 2014-01-28 23:07:10 PST
On irc, glandium indicated that he would prefer to dlopen libglib (before anything depends on libgobject) and use the deprecated g_slice_set_config internal debugging api, than follow Matthias' suggestion to use GSLICE=always-malloc, because of the awkwardness of putenv/unsetenv.
Comment 45 Mike Hommey [:glandium] 2014-01-29 15:28:34 PST
(In reply to Karl Tomlinson (back Jan 28 :karlt) from comment #44)
> On irc, glandium indicated that he would prefer to dlopen libglib (before
> anything depends on libgobject) and use the deprecated g_slice_set_config
> internal debugging api, than follow Matthias' suggestion to use
> GSLICE=always-malloc, because of the awkwardness of putenv/unsetenv.

Note you can actually just use g_slice_set_config directly, and build with -lglib-2.0. Makes it less easy to do that centrally, though.
Comment 46 el.zato.ve 2014-02-11 21:00:19 PST
Confirming as of february 11th, this bug has rendered both firefox and thunderbird completely unusable under kubuntu 13. I re-downloaded the newest firefox 27 and still no luck.

:~$ firefox

(process:5934): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
:~$ thunderbird

(process:6095): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Comment 47 John Hughes 2014-02-16 11:35:08 PST
This bug locks up Thunderbird in the Arch Linux Open Box Manjaro distribution (both 32 & 64 bit) after the update packages below are installed.  The error popped up between the last iso image (11-26-2013) and now. The version 28.0 Firefox beta package runs fine.  Since Arch Linux is a rolling distribution one (or more) of the listed update packages are causing the error.  If I don't install the package updates both Thunderbird and Firefox work fine but they break after the package updates are applied.  Someone smarter than me might be able guess which package is most likely to be causing the problem.

Here is the update list:

There are 195 outdated packages in your system:

Name
Outdated version
Available version

acpid [Package ID,typical] 2.0.20-1 [Outdated Version,typical] 2.0.21-1 [New Version,typical]
archlinux-keyring 20131027-1 20140124-1
btrfs-progs 0.20rc1.3-2 3.12-1
catfish 0.8.2-2 1.0.0-1
cifs-utils 6.1-1 6.2-1
colord 1.0.4-1 1.0.6-1
compton 0.1_beta1-1 0.1_beta2-1
conky 1.9.0-2 1.9.0-4
coreutils 8.21-2 8.22-2
cpupower 3.12-1 3.13-1
cronie 1.4.9-5 1.4.11-1
cryptsetup 1.6.2-2 1.6.3-2
curl 7.33.0-3 7.35.0-1
dbus 1.6.16-1 1.8.0-1 
device-mapper 2.02.104-1 2.02.105-1 
dhclient 4.2.5.p1-2 4.2.5.p1-3 
dhcpcd 6.1.0-1 6.2.1-1 
dialog 1:1.2_20130928-1 1:1.2_20140112-1 
dirmngr 1.1.1-1 1.1.1-2 
dnsmasq 2.67-2 2.68-1 
dosfstools 3.0.23-1 3.0.25-1 
e2fsprogs 1.42.8-2 1.42.9-1 
file 5.15-1 5.16-1 
freetype2 2.5.0.1-2 2.5.2-1 
gcr 3.10.1-1 3.10.1-2 
gdbm 1.10-3 1.11-1 
gdk-pixbuf2 2.30.1-1 2.30.4-1 
gettext 0.18.3.1-2 0.18.3.2-1 
ghostscript 9.10-1 9.10-3 
glibc 2.18-10 2.18-12 
gnome-keyring 3.10.1-1 3.10.1-2 
gnome-vfs 2.24.4-7 2.24.4-8 
gnupg 2.0.22-1 2.0.22-2 
gnutls 3.2.6-1 3.2.10-1 
gparted 0.16.2-1 0.17.0-2 
graphite 1:1.2.3-1 1:1.2.4-1 
grep 2.15-1 2.16-1 
grub 2.00.5086-1 2.02.beta2-4 
gsfonts 1.0.7pre44-3 1.0.7pre44-4 
gst-plugins-base-libs 1.2.1-1 1.2.2-1 
gstreamer 1.2.1-1 1.2.2-1 
gtk3 3.10.4-1 3.10.7-1 
gufw 13.10.3-1 14.04.0-1 
gummiboot 38-1 43-2 
gvfs 1.18.3-1 1.18.3-3 
gvfs-afc 1.18.3-1 1.18.3-3 
gvfs-smb 1.18.3-1 1.18.3-3 
harfbuzz 0.9.23-1 0.9.24-1 
harfbuzz-icu 0.9.23-1 0.9.24-1 
haveged 1.7.c-3 1.8-1 
hwids 20130607-1 20130915.1-1 
hwinfo 20.1-2 21.0-1 
imlib2 1.4.5-6 1.4.6-1 
inetutils 1.9.1.341-1 1.9.2-1 
intel-dri 9.2.3-2 10.0.3-1 
intel-ucode 20130906-1 20140122-1 
inxi 1.9.16-1 1.9.18-1 
iproute2 3.11.0-1 3.12.0-1 
iptables 1.4.20-1 1.4.21-1 
jasper 1.900.1-9 1.900.1-10 
kmod 15-1 16-1 
krb5 1.11.4-1 1.12.1-1 
ldns 1.6.16-1 1.6.17-1 
lib32-freetype2 2.5.0.1-1 2.5.2-1 
lib32-gcc-libs 4.8.2-4 4.8.2-7 
lib32-glibc 2.18-10 2.18-12 
lib32-intel-dri 9.2.3-2 10.0.3-1 
lib32-libdrm 2.4.49-1 2.4.52-1 
lib32-libgcrypt 1.5.3-1 1.6.0-1 
lib32-libxcb 1.9.1-1 1.10-1 
lib32-llvm-libs 3.3-1 3.4-1 
lib32-mesa 9.2.3-2 10.0.3-1 
lib32-mesa-libgl 9.2.3-1 10.0.3-1 
lib32-pcre 8.33-1 8.34-1 
lib32-systemd 208-1 208-2 
libbluray 0.4.0-1 0.5.0-1 
libcap 2.22-5 2.24-1 
libcdio 0.90-2 0.92-1 
libcdio-paranoia 10.2+0.90+1-1 10.2+0.90+1-2 
libdrm 2.4.49-1 2.4.52-1 
libgcrypt 1.5.3-1 1.6.1-1 
libgnome-keyring 3.10.1-1 3.10.1-2 
libjpeg-turbo 1.3.0-3 1.3.0-4 
libldap 2.4.37-1 2.4.39-1 
libmbim 1.4.0-1 1.6.0-1 
libnl 3.2.22-1 3.2.23-1 
libpcap 1.4.0-1 1.5.3-1 
libpipeline 1.2.4-1 1.2.6-1 
libpng 1.6.6-1 1.6.8-1 
libqmi 1.4.0-2 1.8.0-1 
librsvg 1:2.40.1-1 1:2.40.1-3 
libsecret 0.16-1 0.16-2 
libtasn1 3.3-2 3.4-1 
libvorbis 1.3.3-1 1.3.4-1 
libwebp 0.3.1-3 0.4.0-1 
libx86emu 1.1-29 1.1-30 
libxcb 1.9.1-2 1.10-1 
libxfce4ui 4.11.0-3 4.11.0-4 
libxfont 1.4.6-1 1.4.7-1 
libxft 2.3.1-1 2.3.1-2 
libxkbcommon 0.3.1-1 0.4.0-1 
libxslt 1.1.28-2 1.1.28-3 
linux-api-headers 3.10.6-1 3.12.4-1 
linux-firmware 20131013.7d0c7a8-1 20140123.418320b-1 
linux310 3.10.20-1 3.10.28-1 
linux310-ndiswrapper 1.58-10 1.59-5 
llvm-libs 3.3-1 3.4-1 
lua 5.2.2-1 5.2.3-1 
lvm2 2.02.104-1 2.02.105-1 
lxappearance 0.5.3-2 0.5.5-1 
lxpolkit 0.1.0-2 0.1.0-3 
man-db 2.6.5-1 2.6.6-1 
man-pages 3.54-1 3.57-1 
manjaro-keyring 20120504-1 20140209-1 
manjaro-release 0.8.8-1 0.8.9rc2-1 
mesa 9.2.3-2 10.0.3-1 
mesa-libgl 9.2.3-1 10.0.3-1 
mhwd 0.2.8-4 0.3.2-1 
mhwd-catalyst 13.4-4 13.12-1 
mhwd-db 0.2.8-2 0.3.2-1 
mhwd-nvidia 331.20-1 331.38-1 
mhwd-nvidia-legacy 304.116-1 304.119-1 
mkinitcpio 0.15.0-1 16-2 
mobile-broadband-provider-info 20120614-1 20120614-2 
modemmanager 1.0.0-1 1.2.0-2 
mpfr 3.1.2.p4-1 3.1.2.p5-1 
nbd 3.4-1 3.7-1 
ndiswrapper-utils 1.58-2 1.59-1 
nfs-utils 1.2.8-9 1.2.9-5 
nspr 4.10.2-1 4.10.3-1 
nss 3.15.3-1 3.15.4-1 
ntp 4.2.6.p5-17 4.2.6.p5-18 
openssh 6.4p1-1 6.5p1-2 
openssl 1.0.1.e-5 1.0.1.f-1 
os-prober 1.58-1 1.63-1 
p7zip 9.20.1-8 9.20.1-9 
pacman-mirrorlist 20131009-1 20140124-2 
pango 1.36.1-1 1.36.2-1 
pciutils 3.2.0-4 3.2.1-1 
pcre 8.33-2 8.34-2 
perl 5.18.1-1 5.18.2-2 
poppler 0.24.3-1 0.24.5-1 
poppler-glib 0.24.3-1 0.24.5-1 
procps-ng 3.3.8-3 3.3.9-2 
pth 2.0.7-4 2.0.7-5 
pv 1.4.12-1 1.5.1-1 
pyalpm 0.6.2.1-2 0.6.2.2-1 
python 3.3.2-2 3.3.3-1 
python-dbus-common 1.2.0-1 1.2.0-2 
python2 2.7.5-2 2.7.6-1 
python2-dbus 1.2.0-1 1.2.0-2 
python2-distutils-extra 2.37-1 2.38-1 
python2-mako 0.9.0-1 0.9.1-1 
python2-pillow 2.2.1-2 2.3.0-3 
refind-efi 0.7.4-1 0.7.7-1 
s-nail 14.4.5-1 14.5.2-3 
slim 1.3.6-2 1.3.6-3 
sqlite 3.8.1-2 3.8.3-1 
sudo 1.8.8-1 1.8.9.p4-1 
syslog-ng 3.5.1-2 3.5.3-1 
systemd 208-2 208-10 
systemd-sysvcompat 208-2 208-10 
tcpdump 4.4.0-2 4.5.1-1 
terminus-font 4.38-2 4.38-4 
tevent 0.9.18-1 0.9.19-1 
tzdata 2013h-1 2013i-1 
unrar 1:5.0.13-1 1:5.0.14-1 
uriparser 0.7.8-2 0.8.0-1 
usb_modeswitch 2.0.1-1 2.1.0-1 
util-linux 2.24-1 2.24.1-1 
vpnc 0.5.3.svn527-1 0.5.3.svn527-2 
wayland 1.3.0-1 1.4.0-1 
webkitgtk 2.2.2-1 2.2.4-2 
wget 1.14-3 1.15-1 
wireless_tools 29-8 30.pre9-1 
xcb-proto 1.9-1 1.10-1 
xcursor-vanilla-dmz-aa 0.4.3-1 0.4.4-1 
xdg-utils 1.1.0.git20130520-1 1.1.0.git20140207-1 
xextproto 7.2.1-1 7.3.0-1 
xf86-input-acecad 1.5.0-6 1.5.0-7 
xf86-input-aiptek 1.4.1-6 1.4.1-7 
xf86-input-evdev 2.8.2-1 2.8.2-2 
xf86-input-joystick 1.6.2-2 1.6.2-3 
xf86-input-keyboard 1.8.0-1 1.8.0-2 
xf86-input-mouse 1.9.0-1 1.9.0-2 
xf86-input-synaptics 1.7.1-1 1.7.3-1 
xf86-input-void 1.4.0-5 1.4.0-6 
xf86-input-wacom 0.23.0-1 0.23.0-2 
xf86-video-intel 2.21.15-1 2.99.909-2 
xkeyboard-config 2.10.1-1 2.11-2 
xorg-server 1.14.4-1 1.15.0-5 
xorg-server-common 1.14.4-1 1.15.0-5 
xorg-xinit 1.3.3-2 1.3.3-3 
xproto 7.0.24-1 7.0.25-1 
xterm 297-1 301-1
Comment 48 mozilla 2014-02-18 14:32:41 PST
Same problem with Mozilla Firefox 27.0.1 on FreeBSD 10.0-STABLE / amd64 (and same for some previous versions of Firefox and FreeBSD).

When I launch it, I get the error:

GLib-CRITICAL **: void g_slice_set_config(GSliceConfig, gint64): assertion `sys_page_size == 0' failed

A firefox process is running, but no window is displayed.

To be able to run it, I have to enter `firefox -safe-mode' and reset it.
Comment 49 ubucatz 2014-02-25 02:54:26 PST
This problem still exists on the upcoming Ubuntu 14.04

ubucatz@ubuntu:~$ firefox

(process:3489): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:3489): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:3489): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:3489): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:3489): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Segmentation fault (core dumped)

ubucatz@ubuntu:~$ thunderbird

(process:3503): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(thunderbird:3503): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(thunderbird:3503): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(thunderbird:3503): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(thunderbird:3503): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Segmentation fault (core dumped)
Comment 50 marius.spix 2014-03-07 13:12:08 PST
Similar issue with Seamonkey 2.24 on Gentoo 64-bit. I also tried compiling with -O0 and the debug use flag. The GLib message appears (I use GLib 2.36.4). Some UI actions, especially scrollbar (seldom) and dropdown menus (almost everytime) lead to crashes with the message "Speicherzugriffsfehler" (don't know the non-localized message, but it means "Memory Access Error"). The crash is also not mentioned in about:telemetry, even if telemetry is enabled. Breakpad does not even realize the crash and I am unable to provide a dump.

In safe-mode there is a chance that the message "###!!! [Child][MessageChannel::SendAndWait] Error: Channel error: cannot send/recv" appears before. In normal mode the "no loadgroup notificationCallbacks" message from the Google phishing filter sometimes shows up.
Comment 51 Germano Massullo 2014-03-19 09:05:59 PDT
Very slow user interface in Fedora 20.
Comment 52 YF (Yang) 2014-03-21 16:42:02 PDT
*** Bug 986735 has been marked as a duplicate of this bug. ***
Comment 53 Ginn Chen 2014-03-21 17:10:09 PDT
YF, my understanding is this bug will not cause a crash like Bug 986735.

The "GLib-CRITICAL" warning is printed when Firefox starts.
It may cause a crash at startup on some systems. (although I don't think it really happens)
But it should not cause a crash when you open "2 tabs".

See comment 34, comment 35, comment 36.
Comment 54 j 2014-03-21 18:44:57 PDT
(In reply to Ginn Chen from comment #53)
> YF, my understanding is this bug will not cause a crash like Bug 986735.
> 
> The "GLib-CRITICAL" warning is printed when Firefox starts.
> It may cause a crash at startup on some systems. (although I don't think it
> really happens)
> But it should not cause a crash when you open "2 tabs".
> 
> See comment 34, comment 35, comment 36.

I jumped to premature conclusions, I have no evidence this is this bug what's causing my FF28 to crash. I just saw the same error message in FF as in Thunderbird and they seem to crash in a similar fashion and comment 3 was consistent with my experience.
See comment 27, Karl Tomlinson seems to know what he is talking about. My glib is not built with G_DISABLE_CHECKS and so according to Karl, should be a no-op, a 'do nothing'-instruction. I've never seen a crash on an empty startup.
Sorry for spreading confusion.
Firefox does have some major problem on Linux, just guess this bug is not the root cause.
Perhaps bug 920200 as suggested by comment 36, tho the last word over there is 'it shouldn't really happen'.
Comment 55 xtimox 2014-04-09 07:18:22 PDT
Same issue here on Fedora 20:

$ uname -a
Linux timo-usersys 3.12.6-300.fc20.x86_64 #1 SMP Mon Dec 23 16:44:31 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ firefox -v

(process:17784): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 26.0

$ cat /etc/redhat-release 
Fedora release 20 (Heisenbug)
Comment 56 Steve Roylance 2014-04-11 06:47:01 PDT
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
starting always produces this error
$ thunderbird &                                                       
Wed Apr  2 11:43:39 EST 2014                                                                      
[1] 15660                                                                                         
$                                                                            
(process:15660): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Comment 57 Daniele "Mte90" Scasciafratte 2014-04-13 13:53:46 PDT
I confirm this bug in Firefox 30 on Debian Sid with libc 2.18-4.

I get this:
(process:5049): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(iceweasel:5049): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(iceweasel:5049): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(iceweasel:5049): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(iceweasel:5049): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Comment 58 Alexandre Novakovski 2014-04-17 00:48:19 PDT
Hi :)
Same here.

Debian Jessie Iceweasel 30.0a2 (2014-04-11).

firefox --sync

(process:8910): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(iceweasel:8910): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(iceweasel:8910): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(iceweasel:8910): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(iceweasel:8910): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Comment 59 Carsten 2014-04-19 12:43:57 PDT
I can confirm this on Arch x64 with FF 28
Comment 60 Launchpad 2014-04-22 06:44:25 PDT
Wtwine added the following comment to Launchpad bug report 1160569:

The same problem appeared when I upgraded from Ubuntu 12.04 to 14:04.

I can no longer start Thunderbird.

I get the following when trying to run Thunderbird in terminal:

(process:14430): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(thunderbird:14430): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(thunderbird:14430): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(thunderbird:14430): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(thunderbird:14430): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
[calBackendLoader] Using libical backend at /home/wayne/.thunderbird/s4f56rex.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical.manifest

(thunderbird:14430): GLib-GObject-WARNING **: cannot register existing type 'DbusmenuMenuitem'

(thunderbird:14430): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(thunderbird:14430): GLib-GObject-CRITICAL **: g_param_spec_object: assertion 'g_type_is_a (object_type, G_TYPE_OBJECT)' failed

(thunderbird:14430): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion 'G_IS_PARAM_SPEC (pspec)' failed


-- 
http://launchpad.net/bugs/1160569
Comment 61 Shawn 2014-04-29 15:22:29 PDT
Bug report
Mozilla Firefox 29.0
$ uname -a

Linux I1520 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:08:14 UTC 2014 i686 i686 i686 GNU/Linux

$ firefox

(process:4458): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:4458): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:4458): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:4458): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:4458): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Comment 62 amos083 2014-04-29 22:54:26 PDT
Firefox 28.0
Glib 2.0
Debian jessie/sid
Kernel 3.2.0-3-686-pae

Firefox prints the message and dumps core, but continues to start normally.

Does anyone has a solution or workaround?  This is annoying.

Thanks much,
Amos
Comment 63 Underpass 2014-05-07 10:12:04 PDT
Version 29 and 30 are affected as well
Comment 64 K D 2014-05-26 12:07:27 PDT
$ uname -a
Linux trunk 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux

$ cat /etc/*release | head -2
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04

$ thunderbird --version

(process:4934): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
 Thunderbird 24.5.0
Comment 65 Steve Roylance 2014-06-16 01:18:48 PDT
$ thunderbird --version

(process:1274): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
 Thunderbird 24.6.0

$ uname -a
Linux keflavik.iceland.local 3.14.6-200.fc20.x86_64 #1 SMP Sun Jun 8 01:21:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Comment 66 Karl Tomlinson (:karlt) 2014-06-16 02:29:38 PDT
Please file separate bugs, with stack traces for crashes.
Comment 67 Daniele "Mte90" Scasciafratte 2014-06-16 04:07:06 PDT
Firefox not crash, the error appaer only in the shell (even in the nighly).
Comment 68 Wayne Mery (:wsmwk, NI for questions) 2014-06-16 04:55:55 PDT
So this is strictly a warning and does not prevent startup?  
What about comment 1, 3, ...?
Comment 69 Daniele "Mte90" Scasciafratte 2014-06-16 05:08:20 PDT
On Firefox Nightly, on Icewasel 32, Icedove 30 on debian sid i get only this error in console but the software works.

I think that a fix improve the perfomance in many distro, if the software crash on ubuntu or other I think would exist many reports of crash about this.

In the italian community we have a topic about ubuntu http://forum.mozillaitalia.org/index.php?topic=58583.0 and a thread about this ticket http://forum.mozillaitalia.org/index.php?topic=60934.0.
Comment 70 Karl Tomlinson (:karlt) 2014-06-16 15:04:22 PDT
(In reply to Wayne Mery (:wsmwk) from comment #68)
> So this is strictly a warning and does not prevent startup?  

Yes.

> What about comment 1, 3, ...?

I don't see any crash stack traces linking the crashes to this assertion failure.

Everyone on modern systems will be getting this assertion failure, including those that crash on startup.
Comment 71 Launchpad 2014-06-17 06:13:36 PDT
Nigel Horne added the following comment to Launchpad bug report 1160569:

No.  A warning would not say "critical".

-- 
http://launchpad.net/bugs/1160569
Comment 72 Wayne Mery (:wsmwk, NI for questions) 2014-06-17 06:23:21 PDT
(In reply to Karl Tomlinson (needinfo?:karlt) from comment #70)
> Everyone on modern systems will be getting this assertion failure, including
> those that crash on startup.

Thanks for the info. So this is a common issue. (and misleading for the uneducated)
Comment 73 MSN 2014-06-19 20:50:30 PDT
Ok, if [(process:1032): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed] is a warning.

After a few minutes a *SEGMENTATION* fault. and the whole browser window goes for a toss.

This is a very very much essential application. I can say that I'm addicted to firefox as I'm using it from a very long time.

I have started the firefox in the terminal by disabling the GTK modules [GTK_IM_MODULE=xim /usr/bin/firefox]. But not happy with this work around too.

Request good people at mozilla to provide a fix ASAP. This a very critical issue.
Comment 74 Karl Tomlinson (:karlt) 2014-06-19 21:24:25 PDT
(In reply to MSN from comment #73)
> I have started the firefox in the terminal by disabling the GTK modules
> [GTK_IM_MODULE=xim /usr/bin/firefox]. But not happy with this work around
> too.

That's interesting.  Would you be able to file a new bug, cc me and report which module was causing the problem, please?
Comment 75 MSN 2014-06-19 23:33:24 PDT
Disabled scim gtk immodule and started firefox with command [GTK_IM_MODULE=xim /usr/bin/firefox]
in the terminal. After some couple of hours FF crashed saying *Segmentation* fault.

Though the crash is not very immediate. I'm on Slackware64 14.1 [Kernel - 3.10.17, & with No multilib enabled]. But this needs a quick attention.

Even though i have Slackware64 14.0 in my another HDD [kernel - 3.2.29, & with Multilib enabled] their the any version of firefox works like a charm.
Comment 76 rablanken13 2014-08-08 19:37:35 PDT
Version 31 is affected. 

Output of `firefox`:
(process:20438): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 31.0

This is causing problems with the unit testing program "windmill". It is causing it to be stuck at "Setting document.domain environment"

Output of `windmill shell firefox http://google.com`:
1407551686573	addons.xpi	WARN	Add-on webapps-team@lists.launchpad.net is missing bootstrap method install
(firefox:20553): LIBDBUSMENU-GTK-CRITICAL **: dbusmenu_menuitem_property_set_shortcut: assertion 'gtk_accelerator_valid(key, modifier)' failed
Comment 77 George R. Goffe 2014-08-08 20:03:35 PDT Comment hidden (me-too)
Comment 78 jeffrey.cliff 2014-08-08 20:08:19 PDT Comment hidden (me-too)
Comment 79 Dan Jacobson 2014-08-09 17:37:12 PDT
Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0 Iceweasel/33.0a2
Comment 80 bull500 2014-08-26 08:14:49 PDT Comment hidden (me-too)
Comment 81 Jeffery Small 2014-09-03 13:59:25 PDT
Xubuntu 14.04.1

Every time I attempt to run the apport-bug bug reporting command, it tries to load data into an instance of firefox [30, 31, 32] which repeatedly fails with Firefox reporting:

------------------------------
File not found
Firefox cannot find the file at <current working dir path>/https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/<long_id_string>
------------------------------

In the terminal window where the command is launched, I get the following:

------------------------------
% apport-bug <package>

** (apport-gtk:13523): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-t4rIGS23K1: Connection refused

(process:13996): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
------------------------------

The first warning is a ubuntu bug.  The second is apparently issued by Firefox and is likely responsible for the command failing.
Comment 82 David Rankin 2014-10-02 01:59:21 PDT
This Crash is occurring on openSuSE 13.1 with Thunderbird 24.7. Desktop is KDE.

The following 4 crash reports were submitted:

bp-7eacae3e-214c-4346-94d6-725ef2141002
bp-b44db91b-5d2d-441b-b156-9a5402141002
bp-f6cc075e-2bf3-4293-8c5f-756eb2141002
bp-bd80ba8a-4ca8-4560-94dc-114122141002

Starting at the command line after the crash gives the following output -- then the crash reporter appears (I can't even start tbird with restarting):

$ thunderbird

(process:471): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(thunderbird:471): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(thunderbird:471): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(thunderbird:471): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(thunderbird:471): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
ACR (Component): component init
03:47 alchemy:~/dev/prg/asm/nasm>
(crashreporter:494): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(crashreporter:494): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(crashreporter:494): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(crashreporter:494): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Comment 83 Jason 2014-10-14 10:23:44 PDT
"Me too":
$ uname -a
Linux pangea 3.16.4-200.fc20.x86_64 #1 SMP Mon Oct 6 12:57:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

--------------------------------------
$ firefox

(process:3668): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised

(process:3668): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:3668): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised

Trace/BPT trap (core dumped)
------------------------------

Sometimes I see the "trap", but usually it just crashes and I only get the Mozilla crash reporter popping up.

Here is a typical report:
https://crash-stats.mozilla.com/report/index/47cbf288-d2bc-4cbb-93e4-1db5c2141013

Reason "SIGSEGV"

I get these hourly usually; sometimes in rapid succession every few minutes, then it 'calms down' for an hour or two.  I can never go more than a couple hours w/o a crash.

I have tried safe mode, clean, fresh profile, new userID.  If I boot into Fedora 17 it runs perfectly (including the latest v33).  Fedora 20 has constant crashes.
Comment 84 Victor Bjelkholm 2014-10-28 04:49:07 PDT Comment hidden (me-too)
Comment 85 brunoric 2014-12-19 10:04:28 PST Comment hidden (me-too)
Comment 86 alex94puchades 2014-12-20 05:01:14 PST Comment hidden (me-too)
Comment 87 7clement 2015-01-04 13:07:59 PST
[Tracking Requested - why for this release]:
ubuntu 14.04, PC hardware, intel core i3, 4Go Ram, 
>uname -a
Linux 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>synaptic : (run in GUI) asked "dpkg --configure -a" to be run
>dpkg --configure -a
Paramétrage de mime-support (3.54ubuntu1) ...
Paramétrage de firefox (34.0+build2-0ubuntu0.14.04.1) ...
Please restart all running instances of firefox, or you will experience problems.
>dpkg -l 'libglib2.0*'
[...]
ii  libglib2.0-bin 2.40.2-0ubun amd64        Programs for the GLib library

>firefox -v
(process:6202): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 34.0

Note : Firefox runs fine from the guest account on the same PC/Ubuntu
Note : My system is relatively fresh from install appart from heavy fiddling to get OpenCL to work with GeForce GTX 650/PCIe/SSE2 graphics card. various flavors of drivers were installed and removed in the process.

Not fixed. I hope this helps.
Comment 88 Martin Stránský 2015-01-05 05:15:50 PST
g_slice_set_config()(In reply to Karl Tomlinson (:karlt) from comment #44)
> On irc, glandium indicated that he would prefer to dlopen libglib (before
> anything depends on libgobject) and use the deprecated g_slice_set_config
> internal debugging api, than follow Matthias' suggestion to use
> GSLICE=always-malloc, because of the awkwardness of putenv/unsetenv.

GSLICE=always-malloc ENV is the only way how to disable it in glib >= 2.35. g_slice_set_config() actually does nothing because it tweaks only a local copy of slice_config which is not send to the allocator. The actual slice_config_init() config routine has its SliceConfig *config for that.
Comment 89 Lawrence Mandel [:lmandel] (use needinfo) 2015-01-13 13:27:32 PST
With the release of Firefox 35 today, Firefox 34 is EOL. If you think this warrants tracking, please request tracking for a current release. Note that as this is an old bug, unless there has been a recent change in severity, it is unlikely that this will be fixed before Firefox 38 (current Nightly).
Comment 90 jeffrey.cliff 2015-01-13 13:56:29 PST
How can we request tracking for current release?  This is clearly still a bug in FF38 nightly.
Comment 91 Daniele "Mte90" Scasciafratte 2015-01-14 02:12:57 PST
With the developer edition (36) and the 35 the problem persists.
Comment 92 Launchpad 2015-01-14 08:46:18 PST
Nigel Horne added the following comment to Launchpad bug report 1160569:

On 1/13/15 4:27 PM, Lmandel wrote:
> With the release of Firefox 35 today, Firefox 34 is EOL. If you think
> this warrants tracking, please request tracking for a current release.
> Note that as this is an old bug, unless there has been a recent change
> in severity, it is unlikely that this will be fixed before Firefox 38
> (current Nightly).
>
You tell me.  Does the new version fix the problem?



-- 
http://launchpad.net/bugs/1160569
Comment 93 jrussey 2015-01-19 12:12:47 PST
Have Thunderbird 31.3.0
Mozilla Firefox 35.0
Linux localhost.localdomain 3.17.8-200.fc20.x86_64 #1 SMP Thu Jan 8 23:26:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

My wife was trying to change something in her Thunderbird calendar this morning, when it crashed.
Gives the following error message: 

marleen@localhost ~$ thunderbird &
[1] 5074
marleen@localhost ~$ 
(process:5074): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
[calBackendLoader] Using libical backend at /home/marleen/.thunderbird/he3scsnk.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical.manifest

************************************
Funny thing is, I tried to open it this evening via the command line and it opened with a "Write" email document with her home data file attached. I sent it to myself and received the message - with her home file attached. There was no record of this in her Yahoo sent documents - checked via Firefox browser.

Shut down and restart; start Thunderbird via command line and get same error message, however now a blank calendar page opens with the header: "January 18 - February 14, 2015 - Mozilla Thunderbird"
My wife says this was the file she was trying to modify when it crashed.

************************************

Was not aware that Firefox was connected to this till started reading these error messages.

Get the following error message when I open Firefox from the command line:

marleen@localhost ~$ firefox &
[1] 5590
marleen@localhost ~$ firefox &
[2] 6403
[1]   Done                    firefox
marleen@localhost ~$ error: An exception occurred.
Traceback (most recent call last):
  File "resource://gre/modules/Promise-backend.js:744", line 7, in this.PromiseWalker.walkerLoop
  File "resource://gre/modules/Promise-backend.js:865", line 23, in Handler.prototype.process
  File "resource:///modules/sessionstore/SessionStore.jsm:948", line 9, in SessionStoreInternal.onBeforeBrowserWindowShown/<
  File "resource:///modules/sessionstore/SessionStore.jsm:787", line 9, in ssi_onLoad
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/system/events.js:55", line 7, in Observer<.observe
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/addon/runner.js:58", line 5, in wait/<
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/addon/runner.js:87", line 19, in startup
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
  File "resource://fbdislike-at-doweb-dot-fr/fdislike/lib/main.js:2", line 15, in 
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:286", line 7, in require
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
  File "resource://fbdislike-at-doweb-dot-fr/addon-kit/lib/page-mod.js:9", line 28, in 
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:286", line 7, in require
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/content.js:9", line 20, in 
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:286", line 7, in require
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
TypeError: redeclaration of variable self
error: An exception occurred.
Traceback (most recent call last):
  File "resource://gre/modules/Promise-backend.js:744", line 7, in this.PromiseWalker.walkerLoop
  File "resource://gre/modules/Promise-backend.js:865", line 23, in Handler.prototype.process
  File "resource:///modules/sessionstore/SessionStore.jsm:948", line 9, in SessionStoreInternal.onBeforeBrowserWindowShown/<
  File "resource:///modules/sessionstore/SessionStore.jsm:787", line 9, in ssi_onLoad
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/system/events.js:55", line 7, in Observer<.observe
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/addon/runner.js:58", line 5, in wait/<
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/addon/runner.js:87", line 19, in startup
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
  File "resource://fbdislike-at-doweb-dot-fr/fdislike/lib/main.js:2", line 15, in 
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:286", line 7, in require
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
  File "resource://fbdislike-at-doweb-dot-fr/addon-kit/lib/page-mod.js:9", line 28, in 
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:286", line 7, in require
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/content.js:9", line 20, in 
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:286", line 7, in require
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:181", line 3, in load
  File "resource://fbdislike-at-doweb-dot-fr/api-utils/lib/cuddlefish.js:146", line 19, in evaluate
TypeError: redeclaration of variable self
Running global cleanup code from study base classes.

*******************************
Also, her homepage which is http://www.google.es    comes up as:

https://www.google.es/?gfe_rd=cr&ei=_Fy9VMvuGqWp8wfQ1oHgCg


********************************

If you would like more information, just ask.

Thanks.
Comment 94 jrussey 2015-02-02 13:26:52 PST
ok. got the bloody thing to start via:

    /usr/bin/thunderbird -safe-mode

and deleting add-ons; still get:

   (process:28133): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

But I don't really care anymore. 
Anyway, hope this helps someone...
Comment 95 Germano Massullo 2015-02-03 03:01:01 PST Comment hidden (advocacy)
Comment 96 Wyatt Ward 2015-02-17 12:03:18 PST Comment hidden (me-too)
Comment 97 gregoirer 2015-03-10 10:34:18 PDT
firefox -v

(process:8553): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 36.0.1

Even if firefox works properly. This warning should not appear. Is there some possible settings to avoid such warning to appear ?
Comment 98 Launchpad 2015-03-10 12:02:14 PDT
Nigel Horne added the following comment to Launchpad bug report 1160569:

On 3/10/15 1:34 PM, Gregoire-roussel wrote:
> firefox -v
>
> (process:8553): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
> Mozilla Firefox 36.0.1
>
> Even if firefox works properly. This warning should not appear. Is there
> some possible settings to avoid such warning to appear ?
>
It's not a warning - it's a critical message.

-Nigel



-- 
http://launchpad.net/bugs/1160569
Comment 99 Jan Schween 2015-03-16 06:15:38 PDT
The same with ubuntu 14.04 LTS / Gallium 0.4 on NV94


  13:57:41$thunderbird --version
  
  (process:32607): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
  Thunderbird 31.5.0

  13:57:50$thunderbird -safe-mode
  
  (process:317): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
  
  (thunderbird:317): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

  (thunderbird:317): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised
  
  (thunderbird:317): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised
  
  (thunderbird:317): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
  Speicherzugriffsfehler (Speicherabzug geschrieben)

Crash ID: bp-5a95e0f3-0129-485c-a933-5b1152150309


firefox produces the same error:

  14:07:33$firefox --version
  
  (process:376): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
  Mozilla Firefox 36.0
  14:07:54$firefox
  
  (process:410): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

but starts and runs ...
safe-mode and
Comment 100 Marian Marinov 2015-03-19 13:24:21 PDT
Distro: Slackware 14.1 32bit
Libc: glibc-2.20-i486-2
Kernel: 3.12.38

hackman@terion:~$ firefox -version

(process:22214): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Mozilla Firefox 36.0.1

hackman@terion:~$ thunderbird -version

(process:22231): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Thunderbird 31.5.0
Comment 101 Yuri 2015-03-22 22:43:21 PDT
I have the same problem, FreeBSD-10.1 amd64, fresh system install from scratch in VM, firefox-36.0.1, dwm window manager, G_SLICE workaround doesn't help, --safe-mode also doesn't help. FF prints the warning and freezes. No FF window opens.

It fails on xorg in VM, but same FF succeeds on Xnest in VM, and on my binary-identical host system.

I obtained xdpyinfo log in all three cases, see attachments:
firefox-hang-VM-in-xorg.txt : hangs on xorg in VM
firefox-fine-VM-in-xnest.txt : works fine on xnest in VM
firefox-fine-host.txt : works fine on xorg on host system

When I compare dpyinfo from xorg in host system (where ff works), and dpyinfo from xorg in VM system (where ff hangs), the main difference is that on host it has extra extensions NV-CONTROL, NV-GLX and XINERAMA. And on VM xorg it has SGI-GLX. I suspect this SGI-GLX causes ff to hang. Xnest server doesn't have any GLX, so it works too.

Someone from the development team should just reproduce it. I can tell you step by step how to do this with FreeBSD:
1. Download FreeBSD 10.1 amd64 disc1.iso
2. Install OS off that iso into VirtualBox VM with 3GB disk
3. Boot, and as root install all with the following command: pkg install firefox xorg xinit hal dbus dwm dmenu
4. Add these two lines into /etc/rc,conf: hald_enable="YES" / dbus_enable="YES"
5. As a regular user create file .xinitrc with "exec dwm" in it
6. Run startx, in dwm use Shift-Alt-Enter to open terminal
7. Run firefox and observe the problem

In all cases, working or not, it prints this warning:
(process:58625): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed



Hope this helps.
Comment 102 Yuri 2015-03-22 22:45:02 PDT
Created attachment 8581434 [details]
firefox-fine-host.txt: Works with NV-GLX on HW system
Comment 103 Yuri 2015-03-22 22:45:59 PDT
Created attachment 8581435 [details]
firefox-hang-VM-in-xorg.txt: Hangs in VM on xorg with SGI-GLX
Comment 104 Yuri 2015-03-22 22:47:00 PDT
Created attachment 8581436 [details]
firefox-fine-VM-in-xnest.txt: Works fine in VM on Xnest w/out GLX
Comment 105 Yuri 2015-03-22 22:57:37 PDT
I wanted to clarify that my main problem is that FF doesn't start, doesn't show window. Now, that I re-read the subject it isn't clear from the subject that this is what this bug is all about.
Comment 106 Yuri 2015-03-24 01:11:50 PDT
I created the separate bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1146805 because this one doesn't seem clear enough,
Comment 107 atreyu 2015-04-09 07:05:42 PDT
Confirming the bug on my freshly installed system (complete with 'yum update'):

$ firefox -version
(process:6939): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 37.0.1

$ uname -r
3.19.3-200.fc21.x86_64

Using -safe-mode makes no difference.

Setting G_SLICE (or GSLICE, don't know which it is, seen both in this report) to 'always-malloc' makes no diff either.

For the record, Firefox seems to run okay, but when it comes to a CRITICAL error in my terminal, I'm a hater...
Comment 108 jbrown 2015-05-19 08:36:02 PDT
Which firefox version will finally fix this bug?
Comment 109 August Karlstrom 2015-06-24 05:41:12 PDT
@jbrown: Who knows? The application has clearly escaped the intellectual control of the developers.
Comment 110 Mike Hommey [:glandium] 2015-06-26 16:31:53 PDT
Created attachment 8626818 [details] [diff] [review]
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch

Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.

The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.

Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
Comment 111 Nathan Froyd [:froydnj] 2015-06-29 12:36:21 PDT
Comment on attachment 8626818 [details] [diff] [review]
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch

Review of attachment 8626818 [details] [diff] [review]:
-----------------------------------------------------------------

Hooray for eliminating annoying startup messages.

::: xpcom/glue/standalone/nsXPCOMGlue.cpp
@@ +443,5 @@
> +  }
> +
> +  ~GSliceInit() {
> +    if (sTop) {
> +      void (*g_thread_init)(void*) = (void (*)(void*)) GetSymbol(

I tend to think function types are more readable with typedefs, but whatever.
Comment 112 Karl Tomlinson (:karlt) 2015-06-29 23:22:36 PDT
Comment on attachment 8626818 [details] [diff] [review]
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch

>+    // Keep the original value of the G_SLICE env variable to restore it once
>+    // we're done.
>+    mGSlice = getenv("G_SLICE");

I don't think we should assume it is safe to use mGSlice later.

man 3p getenv
"The returned string pointer might be invalidated or the string content might
be overwritten by a subsequent call to getenv(), setenv(), unsetenv(), or (if
supported) putenv()"

>+    // Disable the slice allocator, since jemalloc already uses similar layout
>+    // algorithms, and using a sub-allocator tends to increase fragmentation.
>+    // This must be done before g_thread_init() is called.
>+    setenv("G_SLICE", "always-malloc", 1);

I had intentionally chosen not to override an existing G_SLICE environment
variable so that this could be overridden or debug-blocks could be used if
desired.  That's not a show-stopper, but avoiding overriding would avoid
having to copy the old value to restore.

I don't know why you are preferring setenv over putenv here.
I had chosen putenv to avoid the leak.

There is discussion about possible getenv optimizations if putenv is not used,
but I don't see this in glibc.

> +      void (*g_thread_init)(void*) = (void (*)(void*)) GetSymbol(

Declare with "auto" type, if you like.
Comment 113 Mike Hommey [:glandium] 2015-06-30 00:09:12 PDT
(In reply to Karl Tomlinson (ni?:karlt back June 30) from comment #112)
> I had intentionally chosen not to override an existing G_SLICE environment
> variable so that this could be overridden or debug-blocks could be used if
> desired.  That's not a show-stopper, but avoiding overriding would avoid
> having to copy the old value to restore.

I guess that would work just as much. I was worried that some systems might have G_SLICE set for some wrong reasons. I don't have a strong opinion anyways.

> I don't know why you are preferring setenv over putenv here.
> I had chosen putenv to avoid the leak.

I chose setenv to avoid having both "G_SLICE" and "G_SLICE=always-malloc" as .rodata.
Comment 114 Karl Tomlinson (:karlt) 2015-06-30 00:37:52 PDT
(In reply to Mike Hommey [:glandium] from comment #113)
> > I don't know why you are preferring setenv over putenv here.
> > I had chosen putenv to avoid the leak.
> 
> I chose setenv to avoid having both "G_SLICE" and "G_SLICE=always-malloc" as
> .rodata.

OK.  Whatever you think is best.
Comment 115 Mike Hommey [:glandium] 2015-06-30 22:02:18 PDT
Created attachment 8628085 [details] [diff] [review]
Replace g_slice_set_config() with G_SLICE environment variable
Comment 117 Mike Hommey [:glandium] 2015-07-01 00:44:11 PDT
Backed out for gtest bustage:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f955560a47

23:59:34     INFO - GThread-ERROR **: GThread system may only be initialized once.
23:59:34     INFO - aborting...
23:59:34     INFO - Redirecting call to abort() to mozalloc_abort
23:59:35  WARNING - gtest TEST-UNEXPECTED-FAIL | gtest | test failed with return code -139
23:59:35     INFO - make[1]: *** [check] Error 1

It also happens to break valgrind builds:
/builds/slave/m-in-l64-valgrind-000000000000/src/xpcom/glue/standalone/nsXPCOMGlue.cpp:469:14: error: unused variable 'gSliceInit' [-Werror=unused-variable]
Comment 118 Mike Hommey [:glandium] 2015-07-01 01:42:26 PDT
(In reply to Mike Hommey [:glandium] from comment #117)
> Backed out for gtest bustage:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f955560a47
> 
> 23:59:34     INFO - GThread-ERROR **: GThread system may only be initialized
> once.

And this error was removed in glib 2.23.x 5 years ago, which is why I can't reproduce locally... https://bugzilla.gnome.org/show_bug.cgi?id=606775
Comment 119 Mike Hommey [:glandium] 2015-07-01 02:08:40 PDT
... and it so happens that we're calling g_thread_init(NULL) from different places, and likely crash for that reason with older glib...
Comment 120 Ludovic Hirlimann [:Usul] 2015-07-01 02:43:17 PDT
(In reply to Mike Hommey [:glandium] from comment #119)
> ... and it so happens that we're calling g_thread_init(NULL) from different
> places, and likely crash for that reason with older glib...

What's the followup bug for that ? Shall we change our requirements for glib and fixe these ?
Comment 121 Mike Hommey [:glandium] 2015-07-07 04:51:30 PDT
Created attachment 8630422 [details] [diff] [review]
Replace g_slice_set_config() with G_SLICE environment variable

Turns out there aren't many places where g_thread_init is actually called. There's some webrtc code that we don't build, and other than that, other uses are exclusive... but need to be factored in, so this became a bit awful. At the same time I added a compile time glib check that removes the g_thread_init call when building against glib >= 2.32, which is the case for gtk3 builds.
Comment 122 Karl Tomlinson (:karlt) 2015-07-07 20:52:16 PDT
Comment on attachment 8630422 [details] [diff] [review]
Replace g_slice_set_config() with G_SLICE environment variable

The g_type_init() call has been dropped.
I don't know of a static constructor using GSlice in GLib 2.32.
Is there something that causes G_SLICE to be read during XPCOMGlueStartup with 
GLib 2.32?
It would be good to keep this working for 2.32 because that is what the
precise test machines use.

>+#if defined(MOZ_WIDGET_GTK)
>+#if !GLIB_CHECK_VERSION(2, 32, 0)

The compile time glib version check is contrary to our goal of compiling the same code irrespective of the compile environment.

Can this just be "if MOZ_WIDGET_GTK == 2" ?

I'd also be happy to drop support for G_SLICE=always-malloc on versions prior
to 2.32 if that makes the g_thread_init situation simpler.  However, I don't
know whether it is acceptable to call g_thread_init after g_type_init in
versions prior to 2.24.
Comment 123 Mike Hommey [:glandium] 2015-07-07 22:17:03 PDT
(In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> Comment on attachment 8630422 [details] [diff] [review]
> Replace g_slice_set_config() with G_SLICE environment variable
> 
> The g_type_init() call has been dropped.
> I don't know of a static constructor using GSlice in GLib 2.32.

Yeah, I was mistaken, I thought there was, but there isn't. Only g_thread is initialized, not g_slice.

> >+#if defined(MOZ_WIDGET_GTK)
> >+#if !GLIB_CHECK_VERSION(2, 32, 0)
> 
> The compile time glib version check is contrary to our goal of compiling the
> same code irrespective of the compile environment.

I thought that too, and then I found a bunch of preprocessor glib version checks (various GLIB_CHECK_VERSION in harfbuzz, and various GLIB_MAJOR/MINOR_VERSION checks here and there, although, looking at them, they are actually useless because they're for versions even older than what we support ; harfbuzz does check for versions well above 2.18).

> Can this just be "if MOZ_WIDGET_GTK == 2" ?

sure
 
> I'd also be happy to drop support for G_SLICE=always-malloc on versions prior
> to 2.32 if that makes the g_thread_init situation simpler.  However, I don't
> know whether it is acceptable to call g_thread_init after g_type_init in
> versions prior to 2.24.

g_thread_init can be called multiple times in versions >= 2.24, and gtype.c says, about g_type_init, "Since version 2.24 this also initializes the thread system". So if we're okay with dropping G_SLICE=always-malloc for versions 2.18 to 2.23 included, we should be able to get away with only calling g_type_init. Another option would be to just call g_slice_alloc/g_slice_free1, which will obviously initialize gslice, and after all, sounds much simpler.

Thoughts?
Comment 124 Karl Tomlinson (:karlt) 2015-07-08 04:02:36 PDT
(In reply to Mike Hommey [:glandium] from comment #123)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> > I'd also be happy to drop support for G_SLICE=always-malloc on versions prior
> > to 2.32 if that makes the g_thread_init situation simpler.  However, I don't
> > know whether it is acceptable to call g_thread_init after g_type_init in
> > versions prior to 2.24.
> 
> g_thread_init can be called multiple times in versions >= 2.24, and gtype.c
> says, about g_type_init, "Since version 2.24 this also initializes the
> thread system". So if we're okay with dropping G_SLICE=always-malloc for
> versions 2.18 to 2.23 included, we should be able to get away with only
> calling g_type_init. Another option would be to just call
> g_slice_alloc/g_slice_free1, which will obviously initialize gslice, and
> after all, sounds much simpler.
> 
> Thoughts?

There are many options, and I don't think it matters too much.

It looks like the pre-2.24 code at least attempts to deal with g_slice used
before g_thread_init [1], even though taking advantage of this would not be
complying with the docs.

The most safe would be to either version check or always
g_thread_init before g_type/g_slice usage, though it seems this is probably
not necessary.

It probably comes down to what is simplest.

My instinct is to avoid allocations where possible, so I'd tend to g_type_init
instead of g_slice_alloc because a g_type_init will be required at some
stage anyway, but that is likely premature optimization here if there
something simpler.  g_type_init is a single symbol and g_slice_alloc would require finding two.

The new method in nsXULAppAPI.h can mean that everything can be done from there
with only a single GetSymbol(), if you want to keep the g_thread_init.  It could be renamed to XRE_GLibInit() to do more than just g_thread_init.
Still I'm OK with dropping XRE_g_thread_init altogether and not bothering with
g_thread_init from XPCOMGlueStartup if you prefer.

[1] https://git.gnome.org/browse/glib/tree/glib/gslice.c?h=glib-2-22#n432
Comment 125 Mike Hommey [:glandium] 2015-07-09 01:53:41 PDT
Created attachment 8631479 [details] [diff] [review]
Replace g_slice_set_config() with G_SLICE environment variable

Not enough changes to require another review from Nathan. This should address your concerns.
Comment 126 Karl Tomlinson (:karlt) 2015-07-09 03:51:40 PDT
Comment on attachment 8631479 [details] [diff] [review]
Replace g_slice_set_config() with G_SLICE environment variable

>+      // glib version < 2.32 doesn't initialize g_thread in a static
>+      // initializer. Ensure this happens before we unset G_SLICE.
>+      XRE_GlibInit();

Can you note the need/reason for g_type_init somewhere please?

Perhaps "GLib version < 2.36 doesn't initialize g_slice in a static
initializer.  Ensure this happens through g_thread_init (GLib version < 2.32)
or g_type_init (2.32 <= GLib version < 2.36)."
Comment 128 Carsten Book [:Tomcat] 2015-07-10 03:22:04 PDT
https://hg.mozilla.org/mozilla-central/rev/966db7a40427
Comment 129 amos083 2015-07-10 23:43:59 PDT
(Probably just cosmetics): Referring to https://hg.mozilla.org/mozilla-central/rev/966db7a40427 , the comment in line 5.28 seems to be incomplete.
Comment 130 craigtski47 2015-10-16 13:21:58 PDT
Mint 17.2, based on Ubuntu 14.04.1 bug is still here:

firefox -v

GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 41.0.1

Also, when firefox starts, it's slow and opens in blocks on the screen instead of all at once.
Comment 131 Léa Gris 2015-10-19 16:36:03 PDT
Ubuntu 15.04
Thunderbird 38.3.0
64Bit

But is still present!

Why is this bug marked Fixed then when the latest version of Thunderbird distributed is 38.3.0 as of today?
Comment 132 Magnus Melin 2015-10-19 23:15:42 PDT
This is fixed for v42+ (as per target milestone) and there's no non-beta release of Thunderbird for that yet, next major version is v45.
Comment 133 jeanne.varasco 2015-11-19 08:36:41 PST
On Jessie, for me all was OK. But on Stretch this error came when I install Firetray. I unstall it but the error stay. This make my command "icedove -adressbook" don't work. Could you please do something ?

Message with firetray installed : 

:~$ icedove -adressbook

    (process:2427): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
    [calBackendLoader] Using libical backend at /home/jeanne/.icedove/6ycmoyti.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
    enigmail.js: Registered components
    Warning: unrecognized command line flag -adressbook
    mimeVerify.jsm: module initialized
   16:43:51.527 ERROR firetray.FiretrayWindow unknown window while lookup
   16:43:51.528 ERROR firetray.Window can't unregister unknown window null
    *** BUG ***
    In pixman_region32_reset: Malformed region region
    Set a breakpoint on '_pixman_log_error' to debug

and after unstalling firetray:

     :~$ icedove -adressbook

     (process:2617): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Comment 134 Karl Tomlinson (:karlt) 2016-05-26 16:47:09 PDT
*** Bug 1075079 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.