Bug 194144 - Make log-fd really log to that fd (not dup on startup)
Summary: Make log-fd really log to that fd (not dup on startup)
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (other bugs)
Version First Reported In: 3.3.1
Platform: Ubuntu Linux
: NOR normal
Target Milestone: wanted3.6.0
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-26 12:23 UTC by Crispin Flowerday
Modified: 2024-05-03 14:44 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Crispin Flowerday 2009-05-26 12:23:26 UTC
I have a program which has an error log that is always attached to file descriptor 2, but the log file could change (in particular at one point we attach a daemon to fd 2 that error messages go through).

We used to use --log-fd=2 to force all valgrind errors to via that file descriptor, however valgrind seems to have changed behaviour so that if you use --log-fd=2 it dups fd 2 to somewhere else on startup and logs using that new fd.

This means valgrind logs to whatever stderr was on on startup rather than what my program has changed stderr to.

It would be nice to have valgrind just log to a file descriptor rather than duping it to somewhere else.
Comment 1 Oswald Buddenhagen 2024-05-03 14:25:43 UTC
this seems like an anti-feature to me, breaking the isolation between valgrind and the tracee. the proper solution would be a log daemon to which both can talk.
Comment 2 Tom Hughes 2024-05-03 14:44:06 UTC
Moving the FD is done to preserve isolation by keeping valgrind's file descriptors separate from those of the tracee - valgrind presents a reduced descriptor limit to the tracee and uses the descriptors between that limit and the real one for itself so here it is trying to move the log descriptor into that protected range.