1056130 - We need a function to quit immediately without running any destructors

Status: NEW

(Toolkit :: General, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

At least two ongoing projects (bug 662444, bug 1038342) need to quit Firefox immediately, without running any destructors. Apparently, calling `_exit(0)` should be sufficient, but this is something that needs to be checked for every tier 1 platform.

Opening this bug to
1/ provide an API to quit Firefox immediately;
2/ run all the tests to make sure that we are doing the right thing on all platforms.

Things we wish to test:
- don't run local destructors;
- don't run static destructors;
- don't run static destructors defined in .so/.dll objects.

Comment 1

[brunoais]

I think that addons that ask to be warned should be warned about the shutdown so that they can do something about it (e.g. finish writing data to disk).
But always give a timeout, don't let them hang for too long.

Sounds reasonable?

Comment 2

[David Teller [:Yoric] - still alive but not very active]

We already have AsyncShutdown for that purpose. This here function is designed to be used once it's way too late for this purpose.

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Mike, do you know if there is a way to write a test in which we build a custom .so/.dll/.dynlib and link to it?

Comment 4

[David Teller [:Yoric] - still alive but not very active]

As suggested by glandium over irc, we don't have to use `_exit(0)`. We can also use:
- `kill(getpid, KILL)` under Unix;
- `TerminateProcess(GetCurrentProcess())` under Windows.

Comment 5

[David Teller [:Yoric] - still alive but not very active]

Aaron, is there anything we can do to unlock the profile prior to calling `_exit`/`kill`/`TerminateProcess`? Note that this function may be called from a watchdog thread as a consequence of the main thread being frozen.

Comment 6

[Benjamin Smedberg]

There is a question currently about whether TerminateProcess runs some DllMain detach functions. The docs say that it doesn't, but see the craziness in bug 980580. That's why I'd really like to have a test of whatever we do here.

In terms of the mechanics of the test, build a DLL using normal machinery and then load it from an xpcshell subharness using ctypes?

Comment 7

[David Teller [:Yoric] - still alive but not very active]

Would this work? I mean, if I find a way to build a DLL from a test, will this DLL be found by PR_LoadLibraryWithFlags (which is what js-ctypes uses)? I have no clear idea how libraries are searched on all platforms, but I'm a bit suspicious about that.

Comment 8

[Benjamin Smedberg]

You have to install the DLL into the test directories as a support file and then use a path, but yes, it works. See e.g. http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/test/Makefile.in which does the same thing for the existing crashreporter tests and http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/test/CrashTestUtils.jsm which loads/uses that file.

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to David Rajchenbach-Teller [:Yoric] (use "needinfo") from comment #5)
> Aaron, is there anything we can do to unlock the profile prior to calling
> `_exit`/`kill`/`TerminateProcess`? Note that this function may be called
> from a watchdog thread as a consequence of the main thread being frozen.

TerminateProcess should be sufficient. File locking is a consequence of the lock file being opened without any of the sharing flags specified. When the process is terminated, its handle to the lock file will be closed so the profile will henceforth be considered to be unlocked.

Comment 10

[David Teller [:Yoric] - still alive but not very active]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> In terms of the mechanics of the test, build a DLL using normal machinery
> and then load it from an xpcshell subharness using ctypes?

How can I make sure that the DLL is not shipped?

Comment 11

[David Teller [:Yoric] - still alive but not very active]

Ah, right. Just don't include it in package-manifest.in.