[PATCH] libwbclient clear pointer on bad read

[Matthew Newton]

On Tue, Jan 20, 2015 at 08:38:04AM +0100, Volker Lendecke wrote:
> On Tue, Jan 20, 2015 at 08:08:11AM +0100, Andreas Schneider wrote:
> > Great work, thanks. Could you please make is_privileged a bool? :)
> 
> Well, it wasn't before, so this is an add-on, right?

It was int before, which is why I left it like that. Fight it out
amongst yourselves and let me know the outcome, and I'll update
the patch :-) Can't see it really matters much.

> There's one question I have: Does the pthread_create_key
> destructor also kick in if we are unloaded via dlclose()? We
> had to specificially add the __attribute__((destructor))
> to fix a fd leak in long-running apps that load and unload
> us. I believe some apache module did this. I'd not like to
> re-introduce this fd leak again.

I think you're right - it looks like pthread_key_create() allocates
storage for the TLS key data, and pthread_key_delete() needs to be
called in the library destructor. I'm trying to find some good
reading material on it however, as it looks like it may not be
entirely safe on all platforms.

My limited understanding so far is that not all implementations
call the destructor on dlclose, but as pthread_key_create() is
always called it leads to memory leaks on those systems.

There also seems to be an issue as some applications may call
dlclose() before all threads have exited, causing a segfault at
thread exit when the TLS destructor is called. Though I think I'd
personally call it an application bug to call dlclose() when
threads are still running...

If anyone's got any clear insight on this then it would be welcome
:-)

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>