This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Finding all the places a variant of close() is called


On Friday, August 19, 2011 12:02:31 Justin McCann wrote:
> For a research project, I've been working on tracking socket-related
> system calls in Linux. I've been relatively successful doing library
> interposition using LD_PRELOAD and intercepting socket(), close(),
> bind(), accept(), connect(), listen(), etc. However, I've run into
> several cases where it appears the libc close() function isn't being
> called, but the file descriptor is clearly being returned to the
> operating system.
> 
> I've also intercepted __close(), __res_nclose(), and __res_iclose()
> since some of those appeared to be used within libc itself during DNS
> lookups.
> 
> It seems that there are still some cases that I miss. Other than
> taking another approach (ptrace, kernel module, etc), what other
> functions should I intercept to make sure I have all the ways a
> program might close a file descriptor?
> 
> Am I screwing up by not also intercepting fopen, fdopen, freopen, and
> fclose?
> 
> Unfortunately, strace isn't of much use here, since it catches the
> syscall trap and reports close(), even though it's really some other
> (hidden?) libc function at the higher layer.

you could try ltrace.  i wouldnt be surprised if there were places where glibc 
called close() internally and there is no public symbol for you to catch 
without going through all the public points (like fclose).
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]