The default bug view has changed. See this FAQ.

(webapprt-stub:8885): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

VERIFIED FIXED in Firefox 16

Status

Firefox Graveyard
Web Apps
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: skierpage, Assigned: marco)

Tracking

Trunk
Firefox 16
x86_64
Linux
Bug Flags:
in-moztrap +

Details

(Whiteboard: [qa!])

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

5 years ago
I've installed Private Joe and Lord of Ultima, and when I start either from a terminal I see this message.  Lord of Ultima goes on to run OK despite the "CRITICAL".

Using strace, this warning prints after lstat("/home/skierpage/programs/firefox/webapprt". Both my firefox (nightly profiling) and webapprt-stub are 64-bit.

FWIW bug 672671 is the same warning from elsewhere in the codebase, with a fix.

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Component: Webapp Runtime → Web Apps
QA Contact: webapp-runtime → webapps
…
lstat("/home/john/bin/firefox-nightly/firefox", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/x86_64-linux-gnu/charset.alias", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "\n(webapprt-stub:22023): GLib-CRI"..., 100
(webapprt-stub:22023): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
) = 100

For me its triggering once XRE_main is called, the last lstat is from XRE_GetFileFromPath(firefoxDir).
Created attachment 631860 [details] [diff] [review]
Move gtk_init() to avoid an assert

If an error dialog isn’t needed in normal use case, gtk doesn’t need to be inited. So I moved that into the ErrorDialog function and it no longer triggers the assert ‐ XRE_Main expects nothing gtk/glib inited beforehand.
Attachment #631860 - Flags: review?
Attachment #631860 - Flags: review?(mar.castelluccio)
Attachment #631860 - Flags: review?(karlt)
Attachment #631860 - Flags: review?
(Assignee)

Comment 3

5 years ago
Created attachment 631926 [details] [diff] [review]
Same patch with arguments

Thanks John.
I don't know if we can do something like this, because we should call gtk_init (or gtk_parse_args) in the main function (because we want gtk to remove its arguments from argc and argv).
Attachment #631860 - Attachment is obsolete: true
Attachment #631860 - Flags: review?(mar.castelluccio)
Attachment #631860 - Flags: review?(karlt)
Attachment #631926 - Flags: feedback?(karlt)
CC'ing Glandium to take a look here, as the comments from the similar bug 672671 say that this error makes jemalloc not work, and he might now what is the proper way to fix it.
(Assignee)

Comment 5

5 years ago
I could add a function to remove the gtk related arguments if this assertion is important (this would be a better solution than the other patch, but would complicate the webapprt code a bit).
(Assignee)

Updated

5 years ago
Attachment #631926 - Flags: feedback?(karlt)
(In reply to Marco Castelluccio from comment #3)
> Created attachment 631926 [details] [diff] [review]
> Same patch with arguments
> 
> Thanks John.
> I don't know if we can do something like this, because we should call
> gtk_init (or gtk_parse_args) in the main function (because we want gtk to
> remove its arguments from argc and argv).

XRE_main calls gtk_init already, and I think that's the main reason why you can't call gtk_init before.

(In reply to Felipe Gomes (:felipe) from comment #4)
> CC'ing Glandium to take a look here, as the comments from the similar bug
> 672671 say that this error makes jemalloc not work, and he might now what is
> the proper way to fix it.

I don't think this has any effect on jemalloc. The assertion probably "simply" comes from the double gtk initialization.
(In reply to Mike Hommey [:glandium] from comment #6)
> I don't think this has any effect on jemalloc. The assertion probably
> "simply" comes from the double gtk initialization.

After checking, this comes from g_slice_set_config (in XRE_main) being called after gtk_init (in main).

The error doesn't have an effect on jemalloc, however, it has an effect on gslice memory allocation using its own slab allocator, which may increase memory fragmentation, and thus firefox memory usage.
(Assignee)

Comment 8

5 years ago
(In reply to Mike Hommey [:glandium] from comment #7)
> (In reply to Mike Hommey [:glandium] from comment #6)
> > I don't think this has any effect on jemalloc. The assertion probably
> > "simply" comes from the double gtk initialization.
> 
> After checking, this comes from g_slice_set_config (in XRE_main) being
> called after gtk_init (in main).
> 
> The error doesn't have an effect on jemalloc, however, it has an effect on
> gslice memory allocation using its own slab allocator, which may increase
> memory fragmentation, and thus firefox memory usage.

Indeed the simple double initialization isn't a problem for gtk (they don't do anything on the second initialization).
(Assignee)

Comment 9

5 years ago
Created attachment 631957 [details] [diff] [review]
Set gslice only when needed
Assignee: nobody → mar.castelluccio
Attachment #631926 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #631957 - Flags: review?(mh+mozilla)
Comment on attachment 631957 [details] [diff] [review]
Set gslice only when needed

I preferred the patch that moves gtk initialization into the error function.
Attachment #631957 - Flags: review?(mh+mozilla) → review-
(Assignee)

Comment 11

5 years ago
(In reply to Mike Hommey [:glandium] from comment #10)
> I preferred the patch that moves gtk initialization into the error function.

With that method we won't support GTK commandline options. Don't we care about them?
(In reply to Marco Castelluccio from comment #11)
> (In reply to Mike Hommey [:glandium] from comment #10)
> > I preferred the patch that moves gtk initialization into the error function.
> 
> With that method we won't support GTK commandline options. Don't we care
> about them?

Why wouldn't we, since XRE_main does handle them?
(Assignee)

Comment 13

5 years ago
Comment on attachment 631926 [details] [diff] [review]
Same patch with arguments

Oh, you're right! I couldn't find gtk_parse_args with MXR because I was searching for an identifier (and MXR, I don't know why, doesn't handle it as an identifier).
Attachment #631926 - Flags: review?(mh+mozilla)
(Assignee)

Updated

5 years ago
Attachment #631926 - Attachment is obsolete: false
Comment on attachment 631926 [details] [diff] [review]
Same patch with arguments

>+  gtk_init(pargc,pargv);

File style is to have spaces between parameters.

This approach also saves having 2 connections to the X11 display.
Fortunately gdk_set_program_class doesn't need a g_type_init.
Attachment #631926 - Flags: review?(mh+mozilla) → review+
(Assignee)

Comment 15

5 years ago
Created attachment 632221 [details] [diff] [review]
Patch

Carrying r+
Attachment #631926 - Attachment is obsolete: true
Attachment #631957 - Attachment is obsolete: true
Attachment #632221 - Flags: review+
(Assignee)

Comment 16

5 years ago
Created attachment 632706 [details] [diff] [review]
Patch

Updated patch.
Attachment #632221 - Attachment is obsolete: true
Attachment #632706 - Flags: review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac01424220d8
Keywords: checkin-needed
Target Milestone: --- → Firefox 16

Updated

5 years ago
Whiteboard: [qa+]
https://hg.mozilla.org/mozilla-central/rev/ac01424220d8
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Flags: in-moztrap?(mar.castelluccio)
(Assignee)

Comment 19

5 years ago
Jason, I've created a new test case to launch an application through the shell and check that no assertion is fired: https://moztrap.mozilla.org/manage/caseversion/1074/
(In reply to Marco Castelluccio from comment #19)
> Jason, I've created a new test case to launch an application through the
> shell and check that no assertion is fired:
> https://moztrap.mozilla.org/manage/caseversion/1074/

Looks good.
Flags: in-moztrap?(mar.castelluccio) → in-moztrap+

Updated

5 years ago
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
Depends on: 768768

Updated

5 years ago
QA Contact: jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.