* Re: popen [not found] <3E2C6377.5030600@navtechinc.com> @ 2003-01-20 21:30 ` Bruce Korb 2003-01-21 2:01 ` popen Daniel Jacobowitz 0 siblings, 1 reply; 5+ messages in thread From: Bruce Korb @ 2003-01-20 21:30 UTC (permalink / raw) To: Chris Hamilton; +Cc: gdb 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. printf debugging, I guess. Essentially, the problem boils down to there not being a good implementation of multithreaded process management for GDB on i386. If you are running UnixWare, then Debug works great. Otherwise, you might try a supported multithread platform (Solaris on Sparc??). ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: popen 2003-01-20 21:30 ` popen Bruce Korb @ 2003-01-21 2:01 ` Daniel Jacobowitz 2003-01-21 3:16 ` popen Bruce Korb 0 siblings, 1 reply; 5+ messages in thread From: Daniel Jacobowitz @ 2003-01-21 2:01 UTC (permalink / raw) To: Bruce Korb; +Cc: Chris Hamilton, gdb 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. > > printf debugging, I guess. Essentially, the problem boils down > to there not being a good implementation of multithreaded > process management for GDB on i386. If you are running UnixWare, > then Debug works great. Otherwise, you might try a supported > multithread platform (Solaris on Sparc??). Popen should not present this problem. I don't know why it does, so we need more information. Meanwhile multi-process debugging is forthcoming. The Linux kernel patches are already in and I have more GDB patches queued. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: popen 2003-01-21 2:01 ` popen Daniel Jacobowitz @ 2003-01-21 3:16 ` Bruce Korb 2003-01-21 15:11 ` popen Chris Hamilton 0 siblings, 1 reply; 5+ messages in thread From: Bruce Korb @ 2003-01-21 3:16 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Bruce Korb, Chris Hamilton, gdb, bkorb 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! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: popen 2003-01-21 3:16 ` popen Bruce Korb @ 2003-01-21 15:11 ` Chris Hamilton 2003-01-22 14:23 ` popen Chris Hamilton 0 siblings, 1 reply; 5+ messages in thread From: Chris Hamilton @ 2003-01-21 15:11 UTC (permalink / raw) To: Bruce Korb; +Cc: Daniel Jacobowitz, Bruce Korb, gdb [-- Attachment #1: Type: text/plain, Size: 1253 bytes --] 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! > > > [-- Attachment #2: popen_test.c --] [-- Type: text/plain, Size: 218 bytes --] #include <stdio.h> 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); } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: popen 2003-01-21 15:11 ` popen Chris Hamilton @ 2003-01-22 14:23 ` Chris Hamilton 0 siblings, 0 replies; 5+ messages in thread From: Chris Hamilton @ 2003-01-22 14:23 UTC (permalink / raw) To: Bruce Korb; +Cc: Daniel Jacobowitz, Bruce Korb, gdb 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 <stdio.h> > >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); > >} > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-01-22 14:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3E2C6377.5030600@navtechinc.com>
2003-01-20 21:30 ` popen Bruce Korb
2003-01-21 2:01 ` popen Daniel Jacobowitz
2003-01-21 3:16 ` popen Bruce Korb
2003-01-21 15:11 ` popen Chris Hamilton
2003-01-22 14:23 ` popen Chris Hamilton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox