GNOME Bugzilla – Bug 659145
Use g_app_info_launch_default_for_uri and g_app_launch_context_unsetenv instead of g_unsetenv and other launch commands
Last modified: 2013-12-14 20:31:50 UTC
I'm using GNOME 3.1.91 from arch's gnome-unstable. Here's a proper trace: http://pastebin.com/79dUKKsM
Please paste trace in bug next time. (gdb) epiphany Undefined command: "epiphany". Try "help". (gdb) run epiphany Starting program: /usr/bin/epiphany epiphany [Thread debugging using libthread_db enabled] [New Thread 0xb39c2b70 (LWP 10222)] [New Thread 0xb31c1b70 (LWP 10224)] [New Thread 0xb29c0b70 (LWP 10228)] [New Thread 0xb2095b70 (LWP 10229)] Program received signal SIGSEGV, Segmentation fault. 0xb5ce8688 in strcmp () from /lib/libc.so.6 (gdb) bt
+ Trace 228456
can you please install debuginfo packages of seed-gtk3, glib, gtk3 and gobject and provide us updated trace.
Re-compiled, installed. It gives this! Starting program: /usr/bin/epiphany epiphany [Thread debugging using libthread_db enabled] (epiphany:8062): Egg-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported [New Thread 0xb3a36b70 (LWP 8067)] [New Thread 0xb3235b70 (LWP 8068)] (epiphany:8062): GLib-GIO-CRITICAL **: Timeout was reached [Thread 0xb3235b70 (LWP 8068) exited] [Thread 0xb3a36b70 (LWP 8067) exited] [Inferior 1 (process 8062) exited with code 01]
(gdb) run epiphany Starting program: /usr/bin/epiphany epiphany [Thread debugging using libthread_db enabled] [New Thread 0xb3a16b70 (LWP 27894)] [New Thread 0xb3215b70 (LWP 27895)] [New Thread 0xb28ffb70 (LWP 27896)] [New Thread 0xb1fd4b70 (LWP 27897)] Program received signal SIGSEGV, Segmentation fault. 0xb5d38688 in strcmp () from /lib/libc.so.6 (gdb) bt
+ Trace 228471
This is because of the issue described in bug 659326; setenv/putenv/unsetenv are not thread-safe. So, all environment munging needs to happen before the dbus thread is created (which currently happens when you call gsettings to check for lockdown, ephy-main.c:386)
Everything is working fine in 3.1.92
I take it back, it worked at first but I'm getting the same error again.
Well, if it's only about the startup, this should be easily fixable by moving the g_setenv() call earlier in main()...
Created attachment 197606 [details] [review] Make g_setenv() calls early enough during startup g_setenv() and getenv() are not thread-safe, so we need to make sure that g_setenv() call in main is done earlier than anything that can trigger a getenv() call.
there are other g_setenv()/g_unsetenv() calls elsewhere in the tree
Created attachment 197611 [details] [review] make g_setenv() calls early enough during startup g_setenv() and getenv() are not thread-safe, so we need to make sure that g_setenv() call in main is done earlier than anything that can trigger a getenv() call.
Comment on attachment 197606 [details] [review] Make g_setenv() calls early enough during startup I can't spot any other ephy calls besides these. Or do you mean something else?
(In reply to comment #12) > (From update of attachment 197606 [details] [review]) > I can't spot any other ephy calls besides these. Or do you mean something else? that covers the setenv()s, but unsetenv() is a problem too. The unsetenv() cases are also harder to fix... hm... we probably want some new API at the glib level to help out here. As far as it goes, the patch looks right, and will at least fix the "randomly fails to start up sometimes" problem. The unsetenv()s probably trigger the bug less often anyway, since there's not as much all-going-on-at-the-same-time-in-different-threads once startup is complete...
(In reply to comment #13) > The unsetenv() cases are also harder to fix... hm... we probably want some new > API at the glib level to help out here. That happened, btw. ephy-window.c:policy_decision_required_cb() should use g_app_info_launch_default_for_uri() after using g_app_launch_context_unsetenv() on the launch context. Similarly in window-commands.c:notify_launch_cb().
Comment on attachment 197611 [details] [review] make g_setenv() calls early enough during startup I've pushed this as 7b548bc81703ac315cfd7ccbc335f65adfe0ba89. Leaving the bug open to fix the rest of the calls.
Actually the two remaining cases are pretty nasty hacks anyway, so making them safer is OK but ideally we should figure out something else entirely.
The only g_setenv's are now in ephy_embed_shell_setup_environment() which is only called by application_class->startup = ephy_embed_shell_startup; While those setenvs may not be great I don't think there are any threading concerns with that. Will consider this fixed.