From owner-freebsd-hackers Thu Mar 1 9:58:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 45B2837B719 for ; Thu, 1 Mar 2001 09:58:43 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 76362 invoked by uid 1000); 1 Mar 2001 17:58:17 -0000 Date: Thu, 1 Mar 2001 19:58:17 +0200 From: Peter Pentchev To: Peter Dufault Cc: hackers@freebsd.org Subject: Re: Stupid debugging pthread question Message-ID: <20010301195817.G55211@ringworld.oblivion.bg> Mail-Followup-To: Peter Dufault , hackers@freebsd.org References: <200103011745.f21Hjts33386@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103011745.f21Hjts33386@hda.hda.com>; from dufault@hda.hda.com on Thu, Mar 01, 2001 at 12:44:39PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 01, 2001 at 12:44:39PM -0500, Peter Dufault wrote: > This is a stupid question, basically it's how to debug something. > > I have four cooperating p-threaded processes. One of them keeps getting > a SIGSEGV with the address 0x752f422f. I'm not sure if that address is > always the same, but with a given compile it is. The thing that's a pain > is it is random. The four processes can run for a long time, or through > several tests to completion, and then the > nasty process gets that SIGSEGV. The thread that receives the SIGSEGV > is random, the stack of the SEGV'd thread is trash, the rest of the > threads in the offending process still have intact stacks. Arg! > > Because this is intermittent my temptation is to ignore it and proceed > and eventually something will happen to let me figure it out. But > it's been going on for a while, and it just happened twice in a row so... > Anybody seen anything remotely similar and have a suggestion? How > does one dump the stack brute force on an x86? Not too much help, but.. 0x752f422f sure looks like a hex representation of 4 ASCII chars, and in the alnum range to boot; it's '/B/u', if I'm not too sleepy, and considering the little-endian Intel architecture. It sure looks like you have a (self-inflicted? :) buffer overflow somewhere in your code. G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message