Closed Bug 763358 Opened 8 years ago Closed 8 years ago

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

Categories

(Firefox Graveyard :: Web Apps, defect)

x86_64
Linux
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 16

People

(Reporter: info, Assigned: marco)

References

Details

(Whiteboard: [qa!])

Attachments

(1 file, 4 obsolete files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
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?
Attached patch Same patch with arguments (obsolete) — Splinter Review
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.
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).
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.
(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).
Attached patch Set gslice only when needed (obsolete) — Splinter Review
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-
(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?
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)
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+
Attached patch Patch (obsolete) — Splinter Review
Carrying r+
Attachment #631926 - Attachment is obsolete: true
Attachment #631957 - Attachment is obsolete: true
Attachment #632221 - Flags: review+
Attached patch PatchSplinter Review
Updated patch.
Attachment #632221 - Attachment is obsolete: true
Attachment #632706 - Flags: review+
Keywords: checkin-needed
Whiteboard: [qa+]
https://hg.mozilla.org/mozilla-central/rev/ac01424220d8
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Flags: in-moztrap?(mar.castelluccio)
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+
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
Depends on: 768768
QA Contact: jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.