From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26814 invoked by alias); 28 Jun 2006 16:49:55 -0000 Received: (qmail 26794 invoked by uid 48); 28 Jun 2006 16:49:48 -0000 Date: Wed, 28 Jun 2006 18:56:00 -0000 From: "hunt at redhat dot com" To: systemtap@sources.redhat.com Message-ID: <20060628164947.2861.hunt@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug tapsets/2861] New: user_string fault handling X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00709.txt.bz2 Fallout from bug 2637. Now that we have more page faults, we must handle them gracefully. Currently when user_string() fails, it sets CONTEXT->last_error, which causes the script to exit, unless you set MAXERRORS to something high enough. Using MAXERRORS this way is not appropriate and you end up just always setting it to something high so your scripts don't terminate, even if they should because they are dividing by zero or overflowing arrays. Userspace data not always being available is an expected limitation of our implementation, not an unexpected error. I think a better solution is to generate a warning and return "". The warning might even be optional. This has been discussed before with no consensus. Leaving things broken is not an option. Please document your objections and post alternatives. -- Summary: user_string fault handling Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P1 Component: tapsets AssignedTo: systemtap at sources dot redhat dot com ReportedBy: hunt at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=2861 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.