From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8862 invoked by alias); 19 Nov 2015 12:25:01 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 4517 invoked by uid 48); 19 Nov 2015 12:24:56 -0000 From: "mcermak at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/19241] systemtap fails to start when CPU0 is offline Date: Thu, 19 Nov 2015 12:25:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mcermak at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q4/txt/msg00153.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D19241 --- Comment #2 from Martin Cermak --- Created attachment 8796 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D8796&action=3Dedit proposed "stream mode" file descriptor fix Running whole the testsuite on a machine having some CPUs offline shows, th= at some testcases, such as argv.exp, fail due to incorrect "stream mode" file descriptor handling introduced in commit d879410. Proposed fix attached. Details: =3D=3D=3D=3D=3D=3D=3D # cat /sys/devices/system/cpu/cpu*/online 0 1 1 1 # # make installcheck RUNTESTFLAGS=3D'systemtap.base/argv.exp' ... stuff deleted ... Running ./systemtap.base/argv.exp ... argc=3D0 FAIL: argv naked argc=3D1 argv[1]=3Dhello FAIL: argv one argc=3D2 argv[1]=3Dhello argv[2]=3Dworld FAIL: argv two argc=3D1 argv[1]=3Dhello FAIL: argv one other argc=3D2 argv[1]=3Dhello argv[2]=3Dworld FAIL: argv two other argc=3D2 argv[1]=3Dhello argv[2]=3Dworld FAIL: argv two mixed argc=3D3 argv[1]=3Dhello argv[2]=3Dworld argv[3]=3Dmom FAIL: argv three mixed ... stuff deleted ... =3D=3D=3D=3D=3D=3D=3D 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: =3D=3D=3D=3D=3D=3D=3D # cat systemtap.log=20 ... 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 ... =3D=3D=3D=3D=3D=3D=3D This can be also demonstrated thusly: =3D=3D=3D=3D=3D=3D=3D # stap systemtap.base/argv.stp hello &>/dev/null argc=3D1 argv[1]=3Dhello # # ^^ 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 #=20 =3D=3D=3D=3D=3D=3D=3D Attached patch, that is now being tested, seems to fix the issue for me. --=20 You are receiving this mail because: You are the assignee for the bug.