|
From: Dan S. <dan...@go...> - 2012-05-26 23:20:34
|
Is there a way to set the fd number used by the --log-file number? We've encountered serious trouble when we test the bash/dash/ksh family of shells with valgrind, sometimes testing fails because there are fds used by valgrind which are considered free by the shell. -- Dan Shelton |
|
From: Philippe W. <phi...@sk...> - 2012-05-26 23:29:04
|
On Sun, 2012-05-27 at 01:20 +0200, Dan Shelton wrote: > Is there a way to set the fd number used by the --log-file number? > We've encountered serious trouble when we test the bash/dash/ksh > family of shells with valgrind, sometimes testing fails because there > are fds used by valgrind which are considered free by the shell. I understand that Valgrind should properly indicate to bash/dash/ksh the fd range which is usable. Valgrind reserves a part of the fd range for its own use. This reserved part should not be visible to the client (i.e. valgrind ensures that the syscall getrlimit returns a range not including the reserved for Valgrind). How is bash/... guessing that they can use such a reserved fd ? Philippe |
|
From: Roland M. <rol...@nr...> - 2012-05-27 00:56:53
|
On Sun, May 27, 2012 at 1:29 AM, Philippe Waroquiers
<phi...@sk...> wrote:
> On Sun, 2012-05-27 at 01:20 +0200, Dan Shelton wrote:
>> Is there a way to set the fd number used by the --log-file number?
>> We've encountered serious trouble when we test the bash/dash/ksh
>> family of shells with valgrind, sometimes testing fails because there
>> are fds used by valgrind which are considered free by the shell.
> I understand that Valgrind should properly indicate to bash/dash/ksh
> the fd range which is usable.
>
> Valgrind reserves a part of the fd range for its own use.
> This reserved part should not be visible to the client
> (i.e. valgrind ensures that the syscall getrlimit
> returns a range not including the reserved for Valgrind).
>
> How is bash/... guessing that they can use such
> a reserved fd ?
To clarify Dan's issue (we're sitting together and hunt down some shell bugs):
We see weired test suite failures in ksh93's test suite like these ones:
-- snip --
test io begins at 2012-05-27+02:35:39
io.sh[119]: picked up file descriptor zero for opening script file
io.sh[128]: multiple exec 4< /dev/null can fail
io.sh[193]: parent i/o causes child script to fail
io.sh[204]: trap on EXIT loses last command redirection
io.sh[284]: closed standard output not passed to subshell
-- snip --
These tests used fixed fd numbers (0-6) and "dynamically allocated"
("dynamically" means ksh93 has a syntax to allocate a free fd for a
scripts usage, e.g. by using $ integer n ; exec
{n}</dev/by/path/chutulluh # ; shell variable "n" then contains the fd
number) by the shell (by default anything >=10, for the tests listed
above it's 10-15).
Is it possible somehow that this crosses any paths with valgrind's fd
usage (I'm more or less sure that the ksh93/libast code involved is
correct... at least Rational Purify and Sun Studio's "dbx -check
access" report no issues (but valgrind shows it's teeth)) ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rol...@nr...
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
|
|
From: Dan S. <dan...@go...> - 2012-05-26 23:40:46
|
On 27 May 2012 01:29, Philippe Waroquiers <phi...@sk...> wrote: > On Sun, 2012-05-27 at 01:20 +0200, Dan Shelton wrote: >> Is there a way to set the fd number used by the --log-file number? >> We've encountered serious trouble when we test the bash/dash/ksh >> family of shells with valgrind, sometimes testing fails because there >> are fds used by valgrind which are considered free by the shell. > I understand that Valgrind should properly indicate to bash/dash/ksh > the fd range which is usable. > > Valgrind reserves a part of the fd range for its own use. > This reserved part should not be visible to the client > (i.e. valgrind ensures that the syscall getrlimit > returns a range not including the reserved for Valgrind). > > How is bash/... guessing that they can use such > a reserved fd ? We've guessed that because some of the tests have valgrind output inside while we explicitly set --log-file. The best guess was that the shell tests which have fd numbers hardcoded interfere with valgrinds fd usage. But we might be wrong with that. -- Dan Shelton |
|
From: Dan S. <dan...@go...> - 2012-05-26 23:41:25
|
On 27 May 2012 01:40, Dan Shelton <dan...@go...> wrote: > On 27 May 2012 01:29, Philippe Waroquiers <phi...@sk...> wrote: >> On Sun, 2012-05-27 at 01:20 +0200, Dan Shelton wrote: >>> Is there a way to set the fd number used by the --log-file number? >>> We've encountered serious trouble when we test the bash/dash/ksh >>> family of shells with valgrind, sometimes testing fails because there >>> are fds used by valgrind which are considered free by the shell. >> I understand that Valgrind should properly indicate to bash/dash/ksh >> the fd range which is usable. >> >> Valgrind reserves a part of the fd range for its own use. >> This reserved part should not be visible to the client >> (i.e. valgrind ensures that the syscall getrlimit >> returns a range not including the reserved for Valgrind). >> >> How is bash/... guessing that they can use such >> a reserved fd ? > > We've guessed that because some of the tests have valgrind output > inside while we explicitly set --log-file. The best guess was that the > shell tests which have fd numbers hardcoded interfere with valgrinds > fd usage. But we might be wrong with that. Which fd numbers does valgrind typically use on Linux for --log-file? -- Dan Shelton |
|
From: Philippe W. <phi...@sk...> - 2012-05-27 07:27:15
|
On Sun, 2012-05-27 at 01:41 +0200, Dan Shelton wrote: > Which fd numbers does valgrind typically use on Linux for --log-file? Valgrind (V) is using several fd nrs, e.g; for --log-file, for pipes used as semaphore, for Valgrind gdbserver FIFOs/mmap-ed file, ... All these fds are taken from a range which only V should see. For this, V is maintaining two "fd" limits: extern Int VG_(fd_soft_limit); extern Int VG_(fd_hard_limit); Before executing the guest code, it will setup these two limits. The range >= fd_hard_limit will be used by V and is not supposed to be used by the guest code. V ensures this by checking e.g. setrlimit and making it fail if it sets the limit above the V range. Similarly, V will ensure getrlimit indicates only FD below the above limits can be used. On the platform I am testing, V reserves a range of 10 FDs (>= 1014). (these 10 is a compilation constant. Might be that on other platforms, this range is starting from another value). Philippe |
|
From: Julian S. <js...@ac...> - 2012-12-05 13:39:24
|
On Sunday, May 27, 2012, Dan Shelton wrote:
> On 27 May 2012 01:40, Dan Shelton <dan...@go...> wrote:
> > On 27 May 2012 01:29, Philippe Waroquiers <phi...@sk...>
wrote:
> >> On Sun, 2012-05-27 at 01:20 +0200, Dan Shelton wrote:
> >>> Is there a way to set the fd number used by the --log-file number?
> >>> We've encountered serious trouble when we test the bash/dash/ksh
> >>> family of shells with valgrind, sometimes testing fails because there
> >>> are fds used by valgrind which are considered free by the shell.
You can use
--log-fd=<number> log messages to file descriptor [2=stderr]
or
--log-socket=ipaddr:port log messages to socket ipaddr:port
and use the valgrind-listener program to collect the results.
The second scheme is arguably better as it allows getting data "off the
premises" with no interference at all with normal fd traffic.
J
|