From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luciano Chavez Subject: libaudit large stack requirement in audit_send() Date: Mon, 29 Apr 2013 11:15:16 -0500 Message-ID: <1367252116.6765.50.camel@chavez-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3TGFioO002413 for ; Mon, 29 Apr 2013 12:15:44 -0400 Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3TGFgTF027504 for ; Mon, 29 Apr 2013 12:15:42 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Apr 2013 12:15:42 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id BC8BEC9002A for ; Mon, 29 Apr 2013 12:15:36 -0400 (EDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3TGFaZm102248 for ; Mon, 29 Apr 2013 12:15:36 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3TGFIHj031353 for ; Mon, 29 Apr 2013 10:15:18 -0600 Received: from [9.65.204.160] (sig-9-65-204-160.mts.ibm.com [9.65.204.160]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r3TGFGMN031276 for ; Mon, 29 Apr 2013 10:15:17 -0600 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, I am working with a development team developing a J2EE application. They reported a problem with a crash in audit_send(). The crash occurred in a ppc64 architecture environment early on in the invocation to audit send. The crash occurs in this instruction which is establishing the size of the local stack: => 0xfff73237994 : stdu r1,-27232(r1) I found one large struct defined to a local variable (gdb) print sizeof(struct audit_message) $4 = 8988 but you will note that it asks for much more than that and after looking at the audit_send() routine, it calls a function called check_ack() which appears to be inlined and it contains two even larger definitions on the stack for the following structure: struct audit_reply (gdb) print sizeof(struct audit_reply) $3 = 9016 So, the combination of the three is what requires almost 26.5K of local stack usage in this frame alone. Is there a requirement for libaudit to have the structs on the stack versus allocated from heap? Is so, is this requirement documented somewhere? To be fair, the Java application has some heavy stack usage as it is since it is deployed in a web application server and there is a JNI function that is somewhere in the call stack as well. However, the stack usage in the audit_send() function seems ... excessive. Originally the thread stacksize size was set to 256K and that did not help but once we raised it to 1MB it did but I think that is probably more than we really need. I have looked at the source for the audit 2.2.3 release from March and don't see a difference in how the structs are allocated. So once again, if there is not a requirement that the structs be on the stack, should they not be allocated off the heap? regards, -- Luciano Chavez