This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug testsuite/11525] pr10854.exp locks up expect run
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 22 Apr 2010 13:15:50 -0000
- Subject: [Bug testsuite/11525] pr10854.exp locks up expect run
- References: <20100421151358.11525.mjw@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From mjw at redhat dot com 2010-04-22 13:15 -------
(In reply to comment #2)
> (In reply to comment #1)
> > I haven't seen this problem, but I see problems when looking at pr10854.stp. It
> > filters out probe hits from 'staprun' instead of 'stapio', and should probably
> > do that filter in the .return handler also. Here's a patch of those changes:
>
> Yes, nice catch. Using "pid() == stp_pid()" might be even better.
I pushed this change since it cleans up the testcase.
commit 1aa71d93e247f68ef9222b01f386e1d21dd23b81
Author: Mark Wielaard <mjw@redhat.com>
Date: Thu Apr 22 15:07:49 2010 +0200
Skip stapio tracing in pr10854.stp.
As pointed out by dsmith and jistone in PR11525, this cleans up the test.
* testsuite/systemtap.base/pr10854.stp: Use pid() == stp_pid()) next
to skip tracing our own helper process.
But it doesn't help my case (and I would be surprised if it did).
Still stuck with the following while running pr10854.exp:
14760 pts/1 Tl+ 0:00 expect -- /usr/share/dejagnu/runtest.exp --tool syste
15210 ? Zs 0:00 [stapio] <defunct>
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11525
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.