Re: Making the transport layer more robust

[William Cohen <wcohen@redhat.com>]

On 07/19/2011 04:58 AM, Mark Wielaard wrote:

> pr10854.exp acts strangely on rhel5, it seems fine on f14. It just sits
> there waiting the reap staprun, which will never happen since it tries
> to pkill it at the same time, that could be because the startup/exit of
> staprun/stapio is much more robust now, but I don't fully understand the
> expect spawn, catch, wait logic. Maybe it is some strange bug in the
> rhel5 expect? Maybe I changed some expectation of staprun/stapio/module
> interaction? Any help understanding the expect logic would be
> appreciated.

Another data point. PR10854.exp also acts strangely on the fedora 13 arm running a custom kernel from:

 git://gitorious.org/efikamx/linux-kernel.git

$ uname -a
Linux smartbook-fedora-arm 2.6.31.14.24-efikamx #1 PREEMPT Mon Jul 18 21:32:54 EDT 2011 armv7l armv7l armv7l GNU/Linux

Ran with:

make installcheck RUNTESTFLAGS="--debug systemtap.base/pr10854.exp"

tail -f testsuite/systemtap.log:

Running /media/pata/home/wcohen_fedora/systemtap_write/systemtap/testsuite/systemtap.base/pr10854.exp ...
PASS: compiling pr10854.stp
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")
trap: setting up signal 11 ("SIGSEGV")


Seems to wait and wait. Hit control-c. then get the following in log:


got a INT signal, interrupted by user 

		=== systemtap Summary ===

# of expected passes		1
runtest completed at Tue Jul 19 11:04:56 2011




-Will