From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17542 invoked by alias); 17 Nov 2009 17:31:35 -0000 Received: (qmail 17496 invoked by uid 48); 17 Nov 2009 17:31:20 -0000 Date: Tue, 17 Nov 2009 17:31:00 -0000 Message-ID: <20091117173120.17495.qmail@sourceware.org> From: "fche at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20090522204505.10189.jistone@redhat.com> References: <20090522204505.10189.jistone@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/10189] STP_START gets lost in a warning flood X-Bugzilla-Reason: AssignedTo 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: 2009-q4/txt/msg00555.txt.bz2 ------- Additional Comments From fche at redhat dot com 2009-11-17 17:31 ------- (In reply to comment #2) > Current stap will keep allocating buffer for _stp_warn in probe until > out of memory. That's wrong; script-accessible constructs like error()/warn() should not be able to deplete a dynamically allocated resource. OTOH in this case it looks like the transport is just using its own _stp_mempool_alloc, which at least is a private resource. > Maybe it's better to make _stp_warn utilize _stp_print instead of > _stp_ctl_write. Then we'd have the same problem with error(). The OOB messages do serve a useful purpose at staprun time, so let's find a way of preserving OOB while ensuring that the basic protocol can proceed. For example, we can know that some of these kernel->staprun messages only occur singly (i.e., are not queued en masse). So for them, we could preallocate a mem_buffer element, to avoid having them contend. One way would be to have separate mempools for each message type, and ensuring that the singleton messages only allocate one or two elements total. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10189 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.