[PATCH v8 6/6] elf: Raise SIGABRT for assert within ld.so

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Mon Apr 20 18:36:14 GMT 2026



On 10/04/26 12:49, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 10/04/26 09:38, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> @@ -188,11 +232,11 @@ __assert_perror_fail (int errnum,
>>>>  		      const char *function)
>>>>  {
>>>>    char errbuf[400];
>>>> -  _dl_fatal_printf ("\
>>>> +  _dl_error_printf ("\
>>>>  Inconsistency detected by ld.so: %s: %u: %s%sUnexpected error: %s.\n",
>>>>  		    file, line, function ?: "", function ? ": " : "",
>>>>  		    __strerror_r (errnum, errbuf, sizeof errbuf));
>>>> -
>>>> +  rtld_abort ();
>>>>  }
>>>
>>> Would it make sense to change _dl_fatal_printf to abort instead?
>>>
>>> It requires changing the _dl_fatal_printf call in _dl_signal_error
>>> because we don't want to abort if loading fails due to a missing
>>> dependency.
>>
>> But assert usage in dl-load.c (and related functions) are for unexpected
>> and unhandled situations (like invalid r_debug->state). I do not think
>> making assert an error on dlopen the expected behavior, I would rather
>> check every assert usage and see if we can make it a _dl_signal_error.
> 
> Sorry, I meant the path that is executed if there's no exception
> handler.  That's used for internal dlopen failures of dependencies
> during startup (excluding preloading, loading auditors; those failures
> are ignored/warning only), and for lazy symbol binding failures later
> on.
> 
> If a handler is installed, _dl_signal_error does not call
> _dl_fatal_printf, and that should not change.

But the whole point of _dl_fatal_printf is printing the error message
and terminate the process.  What this change does it making both the
assert failure during process startup *and* during dlopen to act in
the same manner: printing the error message on STDERR_FILENO and stop
execution as abort was called.

Calling _dl_fatal_printf or not does not really matter, since assert 
calls use the barebone mode (no GLRO(dl_debug_fd) and not pid prepending).


More information about the Libc-alpha mailing list