Closed
Bug 763358
Opened 12 years ago
Closed 12 years ago
(webapprt-stub:8885): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Categories
(Firefox Graveyard :: Web Apps, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
Firefox 16
People
(Reporter: info, Assigned: marco)
References
Details
(Whiteboard: [qa!])
Attachments
(1 file, 4 obsolete files)
1.58 KB,
patch
|
marco
:
review+
|
Details | Diff | Splinter Review |
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•12 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•12 years ago
|
Component: Webapp Runtime → Web Apps
QA Contact: webapp-runtime → webapps
Comment 1•12 years ago
|
||
… 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).
Comment 2•12 years ago
|
||
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?
Updated•12 years ago
|
Attachment #631860 -
Flags: review?(mar.castelluccio)
Attachment #631860 -
Flags: review?(karlt)
Attachment #631860 -
Flags: review?
Assignee | ||
Comment 3•12 years ago
|
||
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)
Comment 4•12 years ago
|
||
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•12 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•12 years ago
|
Attachment #631926 -
Flags: feedback?(karlt)
Comment 6•12 years ago
|
||
(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.
Comment 7•12 years ago
|
||
(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•12 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•12 years ago
|
||
Assignee: nobody → mar.castelluccio
Attachment #631926 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #631957 -
Flags: review?(mh+mozilla)
Comment 10•12 years ago
|
||
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•12 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?
Comment 12•12 years ago
|
||
(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•12 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•12 years ago
|
Attachment #631926 -
Attachment is obsolete: false
Comment 14•12 years ago
|
||
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•12 years ago
|
||
Carrying r+
Attachment #631926 -
Attachment is obsolete: true
Attachment #631957 -
Attachment is obsolete: true
Attachment #632221 -
Flags: review+
Assignee | ||
Comment 16•12 years ago
|
||
Updated patch.
Attachment #632221 -
Attachment is obsolete: true
Attachment #632706 -
Flags: review+
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Comment 17•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac01424220d8
Keywords: checkin-needed
Target Milestone: --- → Firefox 16
Updated•12 years ago
|
Whiteboard: [qa+]
Comment 18•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ac01424220d8
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Flags: in-moztrap?(mar.castelluccio)
Assignee | ||
Comment 19•12 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/
Comment 20•12 years ago
|
||
(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•12 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa!]
Updated•12 years ago
|
QA Contact: jsmith
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•