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

[Anastasia Filatova]

Have a look at the screen-shot for more details.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: firefox 19.0.2+build1-0ubuntu1
ProcVersionSignature: Ubuntu 3.8.0-14.24-generic 3.8.4
Uname: Linux 3.8.0-14-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.9.2-0ubuntu4
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
BuildID: 20130308124351
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Channel: Unavailable
Date: Tue Mar 26 21:48:57 2013
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2013-03-26 (0 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64+mac (20130326)
IpRoute:
 default via 10.0.1.1 dev eth0 proto static
 10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.16 metric 1
 169.254.0.0/16 dev eth0 scope link metric 1000
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MarkForUpload: True
Plugins:
 Windows Media Player Plug-in 10 (compatible; Videos) - /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so (totem-mozilla)
 VLC Multimedia Plugin (compatible Videos 3.6.3) - /usr/lib/mozilla/plugins/libtotem-cone-plugin.so (totem-mozilla)
 DivX® Web Player - /usr/lib/mozilla/plugins/libtotem-mully-plugin.so (totem-mozilla)
 QuickTime Plug-in 7.6.6 - /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so (totem-mozilla)
 iTunes Application Detector - /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so (rhythmbox-mozilla)
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=19.0.2/20130308124351
RelatedPackageVersions:
 totem-mozilla 3.6.3-0ubuntu4
 rhythmbox-mozilla 2.98-0ubuntu3
RfKill:

RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.board.name: VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH

[Hiikezoe (hiikezoe)]

Created attachment 546933
A patch

The following message is spewed out on startup of firefox.

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

So out jemalloc is less effective.

[Hiikezoe (hiikezoe)]

(In reply to comment #0)

> So out jemalloc is less effective.

*our* jemalloc, I meant.

[Ginn-chen-r (ginn-chen-r)]

You can just move the line
static GQuark sQuark_gecko_acc_obj = g_quark_from_static_string("GeckoAccObj");
inside toplevel_event_watcher().

[Hiikezoe (hiikezoe)]

nsApplicationAccessibleWrap::Init() is invoked just once?

[Trevor Saunders (trev-saunders)]

Comment on attachment 546933
A patch

STEALING THE REVIEW, PER REQUEST IN 669130 ON THAT PATCH.

[Trevor Saunders (trev-saunders)]

(In reply to comment #2)
> You can just move the line
> static GQuark sQuark_gecko_acc_obj =
> g_quark_from_static_string("GeckoAccObj");
> inside toplevel_event_watcher().

are you absolutely sure that will cause it to be initialized on the first call, not as a global ctor?

(In reply to comment #3)
> nsApplicationAccessibleWrap::Init() is invoked just once?

it should be although I'm not sure why that would matter, personally I like the variable being local to the one function we use it in.

[Ginn-chen-r (ginn-chen-r)]

(In reply to comment #5)
> (In reply to comment #2)
> > You can just move the line
> > static GQuark sQuark_gecko_acc_obj =
> > g_quark_from_static_string("GeckoAccObj");
> > inside toplevel_event_watcher().
>
> are you absolutely sure that will cause it to be initialized on the first
> call, not as a global ctor?
>

Absolutely sure.

But although it will save a couple of source code lines, the final binary will be several bytes larger than the patch here, because the compiler has to do the job for us.

I'm OK with either approach.

[Bzbarsky (bzbarsky)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/b0599f36be18

[Ehsan-mozilla (ehsan-mozilla)]

http://hg.mozilla.org/mozilla-central/rev/b0599f36be18

[Chris Coulson (chrisccoulson)]

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

[Thibault D (thibdrev)]

That's what I get with a 13.04 daily build on a live usb key :

ubuntu@ubuntu:~$ firefox
(process:11823): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Bugzilla-obra (bugzilla-obra)]

This bug appears to have reemerged when firefox runs under glib 2.36

[Ginn-chen-r (ginn-chen-r)]

(In reply to Fredrik from comment #9)
> This bug appears to have reemerged when firefox runs under glib 2.36

Please file a new bug and it will be great if you can provide crash stack.

[avius (avi142)]

I am also affected by this bug. Has a fix actually been released (as suggested by the bug watch update)?
If not, I would be willing to work on a patch if someone could steer me in the right direction.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

avius, the bug watch is only checking the initial mozilla bug report, but the bug has reemerged after updating glib to version 2.36.

[Chris Coulson (chrisccoulson)]

The upstream bug link is wrong

[Alan Robertson (alanr-unix)]

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.

[Alan Robertson (alanr-unix)]

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.

[P-nikolic1 (p-nikolic1)]

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

[Alan Robertson (alanr-unix)]

OK. I agree with comment 3. I have found out that Thunderbird will crash and burn - or just hang.

[Ginn-chen-r (ginn-chen-r)]

I just saw this:
Deprecate and remove g_slice_[sg]et_config.*
https://bugzilla.gnome.org/show_bug.cgi?id=680831

[jidanni (dan-jacobson)]

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!

[Artur Frysiak (wiget)]

This bug prevent running Firefox on 13.04

[Jonathan Allard (joallard)]

Firefox can't start. I fail to see how this could possibly be set to 'Low'.

[Chris Coulson (chrisccoulson)]

This bug does *not* cause Firefox to not start. If Firefox is not starting, then you have another bug.

[Chris Coulson (chrisccoulson)]

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

[Javier (javiersmail)]

Aded saucy and package-from-proposed because this also affects Ubuntu 13.10. https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1181262

[Mh+mozilla (mh+mozilla)]

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

[Chris Coulson (chrisccoulson)]

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.

[Mh+mozilla (mh+mozilla)]

gah these things are confusing.

[Danielneugart (danielneugart)]

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.

[Ron Johnson (ron-l-johnson)]

I noticed this today on Thunderbird.
Xubuntu 13.04
Thunderbird 17.0.6+build1-0ubuntu0.13.04.1
libglib2.0-0 2.36.0-1ubuntu2
kernel 3.8.0-24-generic

[Vseerror (vseerror)]

(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

[Danielneugart (danielneugart)]

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

[Stradionov (stradionov)]

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

[Vseerror (vseerror)]

(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

[Raumkundschafter (raumkundschafter)]

same problemo with icedove on debian testing:
 Icedove: 10.0.12
 Glib Version: 2.36.1-2build1
Firefox works though...

[Andreas Ecker (aecker2)]

I get the same error when I try to install IE6 under Ubuntu 13.04 in order to fix the connect to web album problem with Picasa 3.9 (following the instructions from http://www.webupd8.org/2012/01/install-picasa-39-in-linux-and-fix.html). My firefox is working fine (wintricks is opening a new tab within firefox after displaying the error message in the terminal).

The command line and error message:

~$ winetricks ie6
Executing w_do_call ie6
Executing load_ie6

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

[Yuri (yuri-tsoft)]

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.

[Yuri (yuri-tsoft)]

Created attachment 8581434
firefox-fine-host.txt: Works with NV-GLX on HW system

[Yuri (yuri-tsoft)]

Created attachment 8581435
firefox-hang-VM-in-xorg.txt: Hangs in VM on xorg with SGI-GLX

[Yuri (yuri-tsoft)]

Created attachment 8581436
firefox-fine-VM-in-xnest.txt: Works fine in VM on Xnest w/out GLX

[Yuri (yuri-tsoft)]

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.

[Yuri (yuri-tsoft)]

I created the separate bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1146805 because this one doesn't seem clear enough,

[Wjhendrickson (wjhendrickson)]

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

[Enkouyami (furyhamster)]

Thunderbird 31.6.0 is affected by this.

[J. Brown (jb999-deactivatedaccount-deactivatedaccount)]

Which firefox version will finally fix this bug?

[August Karlstrom (fusionfile)]

@jbrown: Who knows? The application has clearly escaped the intellectual control of the developers.

[Mh+mozilla (mh+mozilla)]

Created attachment 8626818
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.

[Nfroyd (nfroyd)]

Comment on attachment 8626818
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch

Review of attachment 8626818:
-----------------------------------------------------------------

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.

[Karlt (karlt)]

Comment on attachment 8626818
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.

[Mh+mozilla (mh+mozilla)]

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

[Karlt (karlt)]

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

[Mh+mozilla (mh+mozilla)]

Created attachment 8628085
Replace g_slice_set_config() with G_SLICE environment variable

[Pulsebot (pulsebot)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f70b74488807

[Mh+mozilla (mh+mozilla)]

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]

[Mh+mozilla (mh+mozilla)]

(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

[Mh+mozilla (mh+mozilla)]

... and it so happens that we're calling g_thread_init(NULL) from different places, and likely crash for that reason with older glib...

[Ludovic-mozilla (ludovic-mozilla)]

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

[Mh+mozilla (mh+mozilla)]

Created attachment 8630422
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.

[Karlt (karlt)]

Comment on attachment 8630422
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.

[Mh+mozilla (mh+mozilla)]

(In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> Comment on attachment 8630422
> 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?

[Karlt (karlt)]

(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

[Mh+mozilla (mh+mozilla)]

Created attachment 8631479
Replace g_slice_set_config() with G_SLICE environment variable

Not enough changes to require another review from Nathan. This should address your concerns.

[Karlt (karlt)]

Comment on attachment 8631479
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)."

[Pulsebot (pulsebot)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/966db7a40427

[Cbook (cbook)]

https://hg.mozilla.org/mozilla-central/rev/966db7a40427

[Amos083 (amos083)]

(Probably just cosmetics): Referring to https://hg.mozilla.org/mozilla-central/rev/966db7a40427 , the comment in line 5.28 seems to be incomplete.

[Craigtski47 (craigtski47)]

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.

[Léa GRIS (lea-gris)]

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?

[Léa GRIS (lea-gris)]

Still issue with Thunderbird 38.3.0
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid

[Mkmelin+mozilla (mkmelin+mozilla)]

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.

[Mathew Hodson (mhodson)]

This should be fixed with firefox 42.0

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jeanne-varasco (jeanne-varasco)]

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

[Karlt (karlt)]

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

[Max (maxmax)]

It seems a Glib issue, I see this example:
console-kit-daemon[2448]: (process:13258): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

Ubuntu :: 16.04.3
consolekit :: 0.4.6-5
libglib2.0-0:i386 :: 2.48.2-0ubuntu1

[Paul White (paulw2u)]

Upstream bug closed "RESOLVED FIXED" on 2015-07-10
Target milestone - mozilla42
So fixed in Firefox 42 and Thunderbird 45
Marking as "Fix Released" to close