Can you get a stacktrace ?

I am also experiencing this problem.

Specifically, I am trying to run Maple 2015. The program will show the splash screen then a blank window will appear for a moment before disappearing.

Crash log: http://pastebin.com/7ysdnNET

Downgrading to 2.44 from 2.46 resolved this issue.

That trace isn't useful unfortunately, but it seems likely that this might be the GSequence bug again.

If you can build a new glib package with a patch applied, try https://git.gnome.org/browse/glib/patch/?id=2d781788

I'm sorry but there was no change for me with the patch applied.

Works when you do LD_PRELOAD=libglib-2.0.so <command>

[tex@localhost ~]$ LD_PRELOAD=libglib-2.0.so tvbrowser

Works!

[tex@localhost ~]$ LD_PRELOAD=libglib-2.0.so geogebra

Works!

Why?

Hey, the issue has been reported here as well: https://bugs.archlinux.org/task/46619

Does G_SLICE=always-malloc make the crash go away ?

No it doesn't.

Bisection would be helpful.

Did any library dependencies change from 2.44 to 2.46? The JVM crash logs I've seen didn't load any of the glib libraries, and it seems strange that preloading the library would fix the crash.

The following commit is when this issue started happening:

  commit 2fe992b099bfd3fb121a71b7af43e116b2142b5d
  Author: Matthias Clasen <mclasen@redhat.com>
  Date:   Fri Sep 11 23:59:27 2015 -0400

      Move quark initialization to a constructor

      This removes a branch from the very frequently called
      quark functions.

It doesn't revert cleanly on master but I did confirm that reverting it on top of 2.46.0 makes the issue go away.

(In reply to Jan Alexander Steffens (heftig) from comment #10)
> and it seems strange that preloading the library would fix the crash.

Is java dlopening glib, then unloading it and reloading it again? (Possibly indirectly through another library.) That's always caused crashes with libgobject, but it's possible that it used to work with libglib but now fails.

Try setting a breakpoint on glib_init() and see if it gets run more than once.

On the other hand glib_init() should be robust and not crash if ran twice right?

It has asserts that abort the program when glib_init is called twice, and I think unless glib2 is compiled with --enable-debug=no (or --disable-debug), these asserts are active.

(In reply to Dan Winship from comment #12)
> Is java dlopening glib, then unloading it and reloading it again? (Possibly
> indirectly through another library.) That's always caused crashes with
> libgobject, but it's possible that it used to work with libglib but now
> fails.

23:16:52.564445 open("/usr/lib/libglib-2.0.so.0", O_RDONLY|O_CLOEXEC) = 111
23:16:52.564563 mmap(NULL, 3200360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 111, 0) = 0x7f43a9327000
23:16:52.566712 munmap(0x7f43a9327000, 3200360) = 0
23:16:52.589014 open("/usr/lib/libglib-2.0.so.0", O_RDONLY|O_CLOEXEC) = 112
23:16:52.589122 mmap(NULL, 3200360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 112, 0) = 0x7f43a90fd000
23:16:52.644903 munmap(0x7f43a90fd000, 3200360) = 0
23:16:54.448706 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f43a938cbe0} ---

The address at which the fault occurred belongs to the first mapping that has been removed and is no longer valid at that time.

So glib should cleanup its global memory before unload?

I've built a version of glib with LDFLAGS containing "-Wl,-z,nodelete", which (according to at least one user) seems to work.

I built glib with --enable-debug=no + LDFLAGS containing "-Wl,-z,nodelete and it fixes the issue for us.

LDFLAGS containing "-Wl,-z,nodelete" seems to have a negative impact my 32bit MATE so I ended up reverting commit: 

commit 2fe992b099bfd3fb121a71b7af43e116b2142b5d
  Author: Matthias Clasen <mclasen@redhat.com>
  Date:   Fri Sep 11 23:59:27 2015 -0400

and everything appears to be back to normal.

(In reply to texstar from comment #19)
> LDFLAGS containing "-Wl,-z,nodelete" seems to have a negative impact my
> 32bit MATE 

Can you elaborate on "negative impact"?

(In reply to Jan Alexander Steffens (heftig) from comment #17)
> I've built a version of glib with LDFLAGS containing "-Wl,-z,nodelete",
> which (according to at least one user) seems to work.

This is a reasonable thing to do, and I'd say GLib upstream would certainly support these builds, similar to what we do with GObject.

(In reply to Colin Walters from comment #20)
> (In reply to texstar from comment #19)
> > LDFLAGS containing "-Wl,-z,nodelete" seems to have a negative impact my
> > 32bit MATE 
> 
> Can you elaborate on "negative impact"?

Disregard. The fix turned out to be deleting the user file in ~.config/dconf folder and letting Mate recreate it otherwise my mate-settings, marco and caja were segfaulting in libgobject-2.0.so.0.4600.0. after updating to 2.46.0.

(In reply to Jan Alexander Steffens (heftig) from comment #14)
> It has asserts that abort the program when glib_init is called twice, and I
> think unless glib2 is compiled with --enable-debug=no (or --disable-debug),
> these asserts are active.

Where are those asserts ? I don't think there should be any - we can call the glib constructor twice now, at least on systems using musl libc due to limitations of their dynamic linker

Sorry, I was mistaken. glib_init has a guard that makes it return early if it has already run, while g_quark_init has the assert that aborts if it has already run.

Created attachment 313385 [details]
An error report dumped by Android-Studio.

Created attachment 313394 [details] [review]
Use -Wl,-znodelete for all our libraries

Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.

Like this ?

Review of attachment 313394 [details] [review]:

Note that this will also impact libgio.  That seems pretty reasonable, though.

Attachment 313394 [details] pushed as 2ac7c5a - Use -Wl,-znodelete for all our libraries

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