Bug 34570

Summary:	filter socket operations by path, too
Product:	Sisyphus	Reporter:	Ivan Zakharyaschev <imz>
Component:	strace	Assignee:	Dmitry V. Levin <ldv>
Status:	NEW ---	QA Contact:	qa-sisyphus
Severity:	enhancement
Priority:	P3	CC:	ldv, placeholder
Version:	unstable
Hardware:	all
OS:	Linux
URL:	https://github.com/strace/strace/issues/40
Bug Depends on:
Bug Blocks:	34562

Description Ivan Zakharyaschev 2018-02-20 12:52:54 MSK

strace-4.21-alt2

-P FILE -e trace=read makes strace show only reads from fds associated with the specified path. However, this doesn't work for sockets connected to a path (for connect,close,sendto,recvfrom).

Example showing that -P has an effect on filtering reads:

$ strace -f -P .lpoptions -e trace=read cat .lpoptions 
strace: Requested path '.lpoptions' resolved into '/space/home/imz/.lpoptions'
read(3, "EmbedAllFonts=yes", 131072)    = 17
EmbedAllFonts=yesread(3, "", 131072)                     = 0
+++ exited with 0 +++
$ strace -f -y -e trace=read cat .lpoptions 
read(3</lib64/libc-2.25.so>, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\7\2\0\0\0\0\0"..., 832) = 832
read(3</space/home/imz/.lpoptions>, "EmbedAllFonts=yes", 131072) = 17
EmbedAllFonts=yesread(3</space/home/imz/.lpoptions>, "", 131072) = 0
+++ exited with 0 +++
$

Comment 1 Ivan Zakharyaschev 2018-02-20 12:55:54 MSK

(To reproduce a bug, I wanted to inject a success for a close syscall associated with a socket connected to a specific file.)

Comment 2 Ivan Zakharyaschev 2018-09-27 05:22:28 MSK

(In reply to comment #1)
> (To reproduce a bug, I wanted to inject a success for a close syscall
> associated with a socket connected to a specific file.)

Of course, the requested feature could be a useful feature in general, but in my case it (combined with success injection) wouldn't help me to reproduce that bug.

It could only be useful for filtering and reading the log. (However, filtering can be done by external tools, so the absence of the requested feature is not critical.)

I didn't understand that it wouldn't help when I wrote this feature request, but I understood this after a while; and here is why:

if I made the close() syscall not have any real effect, I would make subsequent socket() and open() syscalls return shifted fd numbers (which would break the behavior pattern when the bug is not observed), but that wouldn't actually make the subsequent select() syscalls using the old fd number fail, because that would still be a valid open fd.

The bug would appear if the subsequent syscalls would try to work with the old and already closed fd. (Therefore, I made up a way of not re-using the old fd number by "randomizing" the number returned from socket() with an LD_PRELOAD, so that it has little chance to coincide with the old, just closed fd.)

Comment 3 Ivan Zakharyaschev 2018-09-27 05:26:00 MSK

(In reply to comment #2)

> The bug would appear if the subsequent syscalls would try to work with the old
> and already closed fd.

Or more accurately: ...if they tried to work with the old fd, that got re-used for a non-socket connection or a unrelated connection.

>  (Therefore, I made up a way of not re-using the old fd
> number by "randomizing" the number returned from socket() with an LD_PRELOAD,
> so that it has little chance to coincide with the old, just closed fd.)