From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14706 invoked by alias); 13 Feb 2013 22:10:11 -0000 Received: (qmail 14529 invoked by uid 48); 13 Feb 2013 22:09:48 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/15147] New: _stp_error() doesn't behave as described Date: Wed, 13 Feb 2013 22:10:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2013-q1/txt/msg00131.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15147 Bug #: 15147 Summary: _stp_error() doesn't behave as described Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime AssignedTo: systemtap@sourceware.org ReportedBy: dsmith@redhat.com Classification: Unclassified According to the documentation string for _stp_error(): /** Prints error message and exits. * This function sends an error message immediately to staprun. It * will also be sent over the bulk transport (relayfs) if it is * being used. If the last character is not a newline, then one * is added. * * After the error message is displayed, the module will be unloaded. * @param fmt A variable number of args. * @sa _stp_exit(). */ This documentation is (sort of) true, but doesn't match what happens in other error situations. For example: ==== # stap -ge 'function error_test(str:string) %{ _stp_error(STAP_ARG_str); %} probe begin { error_test("error 1"); printf("after 1st error\n"); error_test("error 2"); printf("after 2nd error\n"); } probe end { printf("exiting\n") }' ERROR: error 1 ERROR: error 2 after 1st error after 2nd error exiting WARNING: /usr/local/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] ==== Here's the same script, but instead of calling _stp_error() we set CONTEXT->last_error: ==== stap -ge 'function error_test(str:string) %{ CONTEXT->last_error = STAP_ARG_str; %} probe begin { error_test("error 1"); printf("after 1st error\n"); error_test("error 2"); printf("after 2nd error\n"); } probe end { printf("exiting\n") }' ERROR: error 1 near identifier 'error_test' at :1:10 WARNING: Number of errors: 1, skipped probes: 0 WARNING: /usr/local/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] ==== Notice the differences - the probe exited immediately (instead of running the entire begin probe), stap reported that 1 error had occurred, and the 'end' probe didn't get run. The documentation states that the module "will be unloaded". While true, it isn't unloaded immediately like it does in other error situations. At a minimum the documentation for _stp_error() should be improved. A more ambitious approach would be to reimplement it with CONTEXT->last_error or remove _stp_error(). (If removal is chosen, _stp_softerror() is another candidate for removal.) Note this is somewhat related to bug #14738, which states that _stp_error() is being overused. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.