From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21573 invoked by alias); 22 Jan 2003 14:23:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21566 invoked from network); 22 Jan 2003 14:23:48 -0000 Received: from unknown (HELO www1.navtechinc.com) (192.234.226.140) by 172.16.49.205 with SMTP; 22 Jan 2003 14:23:48 -0000 Received: from pcNavYkfAdm1.ykf.navtechinc.com (wall [192.234.226.190]) by www1.navtechinc.com (8.9.3/8.9.3) with ESMTP id OAA09480; Wed, 22 Jan 2003 14:23:46 GMT Received: from navtechinc.com (IDENT:hohmW19rCJRu+/8N8nVmjiHZm8I7IaEI@pcNavYkfCjh.ykf.navtechinc.com [204.138.155.26]) by pcNavYkfAdm1.ykf.navtechinc.com (8.9.3/8.9.3) with ESMTP id OAA25431; Wed, 22 Jan 2003 14:23:11 GMT Message-ID: <3E2EA950.8020008@navtechinc.com> Date: Wed, 22 Jan 2003 14:23:00 -0000 From: Chris Hamilton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Korb CC: Daniel Jacobowitz , Bruce Korb , gdb@sources.redhat.com Subject: Re: popen References: <3E2C6377.5030600@navtechinc.com> <3E2C6A5C.3AA4D0E3@gnu.org> <20030121020051.GA17791@nevyn.them.org> <3E2CBD89.3C875FC7@veritas.com> <3E2D6310.3030307@navtechinc.com> In-Reply-To: <3E2D6310.3030307@navtechinc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00372.txt.bz2 I didn't really think that odbc was causing the problem, so I linked in another threaded library and got the same result. I think the general case is that gdb loses it's brains anytime a threaded library is linked in, a breakpoint is set and a popen is passed over. I've tried this with a few safe libraries ( ie. libraries I didn't write ;) ), and this seems to hold up. Chris Hamilton wrote: > The problem seems to come when I include the odbc libraries included > with redhat 7.3. I've included a test .c file that will cause the > problem when run with: > cc popen_test.c -o a.out -g -lodbc > > > Bruce Korb wrote: > >> Daniel Jacobowitz wrote: >> >> >>> On Mon, Jan 20, 2003 at 01:30:04PM -0800, Bruce Korb wrote: >>> >>> >>>> Chris Hamilton wrote: >>>> >>>> >>>>> Bruce, >>>>> I came across your September 24th posting about gdb throwing off a >>>>> "Cannot find thread 2049" when it hits a popen >>>>> (http://sources.redhat.com/ml/insight/2002-q3/msg00185.html). >>>>> I'm currently experiencing the same problem in my application, and >>>>> I was >>>>> wondering if you had any advice on how to solve it. >>>>> >>>> >> >> >> >>> Popen should not present this problem. I don't know why it does, so we >>> need more information. >>> >> >> >> It seems to occur when using popen, but not when I do all >> the fork/exec stuff myself. I'll see if a trivial popen >> example duplicates the problem, but I would guess that many >> would have complained by now if it were that easy. >> >> >> >>> Meanwhile multi-process debugging is forthcoming. The Linux kernel >>> patches are already in and I have more GDB patches queued. >>> >> >> >> Excellent!! Thank you very much! >> >> >> >------------------------------------------------------------------------ > >#include > >int main() >{ > >FILE *tpPipeFp; > >if((tpPipeFp = popen("test", "w")) == NULL) > { > printf("Can't open pipe\n"); > exit(); > } >else > printf("I've opened the pipe\n"); > >pclose(tpPipeFp); > >} > > >