After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 563546 - at-spi should not use g_atexit
at-spi should not use g_atexit
Status: RESOLVED OBSOLETE
Product: at-spi
Classification: Platform
Component: atkbridge
unspecified
Other Linux
: Normal critical
: ---
Assigned To: At-spi maintainer(s)
At-spi maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-12-07 09:58 UTC by timeless
Modified: 2014-11-17 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description timeless 2008-12-07 09:58:10 UTC
http://www.google.com/codesearch?hl=en&q=spi_atk_bridge_do_registration+show:qa9IwCXXvts:BJpYktsESsg:B5uY2O14LB0&sa=N&cd=2&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/at-spi-1.18.0.tar.bz2&cs_f=at-spi-1.18.0/atk-bridge/bridge.c#l261

static gboolean
spi_atk_bridge_do_registration (void)
{

  g_atexit (spi_atk_bridge_exit_func);

http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-atexit
Specifies a function to be called at normal program termination.

...
The behaviour of atexit() in the context of dynamically loaded modules is not
formally specified and varies wildly.

On POSIX systems, calling g_atexit() (or atexit()) in a dynamically loaded
module which is unloaded before the program terminates might well cause a crash
at program exit.
...
As can be seen from the above, for portability it's best to avoid calling
g_atexit() (or atexit()) except in the main executable of a program.

downstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=468239
Comment 1 Alejandro Piñeiro Iglesias (IRC: infapi00) 2009-06-02 10:05:25 UTC
Related to that: http://bugzilla.gnome.org/show_bug.cgi?id=552329#c2, that causes a crash too

I added a solution in that bug, but if finally the call to g_atexit is avoided, it will not be required. 
Comment 2 Li Yuan 2009-06-03 09:10:33 UTC
I will try to replace g_atexit with gtk_quit_add
Comment 3 timeless 2009-06-03 10:44:13 UTC
Is there a requirement that gtk_quit_add will be used before your library is unloaded?

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3448
2558 XRE_main(int argc, char* argv[], const nsXREAppData* aAppData)
3151       ScopedXPCOMStartup xpcom;

http://mxr.mozilla.org/mozilla-central/source/xpcom/build/nsXPComInit.cpp#764
738 NS_ShutdownXPCOM(nsIServiceManager* servMgr)
764                     NotifyObservers(mgr, NS_XPCOM_SHUTDOWN_OBSERVER_ID,
http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsAccessibilityService.cpp#141
150 nsAccessibilityService::Observe(nsISupports *aSubject, const char *aTopic,
162     nsAccessNodeWrap::ShutdownAccessibility();
http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/nsAccessNodeWrap.cpp#74
72 void nsAccessNodeWrap::ShutdownAccessibility()
74   nsAccessNode::ShutdownXPAccessibility();
http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsAccessNode.cpp#335
318 void nsAccessNode::ShutdownXPAccessibility()
335   nsApplicationAccessibleWrap::Unload();
http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/nsAppRootAccessible.cpp#583
583 nsApplicationAccessibleWrap::Unload()
--- this is where we want and expect to be able to unload your library ---

I believe that in embedding cases, it's possible that the main main loop hasn't gone away yet.

As it happens, for Firefox and standard XULRunner applications, 
I don't think we even *have* in normal circumstances a gtk main loop.

http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsAppShell.cpp#142
142 nsAppShell::ProcessNextNativeEvent(PRBool mayWait)
144     return g_main_context_iteration(NULL, mayWait);

... is how we process events.

What you really need to do is have *two* ways of shutting down:
1. some magical way
2. an exported public function

If the public exported function is called, then you need to *unregister* your magical way and die.

If your magical way happens, then you just perform your magic (but make sure that you don't crash if someone calls the public exported function).
Comment 4 Li Yuan 2009-06-25 02:42:56 UTC
(In reply to comment #3)

> 
> What you really need to do is have *two* ways of shutting down:
> 1. some magical way
> 2. an exported public function
> 
> If the public exported function is called, then you need to *unregister* your
> magical way and die.
> 
> If your magical way happens, then you just perform your magic (but make sure
> that you don't crash if someone calls the public exported function).
> 
Right, we do have a public function: gnome_accessibility_module_shutdown.

Comment 5 timeless 2009-06-25 06:12:59 UTC
ok :)
Comment 6 André Klapper 2012-02-26 10:43:32 UTC
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". 
Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports.

IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
Comment 7 André Klapper 2013-08-14 10:06:34 UTC
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
Comment 8 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-11-17 17:03:27 UTC
This is an really old bug, and in addition atkbridge is not maintained anymore. Closing bug.