From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: new auparse question Date: Wed, 31 Aug 2011 15:31:48 -0500 Message-ID: <1314822708.2094.127.camel@lcb> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx11.extmail.prod.ext.phx2.redhat.com [10.5.110.16]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p7VKVx6S024234 for ; Wed, 31 Aug 2011 16:31:59 -0400 Received: from webserver.magitekltd.com (rrcs-24-242-137-197.sw.biz.rr.com [24.242.137.197]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7VKVsGL018179 for ; Wed, 31 Aug 2011 16:31:54 -0400 Received: from [24.242.137.194] (helo=[192.168.30.40]) by webserver.magitekltd.com with esmtpsa (SSL3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QyrRx-0007Hf-V8 for linux-audit@redhat.com; Wed, 31 Aug 2011 15:31:53 -0500 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 List-Id: linux-audit@redhat.com I have an issue now with auparse_find_field. I work around it fine though but maybe it's worth reporting. There is a place where I do this: const char *result; ... result=auparse_find_field(au, "res"); and get a segfault. If I instead do this: const char *result; ... auparse_first_field(au); result=auparse_find_field(au, "res"); then it is fine. A quick gdb test shows me : 0x00007ffff7dd2a7d in nvlist_get_cur_name (au=0x617a90, name=0x4022a8 "res") at nvlist.h:40 40 static inline const char *nvlist_get_cur_name(const nvlist *l) {return l->cur->name;} Looking at my own code, I believe I previously had walked through the event record using this loop: ... auparse_first_field(au); do { ... } while (auparse_next_field(au) > 0); ... and so I guess that the "cur" field was undefined when used the auparse_find_field call. It (auparse_find_field) calls: ... cur_name = nvlist_get_cur_name(&r->nv); and I guess that's were the problem happened. So my question is - is this a bug (I would think so) or should I always precede any auparse call sequence with at least one fresh auparse_first_field call? Thx, LCB -- LC (Lenny) Bruzenak lenny@magitekltd.com