[Bug runtime/19241] systemtap fails to start when CPU0 is offline

["mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19241

--- Comment #2 from Martin Cermak <mcermak at redhat dot com> ---
Created attachment 8796
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8796&action=edit
proposed "stream mode" file descriptor fix

Running whole the testsuite on a machine having some CPUs offline shows, that
some testcases, such as argv.exp, fail due to incorrect "stream mode" file
descriptor handling introduced in commit d879410. Proposed fix attached.
Details:

=======
# cat /sys/devices/system/cpu/cpu*/online
0
1
1
1
#
# make installcheck RUNTESTFLAGS='systemtap.base/argv.exp'

... stuff deleted ...

Running ./systemtap.base/argv.exp ...
argc=0
FAIL: argv naked
argc=1
argv[1]=hello
FAIL: argv one
argc=2
argv[1]=hello
argv[2]=world
FAIL: argv two
argc=1
argv[1]=hello
FAIL: argv one other
argc=2
argv[1]=hello
argv[2]=world
FAIL: argv two other
argc=2
argv[1]=hello
argv[2]=world
FAIL: argv two mixed
argc=3
argv[1]=hello
argv[2]=world
argv[3]=mom
FAIL: argv three mixed

... stuff deleted ...

=======

Here the problem is, that staprun's output doesn't go to stdout, but to an
invalid fd (ending up in the terminal) instead, where expect can't capture it
and complains:

=======
# cat systemtap.log 

... stuff deleted ...

Running ./systemtap.base/argv.exp ...
executing: stap ./systemtap.base/argv.stp
FAIL: argv naked
too few lines of output, got 0, expected 1
executing: stap ./systemtap.base/argv.stp hello
FAIL: argv one
too few lines of output, got 0, expected 2

... stuff deleted ...

=======

This can be also demonstrated thusly:

=======
# stap systemtap.base/argv.stp hello &>/dev/null
argc=1
argv[1]=hello
# # ^^ should have ended up in /dev/null
# echo 'stap systemtap.base/argv.stp hello' | bash
ERROR: Couldn't write to output 0 for cpu 1, exiting.: Bad file descriptor
# 
=======

Attached patch, that is now being tested, seems to fix the issue for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.