Date: Fri, 29 Jan 2021 15:38:10 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 253081] fdlopen is broken in STABLE-12 Message-ID: <bug-253081-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253081 Bug ID: 253081 Summary: fdlopen is broken in STABLE-12 Product: Base System Version: 12.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: theraven@FreeBSD.org I am not sure exactly when this happened because I'd forgotten that I was carrying a local patch to rtld to fix it for a while and reverted to a pristine upstream after the new git migration to be reapply my patches. rtld fails in _rtld_bind with a library opened with fdlopen on this line: https://github.com/freebsd/freebsd-src/blob/f56d7f838f5b3aa0f55b10406eaa7eb760a3ba18/libexec/rtld-elf/rtld.c#L879 This line and the basename implementation it called appear not to have been modified in the last 23 years, so the root cause is, unfortunately, somewhere else (it's not actually clear to me that this code ever worked, unless perhaps `fdlopen` was never tested without `RTLD_NOW`?). Removing this line causes my code to work again but with it the call to `basename(obj->path`) crashes in the `strrchr` call because `obj->path` is null. I believe this is the expected behaviour with fdlopen, because the file descriptor (in my case, inherited from a parent). I have had a local patch to the `basename` implementation to handle being passed a null argument and return null, but this caller seems to be the only one that triggers it and so it's probably better to not call `basename` with a NULL argument on that line. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253081-227>