[4274] in BarnOwl Developers
[barnowl/barnowl] 1f65ae: Properly check for dlsym() errors
daemon@ATHENA.MIT.EDU (kaduk)
Thu Aug 14 23:36:21 2025
Date: Thu, 14 Aug 2025 20:36:17 -0700
From: kaduk <noreply@github.com>
To: barnowl-dev@mit.edu
Branch: refs/heads/master
Home: https://github.com/barnowl/barnowl
Commit: 1f65aee2011f5e938da110a9dcfe741b0a7c1d03
https://github.com/barnowl/barnowl/commit/1f65aee2011f5e938da110a9dcfe741b0a7c1d03
Author: Benjamin Kaduk <kaduk@mit.edu>
Date: 2025-08-13 (Wed, 13 Aug 2025)
Changed paths:
M closures.c
Log Message:
-----------
Properly check for dlsym() errors
In closures.c we dlopen() the main process address space so we can get
references to gvalue_from_sv, sv_from_gvalue, and perl_closure_new, but
we only check for errors by seeing if dlerror() returns a non-NULL
pointer (string). This is not correct, since we are only supposed to
inspect dlerror()'s contents if one of a certain list of functions has
returned an error (dlerror() returns information about the latest such
error).
This causes problems on FreeBSD, where the NSS implementation in libc
performs a dlsym() lookup of a "_nss_cache_cycle_protection_function"
symbls, which fails in all processes other than nscd. The FreeBSD libc
does not subsequently call dlerror() to clear the error string and so
it remains cached until we inspect it, and we erroneously treat this
cached value as indicating an error in our dlsym() usage, which trickles
up and becomes a fatal error at startup.
Fix the issue by only calling dlerror() if we experienced an error
return from dlsym() or dlclose(), clearing res to NULL in the success
case.
To unsubscribe from these emails, change your notification settings at https://github.com/barnowl/barnowl/settings/notifications
