Created attachment 207447 [details] patch Use closefrom() to avoid call close() for all possible descriptors
This change is best suited to submitting upstream first. Please create an issue or PR upstream, and add the issue/PR URL reference to the patch so we can track the patch locally until a future release comes out with the change
Comment on attachment 207447 [details] patch Upstream PR: https://gitlab.freedesktop.org/dbus/dbus/merge_requests/124
ping
maintainer timeout
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=aee4556063e8770fd0e4fd28a29f30626d6e235a commit aee4556063e8770fd0e4fd28a29f30626d6e235a Author: Adriaan de Groot <adridg@FreeBSD.org> AuthorDate: 2021-05-13 22:57:15 +0000 Commit: Adriaan de Groot <adridg@FreeBSD.org> CommitDate: 2021-05-14 19:08:18 +0000 devel/dbus: use closefrom() Don't do 1021 calls to close() when a single closefrom() will do. This patch has been submitted upstream (by the reporter) but is languishing there; there's a big difference between upstream's development branch and the released stable version. I've taken the initial patch from FreeBSD bugzilla, lightly mutated it with upstream work. PR: 240549 Reported by: rozhuk.im@gmail.com devel/dbus/Makefile | 2 +- .../files/patch-cmake_ConfigureChecks.cmake (new) | 10 ++++++++++ devel/dbus/files/patch-cmake_config.h.cmake (new) | 12 ++++++++++++ .../dbus/files/patch-dbus_dbus-sysdeps-unix.c (new) | 21 +++++++++++++++++++++ 4 files changed, 44 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #5) ... +#cmakedefine HAVE_CLOSEFROM 1 ... +#ifdef __FreeBSD__ ... Why __FreeBSD__ and not HAVE_CLOSEFROM?
The buildsystem is (still) autotools and the patch that is in the DBus MR doesn't apply cleanly to the older (stable) version we ship; I could adjust it to patching the configure.ac from the release, but that means then running all the autotools as part of the build. And for what? There's no version of ports that we care about, that would not end up defining HAVE_CLOSEFROM; I suppose I could have used `#if 1` as well. I do hope the MR lands upstream, but development seems a bit bogged down there.
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/265 landed
Created attachment 247139 [details] patch We got this issue again. DBus 1.14 does not have landed changes, and patch has missed from ports tree: https://gitlab.freedesktop.org/dbus/dbus/-/blob/dbus-1.14/dbus/dbus-sysdeps-unix.c#L4792 Master have it: https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-sysdeps-unix.c#L4969 I do test it with 13/stable (build) and 14/stable (build+run).
Created attachment 247140 [details] patch
Reopening. Patch with backported changes.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=54ceee079e36b05345e715d8eb3139960ff0a325 commit 54ceee079e36b05345e715d8eb3139960ff0a325 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2024-01-01 19:33:47 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2024-01-01 19:40:07 +0000 devel/dbus: Pull in a patch that uses closefrom(2) PR: 240549 devel/dbus/Makefile | 2 +- devel/dbus/files/patch-cmake_ConfigureChecks.cmake | 26 ++++--- devel/dbus/files/patch-cmake_config.h.cmake | 7 +- devel/dbus/files/patch-configure (new) | 25 ++++++ .../files/patch-dbus_dbus-sysdeps-unix.c (new) | 89 ++++++++++++++++++++++ 5 files changed, 137 insertions(+), 12 deletions(-)