You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
postgres/src/backend/main/main.c

462 lines
16 KiB

/*-------------------------------------------------------------------------
*
* main.c
* Stub main() routine for the postgres executable.
*
* This does some essential startup tasks for any incarnation of postgres
* (postmaster, standalone backend, standalone bootstrap process, or a
* separately exec'd child of a postmaster) and then dispatches to the
* proper FooMain() routine for the incarnation.
*
*
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* src/backend/main/main.c
*
*-------------------------------------------------------------------------
*/
#include "postgres.h"
#include <unistd.h>
#if defined(WIN32)
#include <crtdbg.h>
#endif
#if defined(__NetBSD__)
#include <sys/param.h>
#endif
#include "bootstrap/bootstrap.h"
#include "common/username.h"
#include "miscadmin.h"
#include "port/atomics.h"
#include "postmaster/postmaster.h"
#include "storage/spin.h"
#include "tcop/tcopprot.h"
#include "utils/help_config.h"
Fix possible crashes due to using elog/ereport too early in startup. Per reports from Andres Freund and Luke Campbell, a server failure during set_pglocale_pgservice results in a segfault rather than a useful error message, because the infrastructure needed to use ereport hasn't been initialized; specifically, MemoryContextInit hasn't been called. One known cause of this is starting the server in a directory it doesn't have permission to read. We could try to prevent set_pglocale_pgservice from using anything that depends on palloc or elog, but that would be messy, and the odds of future breakage seem high. Moreover there are other things being called in main.c that look likely to use palloc or elog too --- perhaps those things shouldn't be there, but they are there today. The best solution seems to be to move the call of MemoryContextInit to very early in the backend's real main() function. I've verified that an elog or ereport occurring immediately after that is now capable of sending something useful to stderr. I also added code to elog.c to print something intelligible rather than just crashing if MemoryContextInit hasn't created the ErrorContext. This could happen if MemoryContextInit itself fails (due to malloc failure), and provides some future-proofing against someone trying to sneak in new code even earlier in server startup. Back-patch to all supported branches. Since we've only heard reports of this type of failure recently, it may be that some recent change has made it more likely to see a crash of this kind; but it sure looks like it's broken all the way back.
12 years ago
#include "utils/memutils.h"
#include "utils/pg_locale.h"
#include "utils/ps_status.h"
const char *progname;
static bool reached_main = false;
static void startup_hacks(const char *progname);
static void init_locale(const char *categoryname, int category, const char *locale);
static void help(const char *progname);
static void check_root(const char *progname);
/*
* Any Postgres server process begins execution here.
*/
int
main(int argc, char *argv[])
{
bool do_check_root = true;
reached_main = true;
/*
* If supported on the current platform, set up a handler to be called if
* the backend/postmaster crashes with a fatal signal or exception.
*/
#if defined(WIN32)
pgwin32_install_crashdump_handler();
#endif
progname = get_progname(argv[0]);
/*
* Platform-specific startup hacks
*/
startup_hacks(progname);
/*
* Remember the physical location of the initially given argv[] array for
* possible use by ps display. On some platforms, the argv[] storage must
* be overwritten in order to set the process title for ps. In such cases
* save_ps_display_args makes and returns a new copy of the argv[] array.
*
* save_ps_display_args may also move the environment strings to make
* extra room. Therefore this should be done as early as possible during
* startup, to avoid entanglements with code that might save a getenv()
* result pointer.
*/
argv = save_ps_display_args(argc, argv);
Fix possible crashes due to using elog/ereport too early in startup. Per reports from Andres Freund and Luke Campbell, a server failure during set_pglocale_pgservice results in a segfault rather than a useful error message, because the infrastructure needed to use ereport hasn't been initialized; specifically, MemoryContextInit hasn't been called. One known cause of this is starting the server in a directory it doesn't have permission to read. We could try to prevent set_pglocale_pgservice from using anything that depends on palloc or elog, but that would be messy, and the odds of future breakage seem high. Moreover there are other things being called in main.c that look likely to use palloc or elog too --- perhaps those things shouldn't be there, but they are there today. The best solution seems to be to move the call of MemoryContextInit to very early in the backend's real main() function. I've verified that an elog or ereport occurring immediately after that is now capable of sending something useful to stderr. I also added code to elog.c to print something intelligible rather than just crashing if MemoryContextInit hasn't created the ErrorContext. This could happen if MemoryContextInit itself fails (due to malloc failure), and provides some future-proofing against someone trying to sneak in new code even earlier in server startup. Back-patch to all supported branches. Since we've only heard reports of this type of failure recently, it may be that some recent change has made it more likely to see a crash of this kind; but it sure looks like it's broken all the way back.
12 years ago
/*
* Fire up essential subsystems: error and memory management
*
* Code after this point is allowed to use elog/ereport, though
* localization of messages may not work right away, and messages won't go
* anywhere but stderr until GUC settings get loaded.
*/
MyProcPid = getpid();
Fix possible crashes due to using elog/ereport too early in startup. Per reports from Andres Freund and Luke Campbell, a server failure during set_pglocale_pgservice results in a segfault rather than a useful error message, because the infrastructure needed to use ereport hasn't been initialized; specifically, MemoryContextInit hasn't been called. One known cause of this is starting the server in a directory it doesn't have permission to read. We could try to prevent set_pglocale_pgservice from using anything that depends on palloc or elog, but that would be messy, and the odds of future breakage seem high. Moreover there are other things being called in main.c that look likely to use palloc or elog too --- perhaps those things shouldn't be there, but they are there today. The best solution seems to be to move the call of MemoryContextInit to very early in the backend's real main() function. I've verified that an elog or ereport occurring immediately after that is now capable of sending something useful to stderr. I also added code to elog.c to print something intelligible rather than just crashing if MemoryContextInit hasn't created the ErrorContext. This could happen if MemoryContextInit itself fails (due to malloc failure), and provides some future-proofing against someone trying to sneak in new code even earlier in server startup. Back-patch to all supported branches. Since we've only heard reports of this type of failure recently, it may be that some recent change has made it more likely to see a crash of this kind; but it sure looks like it's broken all the way back.
12 years ago
MemoryContextInit();
/*
* Set up locale information
*/
set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("postgres"));
/*
* In the postmaster, absorb the environment values for LC_COLLATE and
* LC_CTYPE. Individual backends will change these later to settings
* taken from pg_database, but the postmaster cannot do that. If we leave
* these set to "C" then message localization might not work well in the
* postmaster.
*/
init_locale("LC_COLLATE", LC_COLLATE, "");
init_locale("LC_CTYPE", LC_CTYPE, "");
/*
* LC_MESSAGES will get set later during GUC option processing, but we set
* it here to allow startup error messages to be localized.
*/
#ifdef LC_MESSAGES
init_locale("LC_MESSAGES", LC_MESSAGES, "");
#endif
24 years ago
/*
* We keep these set to "C" always, except transiently in pg_locale.c; see
* that file for explanations.
24 years ago
*/
init_locale("LC_MONETARY", LC_MONETARY, "C");
init_locale("LC_NUMERIC", LC_NUMERIC, "C");
init_locale("LC_TIME", LC_TIME, "C");
/*
* Now that we have absorbed as much as we wish to from the locale
* environment, remove any LC_ALL setting, so that the environment
* variables installed by pg_perm_setlocale have force.
*/
unsetenv("LC_ALL");
/*
* Catch standard options before doing much else, in particular before we
* insist on not being root.
*/
if (argc > 1)
{
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
help(progname);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
Change pg_ctl to detect server-ready by watching status in postmaster.pid. Traditionally, "pg_ctl start -w" has waited for the server to become ready to accept connections by attempting a connection once per second. That has the major problem that connection issues (for instance, a kernel packet filter blocking traffic) can't be reliably told apart from server startup issues, and the minor problem that if server startup isn't quick, we accumulate "the database system is starting up" spam in the server log. We've hacked around many of the possible connection issues, but it resulted in ugly and complicated code in pg_ctl.c. In commit c61559ec3, I changed the probe rate to every tenth of a second. That prompted Jeff Janes to complain that the log-spam problem had become much worse. In the ensuing discussion, Andres Freund pointed out that we could dispense with connection attempts altogether if the postmaster were changed to report its status in postmaster.pid, which "pg_ctl start" already relies on being able to read. This patch implements that, teaching postmaster.c to report a status string into the pidfile at the same state-change points already identified as being of interest for systemd status reporting (cf commit 7d17e683f). pg_ctl no longer needs to link with libpq at all; all its functions now depend on reading server files. In support of this, teach AddToDataDirLockFile() to allow addition of postmaster.pid lines in not-necessarily-sequential order. This is needed on Windows where the SHMEM_KEY line will never be written at all. We still have the restriction that we don't want to truncate the pidfile; document the reasons for that a bit better. Also, fix the pg_ctl TAP tests so they'll notice if "start -w" mode is broken --- before, they'd just wait out the sixty seconds until the loop gives up, and then report success anyway. (Yes, I found that out the hard way.) While at it, arrange for pg_ctl to not need to #include miscadmin.h; as a rather low-level backend header, requiring that to be compilable client-side is pretty dubious. This requires moving the #define's associated with the pidfile into a new header file, and moving PG_BACKEND_VERSIONSTR someplace else. For lack of a clearly better "someplace else", I put it into port.h, beside the declaration of find_other_exec(), since most users of that macro are passing the value to find_other_exec(). (initdb still depends on miscadmin.h, but at least pg_ctl and pg_upgrade no longer do.) In passing, fix main.c so that PG_BACKEND_VERSIONSTR actually defines the output of "postgres -V", which remarkably it had never done before. Discussion: https://postgr.es/m/CAMkU=1xJW8e+CTotojOMBd-yzUvD0e_JZu2xHo=MnuZ4__m7Pg@mail.gmail.com
9 years ago
fputs(PG_BACKEND_VERSIONSTR, stdout);
exit(0);
}
/*
* In addition to the above, we allow "--describe-config" and "-C var"
* to be called by root. This is reasonably safe since these are
* read-only activities. The -C case is important because pg_ctl may
* try to invoke it while still holding administrator privileges on
* Windows. Note that while -C can normally be in any argv position,
* if you want to bypass the root check you must put it first. This
* reduces the risk that we might misinterpret some other mode's -C
* switch as being the postmaster/postgres one.
*/
if (strcmp(argv[1], "--describe-config") == 0)
do_check_root = false;
else if (argc > 2 && strcmp(argv[1], "-C") == 0)
do_check_root = false;
}
/*
* Make sure we are not running as root, unless it's safe for the selected
* option.
*/
if (do_check_root)
check_root(progname);
/*
* Dispatch to one of various subprograms depending on first argument.
*/
if (argc > 1 && strcmp(argv[1], "--check") == 0)
BootstrapModeMain(argc, argv, true);
else if (argc > 1 && strcmp(argv[1], "--boot") == 0)
BootstrapModeMain(argc, argv, false);
#ifdef EXEC_BACKEND
else if (argc > 1 && strncmp(argv[1], "--fork", 6) == 0)
SubPostmasterMain(argc, argv);
#endif
else if (argc > 1 && strcmp(argv[1], "--describe-config") == 0)
GucInfoMain();
else if (argc > 1 && strcmp(argv[1], "--single") == 0)
PostgresSingleUserMain(argc, argv,
strdup(get_user_name_or_exit(progname)));
else
PostmasterMain(argc, argv);
/* the functions above should not return */
abort();
}
/*
* Place platform-specific startup hacks here. This is the right
* place to put code that must be executed early in the launch of any new
* server process. Note that this code will NOT be executed when a backend
* or sub-bootstrap process is forked, unless we are in a fork/exec
* environment (ie EXEC_BACKEND is defined).
*
* XXX The need for code here is proof that the platform in question
* is too brain-dead to provide a standard C execution environment
* without help. Avoid adding more here, if you can.
*/
static void
startup_hacks(const char *progname)
{
/*
* Windows-specific execution environment hacking.
*/
#ifdef WIN32
{
WSADATA wsaData;
int err;
/* Make output streams unbuffered by default */
setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stderr, NULL, _IONBF, 0);
/* Prepare Winsock */
err = WSAStartup(MAKEWORD(2, 2), &wsaData);
if (err != 0)
{
write_stderr("%s: WSAStartup failed: %d\n",
progname, err);
exit(1);
}
/*
* By default abort() only generates a crash-dump in *non* debug
* builds. As our Assert() / ExceptionalCondition() uses abort(),
* leaving the default in place would make debugging harder.
*
* MINGW's own C runtime doesn't have _set_abort_behavior(). When
* targeting Microsoft's UCRT with mingw, it never links to the debug
* version of the library and thus doesn't need the call to
* _set_abort_behavior() either.
*/
#if !defined(__MINGW32__) && !defined(__MINGW64__)
_set_abort_behavior(_CALL_REPORTFAULT | _WRITE_ABORT_MSG,
_CALL_REPORTFAULT | _WRITE_ABORT_MSG);
#endif /* !defined(__MINGW32__) &&
* !defined(__MINGW64__) */
/*
* SEM_FAILCRITICALERRORS causes more errors to be reported to
* callers.
*
* We used to also specify SEM_NOGPFAULTERRORBOX, but that prevents
* windows crash reporting from working. Which includes registered
* just-in-time debuggers, making it unnecessarily hard to debug
* problems on windows. Now we try to disable sources of popups
* separately below (note that SEM_NOGPFAULTERRORBOX did not actually
* prevent all sources of such popups).
*/
SetErrorMode(SEM_FAILCRITICALERRORS);
/*
* Show errors on stderr instead of popup box (note this doesn't
* affect errors originating in the C runtime, see below).
*/
_set_error_mode(_OUT_TO_STDERR);
/*
* In DEBUG builds, errors, including assertions, C runtime errors are
* reported via _CrtDbgReport. By default such errors are displayed
* with a popup (even with NOGPFAULTERRORBOX), preventing forward
* progress. Instead report such errors stderr (and the debugger).
* This is C runtime specific and thus the above incantations aren't
* sufficient to suppress these popups.
*/
_CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile(_CRT_ERROR, _CRTDBG_FILE_STDERR);
_CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile(_CRT_ASSERT, _CRTDBG_FILE_STDERR);
_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDERR);
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
9 years ago
#endif /* WIN32 */
/*
* Initialize dummy_spinlock, in case we are on a platform where we have
* to use the fallback implementation of pg_memory_barrier().
*/
SpinLockInit(&dummy_spinlock);
}
/*
* Make the initial permanent setting for a locale category. If that fails,
* perhaps due to LC_foo=invalid in the environment, use locale C. If even
* that fails, perhaps due to out-of-memory, the entire startup fails with it.
* When this returns, we are guaranteed to have a setting for the given
* category's environment variable.
*/
static void
init_locale(const char *categoryname, int category, const char *locale)
{
if (pg_perm_setlocale(category, locale) == NULL &&
pg_perm_setlocale(category, "C") == NULL)
elog(FATAL, "could not adopt \"%s\" locale nor C locale for %s",
locale, categoryname);
}
/*
* Help display should match the options accepted by PostmasterMain()
* and PostgresMain().
Renovate display of non-ASCII messages on Windows. GNU gettext selects a default encoding for the messages it emits in a platform-specific manner; it uses the Windows ANSI code page on Windows and follows LC_CTYPE on other platforms. This is inconvenient for PostgreSQL server processes, so realize consistent cross-platform behavior by calling bind_textdomain_codeset() on Windows each time we permanently change LC_CTYPE. This primarily affects SQL_ASCII databases and processes like the postmaster that do not attach to a database, making their behavior consistent with PostgreSQL on non-Windows platforms. Messages from SQL_ASCII databases use the encoding implied by the database LC_CTYPE, and messages from non-database processes use LC_CTYPE from the postmaster system environment. PlatformEncoding becomes unused, so remove it. Make write_console() prefer WriteConsoleW() to write() regardless of the encodings in use. In this situation, write() will invariably mishandle non-ASCII characters. elog.c has assumed that messages conform to the database encoding. While usually true, this does not hold for SQL_ASCII and MULE_INTERNAL. Introduce MessageEncoding to track the actual encoding of message text. The present consumers are Windows-specific code for converting messages to UTF16 for use in system interfaces. This fixes the appearance in Windows event logs and consoles of translated messages from SQL_ASCII processes like the postmaster. Note that SQL_ASCII inherently disclaims a strong notion of encoding, so non-ASCII byte sequences interpolated into messages by %s may yet yield a nonsensical message. MULE_INTERNAL has similar problems at present, albeit for a different reason: its lack of libiconv support or a conversion to UTF8. Consequently, one need no longer restart Windows with a different Windows ANSI code page to broadly test backend logging under a given language. Changing the user's locale ("Format") is enough. Several accounts can simultaneously run postmasters under different locales, all correctly logging localized messages to Windows event logs and consoles. Alexander Law and Noah Misch
13 years ago
*
* XXX On Windows, non-ASCII localizations of these messages only display
* correctly if the console output code page covers the necessary characters.
* Messages emitted in write_console() do not exhibit this problem.
*/
static void
help(const char *progname)
{
printf(_("%s is the PostgreSQL server.\n\n"), progname);
printf(_("Usage:\n %s [OPTION]...\n\n"), progname);
printf(_("Options:\n"));
printf(_(" -B NBUFFERS number of shared buffers\n"));
printf(_(" -c NAME=VALUE set run-time parameter\n"));
printf(_(" -C NAME print value of run-time parameter, then exit\n"));
printf(_(" -d 1-5 debugging level\n"));
printf(_(" -D DATADIR database directory\n"));
printf(_(" -e use European date input format (DMY)\n"));
printf(_(" -F turn fsync off\n"));
printf(_(" -h HOSTNAME host name or IP address to listen on\n"));
printf(_(" -i enable TCP/IP connections (deprecated)\n"));
printf(_(" -k DIRECTORY Unix-domain socket location\n"));
#ifdef USE_SSL
printf(_(" -l enable SSL connections\n"));
#endif
printf(_(" -N MAX-CONNECT maximum number of allowed connections\n"));
printf(_(" -p PORT port number to listen on\n"));
printf(_(" -s show statistics after each query\n"));
printf(_(" -S WORK-MEM set amount of memory for sorts (in kB)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" --NAME=VALUE set run-time parameter\n"));
printf(_(" --describe-config describe configuration parameters, then exit\n"));
printf(_(" -?, --help show this help, then exit\n"));
printf(_("\nDeveloper options:\n"));
printf(_(" -f s|i|o|b|t|n|m|h forbid use of some plan types\n"));
printf(_(" -O allow system table structure changes\n"));
printf(_(" -P disable system indexes\n"));
printf(_(" -t pa|pl|ex show timings after each query\n"));
printf(_(" -T send SIGABRT to all backend processes if one dies\n"));
printf(_(" -W NUM wait NUM seconds to allow attach from a debugger\n"));
printf(_("\nOptions for single-user mode:\n"));
printf(_(" --single selects single-user mode (must be first argument)\n"));
printf(_(" DBNAME database name (defaults to user name)\n"));
printf(_(" -d 0-5 override debugging level\n"));
printf(_(" -E echo statement before execution\n"));
printf(_(" -j do not use newline as interactive query delimiter\n"));
printf(_(" -r FILENAME send stdout and stderr to given file\n"));
printf(_("\nOptions for bootstrapping mode:\n"));
printf(_(" --boot selects bootstrapping mode (must be first argument)\n"));
printf(_(" --check selects check mode (must be first argument)\n"));
printf(_(" DBNAME database name (mandatory argument in bootstrapping mode)\n"));
printf(_(" -r FILENAME send stdout and stderr to given file\n"));
printf(_("\nPlease read the documentation for the complete list of run-time\n"
"configuration settings and how to set them on the command line or in\n"
"the configuration file.\n\n"
"Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);
printf(_("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
}
static void
check_root(const char *progname)
{
#ifndef WIN32
if (geteuid() == 0)
{
write_stderr("\"root\" execution of the PostgreSQL server is not permitted.\n"
"The server must be started under an unprivileged user ID to prevent\n"
"possible system security compromise. See the documentation for\n"
"more information on how to properly start the server.\n");
exit(1);
}
/*
* Also make sure that real and effective uids are the same. Executing as
* a setuid program from a root shell is a security hole, since on many
* platforms a nefarious subroutine could setuid back to root if real uid
* is root. (Since nobody actually uses postgres as a setuid program,
* trying to actively fix this situation seems more trouble than it's
* worth; we'll just expend the effort to check for it.)
*/
if (getuid() != geteuid())
{
write_stderr("%s: real and effective user IDs must match\n",
progname);
exit(1);
}
#else /* WIN32 */
if (pgwin32_is_admin())
{
write_stderr("Execution of PostgreSQL by a user with administrative permissions is not\n"
"permitted.\n"
"The server must be started under an unprivileged user ID to prevent\n"
"possible system security compromises. See the documentation for\n"
"more information on how to properly start the server.\n");
exit(1);
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
9 years ago
#endif /* WIN32 */
}
/*
* At least on linux, set_ps_display() breaks /proc/$pid/environ. The
* sanitizer library uses /proc/$pid/environ to implement getenv() as it wants
* to work independent of libc. Depending on which sanitizers are enabled,
* the sanitizer library may not get initialized until after we've called
* set_ps_display(), preventing the sanitizer from seeing environment-supplied
* options.
*
* We can work around that by defining __ubsan_default_options, a weak symbol
* libsanitizer uses to get defaults from the application, and return
* getenv("UBSAN_OPTIONS"). But only if main already was reached, so that we
* don't end up relying on a not-yet-working getenv().
*
* On the other hand, with different sanitizers enabled, libsanitizer can
* call this so early that it's not fully initialized itself, resulting in
* recursion and a core dump within libsanitizer. To prevent that, ensure
* that this function is built without any sanitizer callbacks in it.
*
* As this function won't get called when not running a sanitizer, it doesn't
* seem necessary to only compile it conditionally.
*/
const char *__ubsan_default_options(void);
#if __has_attribute(disable_sanitizer_instrumentation)
__attribute__((disable_sanitizer_instrumentation))
#endif
const char *
__ubsan_default_options(void)
{
/* don't call libc before it's guaranteed to be initialized */
if (!reached_main)
return "";
return getenv("UBSAN_OPTIONS");
}