From owner-freebsd-current@FreeBSD.ORG Thu Mar 18 07:01:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C524D16A4CE for ; Thu, 18 Mar 2004 07:01:49 -0800 (PST) Received: from sweeper.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90C6D43D45 for ; Thu, 18 Mar 2004 07:01:48 -0800 (PST) (envelope-from peter.edwards@openet-telecom.com) Received: from mail.openet-telecom.com (unverified) by sweeper.openet-telecom.com ; Thu, 18 Mar 2004 15:01:57 +0000 Received: from openet-telecom.com (10.0.3.126) by mail.openet-telecom.com (NPlex 6.5.027) (authenticated as Peter@openet-telecom.com) id 404A4ED700010399; Thu, 18 Mar 2004 15:01:42 +0000 Message-ID: <4059B9CD.1010003@openet-telecom.com> Date: Thu, 18 Mar 2004 15:01:33 +0000 From: Peter Edwards User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.6) Gecko/20040120 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: des@des.no References: <4058AC1C.10208@mitre.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: Quoted-Printable cc: freebsd-current@freebsd.org Subject: Re: Pan crashing in libgnuregex after -pthread switchover X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 15:01:49 -0000 Dag-Erling Sm=C3=B8rgrav wrote: >Jason Andresen writes: > =20 > >>It seems to me that every libpthread.so.1 maps to a libc_r.so.5, but >>when I actually run pan it still crashes and shows libpthread in the >>backtrace. Does anybody have a clue as to what is going on here? >> =20 >> > >gdb doesn't know about libmap.conf, so the backtrace is wrong. > >DES > =20 > My understanding is that the dynamic linker fills a link_map (see=20 sys/link_elf.h) structure with the mapped name, and gdb grovels for this=20 in the core: it should work correctly on a corefile. Sounds more like=20 libpthread and libc_r are both in-process to me. Jason, try "i sh" from gdb to see what libraries were loaded in the=20 process when it dumped. Interestingly, from the stack trace, frame 3 shows "re_search" calling=20 into the main application, not a shared library, at the "??" bit (the=20 instruction pointer is in the wrong range for a shared library): It=20 sounds like the application is implementing a function that should=20 probably be resolved from a shared library, and the linker is binding=20 the application version instead of the standard one: that might be an iss= ue. (I don't think the regex library ever uses callbacks, which would be the=20 only other reason I can think it'd happen) The sysutils/pstack has a good chance of finding the name of the "??"=20 function if you want to run that on the corefile: it takes the dynamic=20 exported functions into account as well as the debug information when=20 finding function names. HTH, Peter.