How to test if dlclose is a no-op?

How to test if dlclose is a no-op?

[Thadeus Fleming]

In the spirit of not “assum[ing] a certain implementation has particular properties rather than testing,” how can one test if dlclose is a no-op, as it is in musl, without breaking things if it isn’t?

Re: How to test if dlclose is a no-op?

[Rich Felker]

On Thu, Mar 15, 2018 at 08:32:34AM -0500, Thadeus Fleming wrote:
> In the spirit of not “assum[ing] a certain implementation has
> particular properties rather than testing,” how can one test if
> dlclose is a no-op, as it is in musl, without breaking things if it
> isn’t?

This sounds like an XY problem¹. Do you care about whether you can
recover virtual memory space, whether the underlying fs objects remain
referenced, whether there's a cycle of dtors and ctors running, or
something else?

FYI there is no clear answer to the question even on other
implementations. glibc only sometimes unloads; there are corner cases
and race-type conditions where unloading is impossible for them. You
really should not be designing around an assumption/requirement that
anything get unloaded.

Rich



¹ http://xyproblem.info/

Re: How to test if dlclose is a no-op?

[Thadeus Fleming]

I'm working on improving a system that makes some bad assumptions
about dynamic unloading. While I'm not fond of dynamic unloading, I
think it might be valuable to be able to distinguish between "this C
library doesn't support unloading at all" and "if the planets are all
aligned, unloading might work." Testing if dlclose is a no-op would
allow me to make that distinction.


On Thu, Mar 15, 2018 at 9:40 AM, Rich Felker <dalias@libc.org> wrote:
> On Thu, Mar 15, 2018 at 08:32:34AM -0500, Thadeus Fleming wrote:
>> In the spirit of not “assum[ing] a certain implementation has
>> particular properties rather than testing,” how can one test if
>> dlclose is a no-op, as it is in musl, without breaking things if it
>> isn’t?
>
> This sounds like an XY problem¹. Do you care about whether you can
> recover virtual memory space, whether the underlying fs objects remain
> referenced, whether there's a cycle of dtors and ctors running, or
> something else?
>
> FYI there is no clear answer to the question even on other
> implementations. glibc only sometimes unloads; there are corner cases
> and race-type conditions where unloading is impossible for them. You
> really should not be designing around an assumption/requirement that
> anything get unloaded.
>
> Rich
>
>
>
> ¹ http://xyproblem.info/

Re: How to test if dlclose is a no-op?

[Rich Felker]

On Thu, Mar 15, 2018 at 10:24:05AM -0500, Thadeus Fleming wrote:
> I'm working on improving a system that makes some bad assumptions
> about dynamic unloading. While I'm not fond of dynamic unloading, I
> think it might be valuable to be able to distinguish between "this C
> library doesn't support unloading at all" and "if the planets are all
> aligned, unloading might work." Testing if dlclose is a no-op would
> allow me to make that distinction.

Well obviously you can do something like dlopen/dlclose/dlopen of the
same library (a specially crafted probe library) with a ctor and
observe whether ctor ran once or twice. But it seems like if you fix
whatever bad assumptions the code has to the point that it runs
correctly on musl, it will run correctly everywhere without caring
what the behavior is.

Rich


> On Thu, Mar 15, 2018 at 9:40 AM, Rich Felker <dalias@libc.org> wrote:
> > On Thu, Mar 15, 2018 at 08:32:34AM -0500, Thadeus Fleming wrote:
> >> In the spirit of not “assum[ing] a certain implementation has
> >> particular properties rather than testing,” how can one test if
> >> dlclose is a no-op, as it is in musl, without breaking things if it
> >> isn’t?
> >
> > This sounds like an XY problem¹. Do you care about whether you can
> > recover virtual memory space, whether the underlying fs objects remain
> > referenced, whether there's a cycle of dtors and ctors running, or
> > something else?
> >
> > FYI there is no clear answer to the question even on other
> > implementations. glibc only sometimes unloads; there are corner cases
> > and race-type conditions where unloading is impossible for them. You
> > really should not be designing around an assumption/requirement that
> > anything get unloaded.
> >
> > Rich
> >
> >
> >
> > ¹ http://xyproblem.info/